Ask Bjørn Hansen said the following on 02/24/2006 08:39 AM: > > On Feb 23, 2006, at 1:27 PM, Robin Bowes wrote: > > [using plugin inheritance] > >>> The only thing I haven't worked out is how to handle any optional >>> commandline arguments to the original queue plugin (which may just be a >>> matter of calling the original plugins init() sub with the >>> appropriate @_). > > > Yeah, that should work. We really need a better configuration system > for the plugins though. > >> That's certainly another approach. >> >> However, it introduces unnecessary coupling between the logging and >> queueing processes. I'd rather keep them as separate as possible. > > > Isn't this approach exactly a way to keep them separate? The other > suggestions so far have involved changing the queue plugin(s) which > seems more intrusive...
I think the time is right for a global change here as John has proposed, i.e. foo_pre, foo, and foo_post hooks. > Thanks for working on this by the way. I lost track of what your goal > was, but having more and better way to analyze how much junk the smtpd > rejects (and how and why) will be useful. My goal is (was?) relatively simple: to produce two log files in addition to the "normal" log: accepted - listing details of all accepted msgs rejected - listing details of all rejected msgs/connection attempts > Robert mentioned a week or two ago that the perl.org (etc) MX only ends > up accepting a mail from 20% of all connections and of the accepted > mail most ends up being tossed in a huge file never to be looked at > again. (So something like 95%+ of the connections end up being a waste). Well, I'd like to be able to easily produce statistics like that. My gut feel, based on my experience running qpsmtpd for a medium-sized ISP (~350 domains) is that those figures are under-estimates. As an aside, isn't great to be able to easily modify the code like this? Can you imagine trying to patch qmail-smtpd to do this? Kudos. R.
