Thanks for your reply, Gavin!
Gavin Carr wrote:
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)?
All of these :-)
I have no idea how expensive the dbm work is, but I've probably spent
too much time looking through the INFO log. The most frequent scenario
is this: the spambot knocks, is entered into the dbm, denied by
check_verybadrcptto, and never seen again. Some are more persistent and
keep coming back, so they end up white, but they still get denied by
check_verybadrcptto. That's 80% of my traffic, and it seems backwards,
because it could be handled by check_verybadrcptto alone.
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.
I'm pretty new to qpsmtpd and I still get a kick out of looking through
the log. If you like inspecting the db as much as I like checking the
log, then I agree. But -- entering a transaction into the db means
giving the sender a chance to become white. Why would you offer that
privilege to a sender that might turn out to be a spammer at the next step?
It might make sense to hook_deny in greylisting and to remove records
from transactions that are denied, but wouldn't it be easier to just not
create them in the first place?
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.
Bingo! I'll try that!
Hans
