I totally agree with you. A qpsmtpd-dev branch will speed tests allot. José Borges Ferreira
PS: the log parser looks really good. On Fri, Jun 22, 2012 at 10:14 AM, Matt Simerson <m...@simerson.net> wrote: > > http://www.nntp.perl.org/group/perl.qpsmtpd/2009/01/msg8376.html > > This thread almost precisely describes my vision for QP. To whit: > > a) It describes the need for a standardized method for handling > rejections. > > I have implemented this in pull request #23: > https://github.com/smtpd/qpsmtpd/pull/23 > > It breaks nothing in qpsmtpd, facilitates consistency in plugins, > simplifies each plugin, and yet has met resistance (passive or intentional) > in getting integrated. > > b) The thread describes a consistent manner of deferring rejections among > plugins (wait for DATA). > > A number of plugins do this on their own, at the expense of plugin > complexity. Rather than each plugin implementing delayed deferral, I wrote > the naughty plugin, which greatly simplifies the process and allows > deferred rejection in all plugins with one configuration setting. Albeit at > the expense of adding a plugin. The advantages are huge. Documenting how to > handle rejections across any plugin is now possible. Plugins are simpler. > But the main reason I wrote naughty was resource efficiency. Having a > standard way to make a connection as junk allows all subsequent plugins to > skip processing after the connection is marked as naughty. Regardless of > when the connection is rejected (from, to, data, data_post). > > Additional benefits of consistent rejection handling and message deferral > align with the logging goals I outlined in the May 1st email, "uniform > plugin logging." I described my desire to improve the human readability of > log messages, use consistent (skip, pass, fail) syntax to describe plugin > results, have each plugin typically log a single message per connection, > and allow the ability to increase/decrease loglevel for individual plugins. > > I have completed all of these goals. In addition, I have written > log_watch.pl, a CLI log watcher, that parses the much more uniform > qpsmtpd logs and conveniently summarizes each connection into a single line > of of output. I have some example output here: > http://www.tnpi.net/internet/mail/qp/logwatch.html > > I have written a CLI script named log2sql.pl, which also parses the now > mostly consistent log entries and feeds a summary of them into a SQL > database. A companion CGI app presents a very similar view of the SMTP > transaction history as shown by log_watch.pl. The data is well normalized > and 100,000 messages of history consume only 100MB of disk. If one opts not > to store the OS, hostname, helo string, from, and to data in the tables, > the disk consumption is about 95% less. > > I wrote these log processing tools because all the log processing tools I > found were written for older versions of qpsmtpd and no longer worked. They > also made rare attempts to log plugin actions, which made them of little > value to a user or author who wished to monitor or measure the effects of > twiddling settings or tweaking code. > > In doing all of the above, I have posted regularly to the list, soliciting > the input of the community, and often making changes to address issues > raised. > > The responses, particularly from the keepers of the commit bits, have been > deafening. > > I am to the point where I need to deploy. I was hoping that I could get my > changes merged into the main branch, but that appears impossible. I hate > the prospect of forking, but I see few alternatives. > > I hereby propose the creation of qpsmtpd-dev. > > The primary aim is merging the forks maintained by myself, Steve, Chris, > Jared, and others. I am willing to do much of the work to accomplish this. > I believe there is much to be gained by doing so, not the least of which is > saving others the pain of learning they are wasting their time trying to > improve QP in any way that doesn't fit with the unstated goals and vision > of the project. A secondary goal is to provide a development branch of QP > in which ideas can be rapidly tested, deployed, and when desired, > backported to the main branch. > > Matt
