Re: murphy is listed on spamcop

[Thomas Bushnell BSG <tb@becket.net>]

Joel Aelwyn <fenton@debian.org> writes:

> > The worst case costs of well-implemented graylisting should be
> > something like a short delay in an email message; the worst case of a
> > false positive rejection can be much much worse indeed.
> 
> The worst case for graylisting is the same as a false positive: undelivered
> mail. Yes, there are servers out there that are non-spam (like, for one
> known example, at least one major airline's reservation notification
> system) that don't attempt to re-send on a 4xx code.

A key word has been dropped here, "well-implemented".  :)

I'm not yet sure if graylisting *can* be well-implemented; I would
suggest that in fact graylisting is a protocol violation.  That
doesn't mean you can't do it, but it does mean that you can't describe
graylisting as implementing "your end of the protocol perfectly":

> Note that I'm not going to argue the merits of graylisting vs. other
> methods, or the actual measured costs, except to point out that you can
> implement *your* end of the protocol perfectly, in a way that shouldn't
> cause any mor than a delay, and the other guy can still screw it up for
> you.

More interesting are the cases where the sender is *not* doing
anything wrong, by for example sending from a huge farm of servers
such that the mail comes from a different IP address every time, and
the graylisting recipient keeps returning 4xx.

That can be solved by not returning the 4xx until after the DATA
command has been received, which enable you to detect cases like
this.  But doing so means that you lose the load-saving benefits of
graylisting (though not the spam-filtering ones).

Thomas