I’ve been meaning to collate a page about why I don’t like
greylisting. My previous
posting is relatively useful, but it needs an update, so here it is:
First off, every single message is delayed until a database match is found for the combination of sending IP, envelope-from and envelope-to. As Alan Leghart pointed out, ‘So…we punish everyone in the world, and hope that a delay of one or more hours is considered ‘acceptable’? Maybe some people already expect a mail to take several hours to reach a recipient. In that case, you need to fix your mail server.’
Secondly, large mailing lists that use VERP (generating keyed From addresses for each mail for good bounce-handling) will require manual whitelisting for each list, or each host.
Yahoo! Groups, for example,
uses VERP for all its lists, and also will not retry delivery
if the first attempt fails.
There’s even
buggy SMTP servers that do not support retrying, believe it or not.
(Once again, as for many spamfilter designs, the unusual SMTP clients
are the ‘edge cases’ that cause the most trouble.)
Manual whitelisting == work == what spam filtering is trying to reduce
== bad.
Thirdly, and most seriously, it assumes spammers would never introduce
retries into their spam-tools if it took off. Tempfailing, what this is
based on, is effective right now because spamtools don’t retry. But
every proposed spam solution has to consider what would happen if every
server admin in the world implements it, and spammers then want to
subvert it.
For a spamtool to retry, it just needs to track 4xx responses, and if it
encounters one, save these items of data:
-
From, To addrs and HELO string used
-
proxy IP used (btw proxies are almost never shut down successfully, so the spammer can generally assume this can be reused next time)
-
random seed used to generate random hashbuster tokens etc., so the body text matches
That’s really not a lot of data — 64 bytes per address that requires a retry. Then, an hour or more later, do the retry.
So, IMO, ‘greylisting‘ will work fine in the short term, until it becomes
reasonably common — then the spamtool developers will start adding retry
code.
Then we’re back to square one — except some legit mail takes much
longer to get delivered, and the bandwidth wasted by spam has doubled,
due to all those retrying spams. That’s not really progress.