Re: RFC3463, 450 reply codes, and 4.7.1 extended codes.

Claus,

A few points:

First, I think a key point about what makes greylisting or any other c/r
(challenge/response) retry logic currently attractive is the current
operational behavior with spammers (professional typically bulk sending
systems)  who do not currently respect or honor the "retry logic."    Only
good legitimate systems follows the rules which is why it does work in this
regard.  The good system will retry. "Bad" systems do not.  That's the
theory behind greylisting.

Second, extended response status codes are optional.  You can't base any
client retry logic on it. It has to remain based on the required response
codes (4xx, 5xx) for backward compatibility.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com


----- Original Message -----
From: "Claus Assmann" <ietf-smtp(_at_)esmtp(_dot_)org>
To: <ietf-smtp(_at_)imc(_dot_)org>
Sent: Monday, May 09, 2005 11:20 AM
Subject: Re: RFC3463, 450 reply codes, and 4.7.1 extended codes.



On Mon, May 09, 2005, John Leslie wrote:

>    What is the _benefit_ of telling a spammer you're greylisting him?
How do you know it's a spammer that is subject to greylisting?

As more and more systems deploy greylisting the effect on legitimate
mail clients is getting significant. Especially bad are those domain
which have multiple MX servers. Here's what happened (and which
originally triggered this question that I asked on a different list):

My system sends out mail to a small mailing list. As this happen
infrequently the IP address/sender is usually already "expired"
from the "white lists" of systems that deploy "greylisting".  Hence
almost every time the mail is subject to being delayed by several
servers. At least one of them has 4 MX servers which means that my
MTA tries all of them just to receive:

451 4.7.1 Greylisting in action, please come back in 01:00:00
451 4.7.1 Greylisting in action, please come back in 00:59:56
451 4.7.1 Greylisting in action, please come back in 00:59:53
451 4.7.1 Greylisting in action, please come back in 00:59:51

(or some similar text) in reply. Now the question is: how can I
tell my MTA not to try another MX server[1]? One idea is to have a
specific enhanced status code to do that: that might be either an
existing code (4.7.1 has been suggested) or a new one.

I would prefer a new one because such a code could be used for
different cases (e.g., if the recipient address can currently not
be identified because some name service is down). So if we use
4.10.x for "temporary error: do NOT try another MX" then we don't
have to overload exactly one code to have this effect.


[1] I know that some MTAs do not try another MX server after having
successfully established a connection with one. However, most MTAs
nowadays try another MX server on pretty much any temporary error
during a session/transaction.