On Sun, Apr 13, 2008 at 02:55:16PM -0500, Sam Clippinger wrote:
> Andras Korn wrote:
> > I don't agree. These days, there are RBLs that will automatically list and
> > delist IPs in the space of a few hours, well within the lifetime of a single
> > email message.
>
> If a server is being added and removed from RBLs in the space of a few
> hours, its behavior must be just on the border between "legitimate" and
> "spammer". In that case, I would think the administrator would want to
> know about it by receiving a few complaints from users whose messages
> were being bounced.
Again, let's agree to disagree. :)
> You started this thread with a complaint that temporary rejections were
> needlessly consuming your server resources by causing the remote server
> to retry deliveries multiple times. I guarantee that making the RBL
> filter return temporary rejection codes would waste considerably more
> resources for everyone, as RBLs are much more common and more widely
> used than RHSBLs.
In a way, that is true. However, if you allowed qmail to permanently reject
some of the spam (because it's addressed to a bogus recipient), the
temporary rejections wouldn't make that much of a difference because there
wouldn't be so many of them.
The added load caused by RBL-based temporary rejections I'm willing to
accept.
> > rblsmtpd also uses temporary rejects, fwiw.
>
> Well, most of the major email providers (AOL, Yahoo!, GMail, Hotmail,
> etc) use permanent rejections for RBL matches.
They probably use their own RBLs though, don't they? Also, they have
hundreds of thousands of users, so they aren't going to care about any
particular message not getting through.
At smaller sites, it's possible to keep a virtual eye on the qmail log (say,
using a script) that can alert you when some new type of mail is being
blocked. It's nice to be able to interfere.
> > Temporary rejects also give the administrator a chance to whitelist an IP
> > they do want to receive mail from (such as when it turns out that your new
> > business partner's ISP just got blacklisted by an RBL).
>
> The administrator would have to be carefully watching the outbound queue
> to notice a message was being held, then investigate the logs to find
> out why. I can't envision this happening unless the server is new and
> the administrator is testing to make sure everything is working.
I didn't mean the administrator of the server sending the message, but the
admin of the server rejecting it. I've often manually whitelisted IPs
blocked by one RBL or the other. I have found this to be practically the
only way to use RBLs run by 3rd parties to block mail (instead of just
increasing their spamminess score in SpamAssassin).
> I understand now.
>
> What you're describing would make spamdyke more efficient only for users
> who have modified/replaced their qmail-smtpd to support blacklists or
> other filters.
Yes.
> 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.
> On a stock qmail installation, this change would make spamdyke _less_
> efficient, since it would keep qmail running for all connections, at
> least until the DATA command is given.
Yes, if you only consider the single server spamdyke and qmail are running
on. But issuing needless DNS queries also puts supefluous load on the local
caching DNS resolver and the DNS servers of the RBLs/RHSBLs. Wouldn't it be
a courtesy to them to not query their servers if a local decision can be
made to reject a message?
Also, local decisions have lower latency. It may be possible to reject a
message based on local tests in less wall time than by waiting for the RBLs;
thus, a higher connection rate could potentially be served, because many
connections would end sooner.
> However, the current code closes qmail as soon as possible to free up
> resources.
"As soon as possible" in terms of the SMTP conversation, certainly; but not
as soon as possible in real time, I'm pretty sure.
> "As soon as possible" depends on the configured filters -- the possibility
> of SMTP AUTH and the use of sender whitelists require qmail to continue
> running until "MAIL FROM" is seen. The use of recipient whitelists
> require qmail to continue running until "RCPT TO" is seen. But if
> spamdyke is configured to do graylisting, some RBLs, some rDNS tests and
> SMTP AUTH (a typical setup), qmail will be closed as soon as the "MAIL
> FROM" command is given.
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.
> 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.
Andras
--
Andras Korn <korn at chardonnay.math.bme.hu>
<http://chardonnay.math.bme.hu/~korn/> QOTD:
Mental Floss prevents Moral Decay.
_______________________________________________
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
