On Sun, Feb 25, 2007 at 10:39:50PM +0100, Hans Salvisberg wrote:
> I run some of my domains with a catch-all address (i.e. no recipient
> checking), and I have a considerable number of retired addresses there.
> Many were never in actual use but have been invented by spammers! With
> this setup check_verybadrcptto takes care of about half of my spam,
> because a lot of spam includes one of the retired addresses in the
> recipient list.
>
> greylisting takes care of much of the remaining spam, but I have to run
> it in deny_late mode, so that check_verybadrcptto can do its work (and
> issue a hard DENY). In deny_late mode, greylisting defers denials until
> hook_data (the documentation says hook_data_post, but this is wrong).
> However it still does its database work in hook_mail and/or hook_rcpt,
> even though a large number of transactions will receive a DENY before
> greylisting ever gets a hook_data call.
>
> It would be nice if the greylisting database work could also be
> postponed until hook_data, when it's actually needed ("lazy
> evaluation"), so that it can be skipped, if some earlier plugin returns
> a DENY.
What's your primary concern here Hans? That noting the connection in
the greylisting db is relatively expensive? Or that you're 'polluting'
the database with connections from IPs that you're going to deny soon
anyway (i.e. more database size)?
I personally like the greylisting db getting updated as soon as all the
relevant information is available, irrespective of whether I'm going to
deny shortly for other reasons anyway. To me it seems simpler and cleaner,
though I can see where you're coming from to.
Note that a workaround/hack would be that if you're greylisting
ip/sender/recipient triples, or if you turn per_recipient configs on,
the greylisting test happens at the rcpt hook, so if you put greylisting
after your check_verybadrcptto plugin, you should get the effect you're
after for free.
Cheers,
Gavin
