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
