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.
The only DNS-related filters that send temporary rejection codes are
those that could be triggered by no response from a DNS server. In
other words, reject-empty-rdns, reject-unresolvable-rdns and
reject-missing-sender-mx. If the DNS server is slow or overloaded,
retrying in a few minutes could allow delivery because the DNS server
may have recovered in that time. Beyond those, graylisting, timeouts
and max-recipients send temporary rejections. All other filters send
permanent rejections.
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:
SPAMDYKE->QMAIL: RCPT TO:<[EMAIL PROTECTED]>
QMAIL->SPAMDYKE: 250 OK
qmail did not reject the recipient, so spamdyke runs its filters and
decides the recipient should be blocked. So it sends a rejection to the
remote server.
SPAMDYKE->REMOTE: 554 Recipient rejected.
Then a valid recipient is sent:
REMOTE->SPAMDYKE: RCPT TO:<[EMAIL PROTECTED]>
SPAMDYKE->QMAIL: RCPT TO:<[EMAIL PROTECTED]>
QMAIL->SPAMDYKE: 250 OK
SPAMDYKE->REMOTE: 250 OK
After that, the message is delivered:
REMOTE->SPAMDYKE: DATA
SPAMDYKE->QMAIL: DATA
QMAIL->SPAMDYKE: 354 Proceed.
SPAMDYKE->REMOTE: 354 Proceed.
REMOTE->SPAMDYKE: (message data)
SPAMDYKE->QMAIL: (message data)
QMAIL->SPAMDYKE: 250 Accepted.
SPAMDYKE->REMOTE: 250 Accepted.
REMOTE->SPAMDYKE: QUIT
SPAMDYKE->QMAIL: QUIT
QMAIL->SPAMDYKE: 221 Bye.
SPAMDYKE->REMOTE: 221 Bye.
From the remote server's point of view, the conversation looked like this:
Remote server connects, spamdyke and qmail start.
SPAMDYKE->REMOTE: 220 qmail ESMTP
REMOTE->SPAMDYKE: HELO myname
SPAMDYKE->REMOTE: 250 Hello, pleased to meet you.
REMOTE->SPAMDYKE: MAIL FROM:<[EMAIL PROTECTED]>
SPAMDYKE->REMOTE: 250 OK
REMOTE->SPAMDYKE: RCPT TO:<[EMAIL PROTECTED]>
SPAMDYKE->REMOTE: 554 Recipient rejected.
REMOTE->SPAMDYKE: RCPT TO:<[EMAIL PROTECTED]>
SPAMDYKE->REMOTE: 250 OK
REMOTE->SPAMDYKE: DATA
SPAMDYKE->REMOTE: 354 Proceed.
REMOTE->SPAMDYKE: (message data)
SPAMDYKE->REMOTE: 250 Accepted.
REMOTE->SPAMDYKE: QUIT
SPAMDYKE->REMOTE: 221 Bye.
One recipient was accepted and one was rejected.
But from qmail's point of view, the conversation looked like this:
Remote server connects, spamdyke and qmail start.
QMAIL->SPAMDYKE: 220 qmail ESMTP
SPAMDYKE->QMAIL: HELO myname
QMAIL->SPAMDYKE: 250 Hello, pleased to meet you.
SPAMDYKE->QMAIL: MAIL FROM:<[EMAIL PROTECTED]>
QMAIL->SPAMDYKE: 250 OK
SPAMDYKE->QMAIL: RCPT TO:<[EMAIL PROTECTED]>
QMAIL->SPAMDYKE: 250 OK
SPAMDYKE->QMAIL: RCPT TO:<[EMAIL PROTECTED]>
QMAIL->SPAMDYKE: 250 OK
SPAMDYKE->QMAIL: DATA
QMAIL->SPAMDYKE: 354 Proceed.
SPAMDYKE->QMAIL: (message data)
QMAIL->SPAMDYKE: 250 Accepted.
SPAMDYKE->QMAIL: QUIT
QMAIL->SPAMDYKE: 221 Bye.
Two recipients were given and both were accepted. Both recipients will
receive the message. If that happens, it's like spamdyke isn't
installed at all -- all mail will get through no matter what.
-- Sam Clippinger
Andras Korn wrote:
> On Sat, Apr 12, 2008 at 06:10:04PM -0500, Sam Clippinger wrote:
>
>> The RHSBL filter checks rDNS names and sender addresses, not recipient
>> addresses.
>
> I know.
>
>> It also produces permanent rejection codes, not temporary ones.
>
> OK, with RHSBL, that is probably justified. However, I hope RBL by default
> produces temporary rejects?
>
>> If you're seeing the same sender rejected repeatedly, it's because the
>> remote server is sending repeatedly.
>
> Strange that they didn't do it so far, but apparently this is the case.
>
>> Also, spamdyke should be disconnecting (and killing) qmail as soon as
>> the blacklisted sender is given (depending on your configuration -- if
>> you're using a recipient whitelist, qmail is disconnected after the RCPT
>> command). After that, all SMTP traffic is answered by spamdyke (with
>> rejection codes). So at least for that short time, spamdyke is saving
>> resources.
>>
>> However, with regard to blacklisted recipients, the reason spamdyke runs
>> its filters before passing the RCPT command to qmail is because there
>> may be multiple recipients. Once a recipient has been passed to qmail,
>> it cannot be removed. Passing the RCPT command just to check the status
>> code would effectively defeat spamdyke.
>>
>> For example, imagine an unpatched qmail server. The remote server names
>> a blacklisted recipient, spamdyke passes it to qmail, checks the status
>> code, then sends a rejection to the remote server. Then the remote
>> server names a second recipient that is not blacklisted. spamdyke must
>> allow the message to pass through because the second recipient is
>> legitimate. However, because the first recipient was already sent to
>> qmail, that recipient will also receive the message.
>
> I'm not sure I understand what you're saying.
>
> If a recipient is blacklisted in spamdyke, spamdyke should of course reject
> it.
>
> If it is blacklisted by qmail, qmail will reject it and spamdyke needn't
> worry about it.
>
> The SMTP conversation can continue, with each recipient specified by the
> client being treated as above.
>
> Finally, if any recipients were accepted by the backend qmail, spamdyke can
> check RBL and RHSBL, and if there is a match, reject the client temporarily
> (for RBL) or permanently (in the case of RHSBL), and send a QUIT to the
> backend qmail.
>
> The costly DNS lookups needn't be performed at all if qmail rejects all
> recipients.
>
> I see no situation where this scheme would result in mail being passed to
> recipients who would otherwise not receive it.
>
> I think all feasible local tests should be carried out before resorting to
> remote tests, because those can be (and typically are) much slower.
>
> Andras
>
_______________________________________________
spamdyke-users mailing list
[email protected]
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
