Andras Korn wrote: > On Sun, Apr 13, 2008 at 02:55:16PM -0500, Sam Clippinger wrote: >> Most qmail servers run a stock version of qmail-smtpd, which will only >> reject recipients for relaying. > > They shouldn't, as stock qmail is liable to causing backscatter. No > self-respecting admin should run qmail as distributed by DJB today. Mail to > bogus recipients must not be accepted and then bounced later. Some mechanism > must be in place to ensure that mail to bogus recipients is never accepted > at all.
I agree. But regardless of what /should/ be the case, the fact is that most qmail servers run the stock version of qmail-smtpd. I can't justify making a change that will make spamdyke less efficient for the majority and only slightly more efficient for the minority. > I think you should always wait for RCPT TO, even if it's not necessary for > whitelist decisions, because then you can log whose mail you're rejecting. > rblsmtpd's inability to do this is one of its major shortcomings. spamdyke does always wait for RCPT, so that it can log the recipient. But it does not keep qmail running the entire time, if there is no chance the message will be accepted. If a recipient whitelist is not in use, there's no reason to wait. >> I suspect we're debating fractional efficiencies here anyway -- I've >> never benchmarked either scenario. > > Well, fwiw, I just ran a quick test: querying the handful of RBLs I have > configured in parallel takes about 10 seconds (as long as it takes for the > slowest of them to reply). Rejecting a mail based on the local list of valid > recipients takes a good deal less than a second. Of course local file accesses are faster than DNS queries. That's not what I meant. To find real numbers, you would have to consider how many connections are accepted, how many are rejected and for what reasons. Then look at the popularity of different spamdyke features and specifically the popularity of different DNS RBLs. Use all that to find out what percentage of rejected connections could avoid the DNS queries due to local tests. Lastly, find a way to evaluate the real cost (wall time, server load and network load) of spamdyke's DNS queries versus the additional load generated by passing the extra SMTP traffic to qmail. That last step is the part I don't know how to measure. If all of those numbers were available, my instinct says the advantage of your proposed change would be very small at best. -- Sam Clippinger _______________________________________________ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
