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.