John Hardin wrote: >>> Igor, you might also want to implement greylisting, to give the URIBLs a >>> chance to list URIs that appear in these messages.
Ned Slider responded: >> Interesting concept - do you have any data to support the hypothesis? John Hardin shrugged: > Nope. I have anecdotal evidence supporting it; after I train+report a spam, I have SA parse it a second time. On occasion, it has hit another spamtrap or two (in addition to hits from the places I reported it to: DCC, Pyzor, SpamCop, and my local Bayesian db), though perhaps it had hit some of the places I was reporting to as well. Here's a logical defense if you prefer: Many MTAs now implement some sort of delay (mine uses 1.8s) before anything can happen in an SMTP transaction. This has the direct benefit of stopping some spam bots from delivering mail (supporting data: http://acme.com/mail_filtering/sendmail_config.html ), but it also has a second benefit: spam can't be sent out so quickly when so many of its recipients force it to wait for delivery. So if you're at the beginning of a blasting of spam and a spamtrap is later on, or if somebody has reported the message after it was delivered to you, it will appear in the online indexes (and not just URIBLs; don't forget DNSBLs and all the hash-sharing systems). Like the delay before the SMTP greeting, greylisting is a great way to stop spam botnets. The secondary benefit of delayed network tests in SA is often overlooked as it is admittedly far less profound than the first benefit.
