Thank you for your reply, Peter!
Peter J. Holzer wrote:
Hmm. If you are running a domain with catch-all, worrying about the
efficiency of reading/writing a single record in a dbm file seems like
putting the cart before the horse to me.
Ok, got that. Will greylisting ever purge records, or does the dbm file
grow indefinitely?
I'd try to modify check_verybadrcptto to simply return DENY_DISCONNECT
in the recpipient handler and remove hook_data. That's against the idea
of check_verybadrcptto, but it's probably closer to what you want.
No, I don't want to make it that easy for the spammers to clean their
list. If I disconnect on RCPT and their software has only a little
smarts, it will reconnect and try the next address. That way I'd lose
the protection that check_verybadrcptto gives to the good addresses.
check_verybadrcptto works so well that I'm thinking about adding
invisible "guard" addresses on web pages where I've published real
addresses. (I've obfuscated them of course, but over time they still
leak out.)
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.
I think using deny_late is usually a mistake. I can't think of a
scenario where it's actually useful.
My thinking was along these lines: if I can end a transaction with DENY
rather than DENYSOFT, then it's worth the extra effort, because the
spammer is less likely to come back as quickly. So, to give
check_verybadrcptto precedence over greylisting, I have to run
greylisting with deny_late, or am I missing something?
BTW, I had a bogus bouncer retry every 3 seconds (without ever
disconnecting!) until the black period turned grey. Seems like there
should be a counter in greylisting...
It would also be nice, if a plugin like check_verybadrcptto could
somehow signal that the transaction is doomed, so that other, more
expensive plugins could tell that they don't need to run anymore.
I think that in that case the plugin should return DENY_DISCONNECT or
DENYSOFT_DISCONNECT. There's little point in keeping the connection open
if it is doomed (unless you're running a spamtrap, but then you probably
don't worry about expensive plugins).
Well, I guess you could call my way of running check_verybadrcptto a
mini-spamtrap (see above).
Not that I go out and actively attract spam, but I've fed some 40,000
pieces of spam into SpamCop. Now I've turned to qpsmtpd because I'm
getting a bit tired of this game, but if I could easily forward the
verybadrcptto's, I'd do it right away!
This would mean to hang on to doomed transactions all the way to the end
and to redirect rather than reject the spam that was identified
positively...
Hans
