Joel Aelwyn <[EMAIL PROTECTED]> 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
