On Sun, Apr 13, 2008 at 12:29:51PM -0500, Sam Clippinger wrote:
> RBL rejections use permanent codes. This is because an RBL/RHSBL match
> is permanent within the lifetime of an email message -- the situation
> won't change in a few minutes, so there's no point in retrying multiple
> times. A human must intervene and correct the situation before any
> email can be delivered.
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.
rblsmtpd also uses temporary rejects, fwiw.
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).
Permanent rejects are less of a problem with RHSBLs because those are less
ephemeral and whether a domain is being used for spamming or not doesn't
change that quickly.
> Regarding the delayed checking of recipient filters, let me spell this
> out as I understand your suggestion. The process would look like this:
> Remote server connects, spamdyke and qmail start.
> QMAIL->SPAMDYKE: 220 qmail ESMTP
> SPAMDYKE->REMOTE: 220 qmail ESMTP
> REMOTE->SPAMDYKE: HELO myname
> SPAMDYKE->QMAIL: HELO myname
> QMAIL->SPAMDYKE: 250 Hello, pleased to meet you.
> SPAMDYKE->REMOTE: 250 Hello, pleased to meet you.
> REMOTE->SPAMDYKE: MAIL FROM:<[EMAIL PROTECTED]>
> SPAMDYKE->QMAIL: MAIL FROM:<[EMAIL PROTECTED]>
> QMAIL->SPAMDYKE: 250 OK
> SPAMDYKE->REMOTE: 250 OK
> REMOTE->SPAMDYKE: RCPT TO:<[EMAIL PROTECTED]>
> At this point, you're suggesting that spamdyke pass the recipient to
> qmail first, without running its own filters. That would look like this:
No. What I was suggesting was that if spamdyke can decide at this point that
the recipient is invalid, it should of course reject it.
_But_ it should hold off on all DNS queries until it receives a DATA verb
from the client.
> [...]
All of this is perfectly valid and true, but it's not what I was suggesting.
Let me try to rephrase it.
Currently, what happens is this (IIRC):
1. client 1.2.3.4 connects.
2. spamdyke checks rdns, RBLs, blacklists and whitelists, rejects message if
necessary.
3. client issues HELO/EHLO.
4. spamdyke checks DNS, rejects message if necessary.
5. spamdyke forwards HELO to qmail.
6. client issues MAIL FROM.
7. spamdyke checks DNS, RHSBLs, blacklists and whitelists, rejects message
if necessary.
8. spamdyke forwards MAIL FROM to qmail.
9. client issues RCPT TO.
10. spamdyke consults localdomains, blacklists, whitelists, relay access and
whatnot; rejects receipient if necessary.
11. spamdyke forwards recipient to qmail.
12. repeat 9-11 until client issues DATA.
13. spamdyke forwards DATA to qmail.
14. actual message is transferred.
What I suggest is to skip all DNS based tests until just before step 13. If
qmail accepted none of the recipients (including the case where it didn't
even get to see them because they were filtered by spamdyke), there is
nothing to do and we saved some slow DNS queries.
If some recipients were accepted, spamdyke does the DNS lookups and if they
indicate that the message should be rejected, it sends an appropriate 45x or
55x response to the DATA command of the client. Instead of DATA, it sends
QUIT to qmail.
With "DNS lookups" I mainly mean RBL and RHSBL lookups, because there are
potentially many of those; there is normally no need to hold back on rdns,
as tcpserver will/may have attempted it anyway, so the response, if any,
should be in the DNS cache already.
Andras
Ps. not that it matters, but by buffering the list of recipients there is
still a way out in the situation you described (which doesn't however arise
in the scheme I am suggesting): just kill the qmail-smtpd child and spawn
another, but don't give it that particular recipient address. I'm only
including this footnote because this approach could conceivably be useful in
other situations.
--
Andras Korn <korn at chardonnay.math.bme.hu>
<http://chardonnay.math.bme.hu/~korn/> QOTD:
I'd like to live like a poor person with lots of money.
_______________________________________________
spamdyke-users mailing list
[email protected]
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
