Top line is that a deny with message is more informative to a legitimate sender than bouncing for a week, and less bounce handling is good for us. Can't say what joe_ok might deliver on the bottom line as far as blocking spam. joe_ok gathers data on joe-jobbers which may reveal some as yet unidentified pattern of overlap with spam sent to correct addresses from the same IP or From. I find the data http://deadfam.com/joe/ interesting, but you may prefer TV or attending live baseball games--not to say venture onto the field of dreams there. Maybe I'm making too much out of joe, and he would just fade away if I paid him less attention. Can I afford to obsess and rage, from a health point of view, as far as blood pressure, ulcers, adrenaline ketosis? Dunno, can't say, but joe_ok can deliver informative denies and less bounce handling today(locally anyway).
Before I show you the joe_ok plugin I'll have to calm it down to a test-only mode which databases and logs like this http://deadfam.com/joe/ but does not deny. It mimics rcpt_ok if there is no ./config/rcptusers, or if in test-mode with ./config/rcptusers, and then it would only database and log unless rcpt_ok would deny. There is more in the database hash than in the log line format examples at http://deadfam.com/joe/
joe_ok notifies legitimate senders at rcpt hook with DENY and a no-such-user message if user or vuser(only looks at rcptusers) not there, but never denies To postmaster or abuse or mailer-daemon. Then if the spelling is atrocious it assumes dictionary scan or somebody purchased a poor quality dictionary scan output list(they got hustled, bought fake addresses, but we don't sympathize, just give the same no-such message as if they were legit typo or dyslexic) and is spamming. It checks for relay-client, and whitelisting.
joe_ok never blacklists a To but it can shield To's from IP/Froms. It can honeypot-store messages by diverting the queue for that message. It has a tarpit sub which has no code in it yet. Blacklisting, honeypot message storage and tarpitting are command line options set in ./config/plugins.
One question I have is whether there will more of a cross-over between source IP's and addresses marked as bad for sending joe-jobs when there is a lot of legitimate traffic. On my machine the joe-jobbers don't know a single one of my legitimate IP's, so I'm looking for cross-overs of IP's and Froms between the joe names. I'm wondering how many positives I'll get for joe-jobber IP's and Froms sending to legitimate users, in other words. I'm hoping it's a small world, if not, make it smaller by peering the elho_and_from.dbm(To's filtered out).
By the way, neither the greylisting plugin or this plugin does any expiring of database keys other than when they are accessed. That means expired but never-again or seldom- accessed keys bloat the databases. I guess the expiry checkers should write the day to a key in their db hash, and walk the db has once a day. The joe_ok db pruner ought to delete 30 days or some limit after black_timeout so as to retain the counts and associations longer than the black_timeout, effecting a parole/probation period.
-Bob Dodds
