[H-GEN] People's thoughts on Greylisting

[Greg Black]

On 2005-11-25, Bruce Campbell wrote:
> For those who don't know what it is, Greylisting is a method of delaying 
> the acceptance of email at the SMTP level to ensure that only 'real' email 
> is received by the server, and works because SMTP has an inbuilt retry 
> mechanism after a server receives a temporary failure from a remote site.
> 'Unreal' email doesn't get through because the senders of such crud 
> generally don't bother to retry sending the mail.
> 
> Have people used it or encountered it?  What are your thoughts on the 
> method or implementations that you have seen ?

When the original paper[1] was published, I read it hoping that
it would provide something useful to me in my struggle with what
was becoming an overwhelming amount of spam.  The basic idea
seemed good--but, as always, the devil is in the details.
People who are playing along will need to be familiar with that
paper to follow the rest of this post.

The details in this case are an outcome of the otherwise good
thing that there are many MTAs and MUAs in the wild--leading to
inconsistent (and sometimes buggy) implementations.

The original paper actually lists two significant issues with
greylisting that, to the best of my knowledge, have not been
addressed:

  1. Some large ISPs use a rotating pool of servers to handle
     outgoing email, so that it's possible for an email to time
     out from the sender's perspective before the original host
     happens to be called upon to attempt a second delivery.
     This can lead to lost email.  (In my case, I have some
     customers who use such services, so I can't afford to take
     this risk.)

  2. Some mailing lists (in particular ezmlm, which is still
     widely-used but not in active development) use a variation
     on VERPs that breaks the greylisting proposal.  The paper
     suggests manually whitelisting such lists, but this defeats
     the entire purpose of having an automated system and simply
     doesn't scale.  Suggesting that mailing list traffic is not
     timely anyway and that additional delays in delivery don't
     matter doesn't fit with my needs either.

For those reasons, I decided to adopt other measures to cut down
on spam.  I have modified qmail to check for valid recipients at
SMTP time so that it can refuse such email on the spot (rather
than the standard qmail behaviour of accepting everything and
then deciding what to do with it--which effectively means that
qmail sites have to accept everything, since subsequent bounce
generation is not acceptable behaviour in today's internet,
where most badly-addressed email is also from forged senders).

And I have implemented Bayesian spam filters to cut down on the
spam addressed to real people.

These two measures have reduced my daily spam load from a level
that made email useless to a level that I can easily manage.  I
provide some extra details in an article on my blog[2].  Since I
wrote that, the figures have deteriorated very slightly: I'm now
seeing 15 spams per day and the SpamAssassin detection rate has
dropped to 93.5%.  But I'm happy enough with that and I have yet
to try Dspam, which is on my todo list for early next year.  For
me, the good thing about what I have now is that it's basically
self-maintaining and does not require tweaking to maintain its
effectiveness.

So, although I know plenty of people are happy with greylisting,
I'm not going to try it; the problems with it seem like too high
a price to pay for what would be, at most, a limited return.

Cheers, Greg

----------
[1] http://greylisting.org/articles/whitepaper.shtml
[2] http://www.gbch.net/gjb/blog/software/discuss/spamassassin.html