On Mon, Apr 14, 2008 at 09:40:51AM -0500, Sam Clippinger wrote:
> 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.
You yourself said that the decreased efficiency, if any, would be marginal.
This behaviour could even be configurable: "delay-dns-blacklis-checks=1|0"
or similar, defaulting to off if you're worried about efficiency.
> 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.
I can come up with local figures, but knowing globally what features of
spamdyke are used how often is probably impossible.
> 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.
I can't imagine this latter additional load as being nontrivial, but it
could be measured to some extent using strace -c.
> If all of those numbers were available, my instinct says the advantage
> of your proposed change would be very small at best.
This is still ignoring the unnecessary load on the RBL DNS servers (most of
us are using them for free, yet someone must pay for their maintenance and
bandwidth, so let's not be wasteful).
Also, I still think that in the case of email service, saving wall time
(i.e. reducing latency) is more beneficial than saving CPU time (probably a
minuscule amount of CPU time, at that). I find a net gain of 9 seconds per
message with a single bogus recipient hard to ignore.
Andras
--
Andras Korn <korn at chardonnay.math.bme.hu>
<http://chardonnay.math.bme.hu/~korn/> QOTD:
History will record it. I know it because I'll write it myself.
_______________________________________________
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
