ietf-smtp
[Top] [All Lists]

Fixing graylisting [was TBR]

2007-11-13 09:35:07

Tony Finch <dot(_at_)dotat(_dot_)at> wrote:

I agree that it is a worthwhile goal to reduce the interop problems of
greylisting, and I agree that delaying email from unknown sources might
give blacklists time to make a decision about the source.

I think it would be more useful for you to try to fix greylisting than to
redesign IM2000 yet again.

   An interesting challenge!

   I quite agree that graylisting needs fixing (and Doug and I did try
to sneak some fixing into TBR).

   Graylisting, IMHO, started with a simple observation that many botnets
would only try once; thus giving 50% temporary errors (blindly) would
reduce botnet spam by 50%. Obviously, spam increased to fill the vacuum,
proving that a 50% solution is effectively no solution at all.

   Graylisting progressed to a realization that botnet spammers didn't
keep state, while genuine MTAs did. Thus graylisters now try to notice
which incoming emails are the result of running the queue of previous
tries which you gave temporory errors to. This is much better, but it
is difficult because the SMTP protocol does nothing to help.

   I look upon graylisting as a temporary measure to gain time for
better information about the sender -- not just whether they keep state
and run the queues.

   We could in principle accomplish that by keeping the SMTP connection
open for however long that takes; but this feels wrong to me: it's
probably cheaper for the spammer to keep a botnet connection open than
it is for me to keep TCP state for a million spams.

   The "fix" Doug and I put into TBR is to extend the time to formal
handoff, by any amount the receiving mail system may choose, which
accomplishes much of what keeping the TCP connection open would -- at
a far smaller cost (the queue of URIs could be written to disk, for
one example).

   A part of the problem which remains unfixed is how long the sender
should expect to wait. Doug and I despaired of fixing this.

   We did add an error message saying, in essence, "You are being
graylisted." We're of the opinion that any further information should
be out-of-band (or at least not part of protocol).

   What would others like to see in a fix for graylisting?

--
John Leslie <john(_at_)jlc(_dot_)net>