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
--
Andras Korn <korn at chardonnay.math.bme.hu>
<http://chardonnay.math.bme.hu/~korn/> QOTD:
When I was your age, we had to walk ten miles to a node.
_______________________________________________
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
