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.