On Fri, 2005-03-04 at 12:53 +0100, Tom Kistner wrote:
> Clogging up remote queues, delaying bona fide emails ...
Those are the two major problems with greylisting, it's true. You can do
a lot to alleviate those two problems though.
Firstly, you don't ever greylist mail hosts which are actually known to
have queues. If you greylist a mail and it's later retried, there is
_no_ point in ever greylisting any further mail from the same host. You
might as well just accept it in future.
Secondly, you shouldn't just greylist _everything_ that's offered. Do it
only for mail which is at least slightly suspicious.
The greylisting implementation I'm currently playing with is very simple
-- it's in
http://david.woodhou.se/eximconf/include/acl-greylist and
depends on the mail being marked 'suspicious' by having $acl_m0 set
elsewhere by acl-content and/or acl-mime.
If a mail is accepted after greylisting, the host which _originally_
offered that mail is automatically exempted from greylisting in future.
Mail is considered for greylisting only if there's something suspicious
about it -- either having more than zero SpamAssassin points, looking
like a fake reply ('Re:' in Subject but no References), coming from a
host without good reverse DNS _and_ without a CSA record authorising its
HELO, being HTML, etc.
I can't offer data on how well it works yet, because I've only just
rolled it out -- I _really_ need to start using sqlite instead of the
'${run {sh -c "echo blah >> LSEARCHDATAFILE"}' hack, or at least use
daily greylist-db files and just delete the ones which are older than a
week, and perhaps think about a nightly cron job to make a cdb from the
'greylist-known-resenders' when that grows larger.
--
dwmw2
