Milter-greylist

Steger Wolfgang wrote:
 > Ok., it's a week since you asked, but here are some ideas 
 > about the way greylisting works. Hopefully I did not get 
 > it all wrong.
 > 
 > If you run greylisting *before* user check, it won't make any 
 > difference, as the trick is, that the same combination of
 > sender IP, sender & recipient address "never" comes again in 
 > a SPAM message.

How would that change if the recipient check comes first?
The recipient check doesn't change the IP/sender/recipient
tuple, so greylisting would work just as well afterwards.
In fact it would work *better* because the tuple database
will be much smaller, since it won't be "spammed" with
invalid users that won't receive any mail anyway.

In a similar way, sendmail's "greet_pause" feature rejects
connections that violate the SMTP protocol at the very
beginning (also *before* greylisting comes into play, and
before the recipient check).  This also reduces the grey-
listing load.

As a rule of thumb, the various rejection and anti-spam
measures should be executed in the order of complexity.
That is, features that cost almost zero CPU time should
come first, such as greet_pause.  Then check the IP for
various blacklists (doesn't cost much CPU either).  The
next thing should be to check for valid recipients,
because the recipients have to be checked anyway, sooner
or later.  The next thing is greylisting.  And finally,
messages that still haven't been rejected will be given
to more complex antispam software such as spamassassin
or dspam, or pass it through www.surbl.org and similar
services.

Of course, there might be cases where it's different.
For example, if your server is *not* targeted by a large
amount of spam to non-existent users *and* your recipient
checks are expensive (because of a slow LDAP server or
whatever), then it might make sense to greylist before
the recipient check.

 > Also, if you are sending out non-deliverable-messages for 
 > nonexistant recipients: on SPAM they will either be bounced
 > (because the sender does not exist) or reach somebody innocent.

No, you're not sending out any non-deliverable messages
during the envelope phase (before DATA phase), which is
where the recipient checks happen, because the message
won't be accepted in the first place.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Gesch\ufffdftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M\ufffdn-
chen, HRB 125758,  Gesch\ufffdftsf\ufffdhrer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"The most important decision in [programming] language design
concerns what is to be left out."  --  Niklaus Wirth