On 8/30/2006 12:07 PM, Alex van den Bogaerdt wrote:
On Wed, Aug 30, 2006 at 11:39:51AM -0400, Eric A. Hall wrote:
You should requeue the message for later delivery.
You did not fail to connect.
That's not what 450 indicates.
450 Requested mail action not taken: mailbox unavailable [E.g., mailbox busy]
This could very well be a problem on the MX itself. It is not unreasonable to
try another mail exchanger that may be able to receive the message.
It may not be unreasonable but its not a safe assumption either, such as
when MXs are multiplexing in front of a cluster. Worse, if every MX has
its own greylist then you're just wasting everybody's time by banging on
all of them in sequence.
450 isn't defined for use with DATA either, btw, which is probably the
source of most of the confusion in this area (I've gone through this same
debate elsewhere recently and likely to have it again as greylisting picks
up). 451 and 452 are the only two 4xx codes that are defined for it to my
knowledge. It would probably help things to have a clarification
statement, specifically as regards to 450 after DATA, which would map
pretty well to "temporary policy problem".
RFC974 has this to say:
"Implementors are encouraged to write mailers so that they
try the MXs in order until one of the MXs accepts the message, or all
the MXs have been tried."
Yay, my favorite IETF pastime, fun with scripture
Taken literally that text would also require you to chain through every MX
upon receipt of a 5xx error, and hopefully people aren't doing that.
Also, 974 was obsoleted by 2821, which rephrases the point:
When the lookup succeeds, the mapping can result in a list of
alternative delivery addresses rather than a single address, because
of multiple MX records, multihoming, or both. To provide reliable
mail transmission, the SMTP client MUST be able to try (and retry)
each of the relevant addresses in this list in order, until a
delivery attempt succeeds. However, there MAY also be a configurable
limit on the number of alternate addresses that can be tried. In any
case, the SMTP client SHOULD try at least two addresses.
Note that the cited discussion is about addresses not MX hosts. Certainly
it makes sense to immediately try the next ADDRESS in the list, but that's
about the connection-level stuff, not about in-protocol response codes.
In general the meaning of 4xx should apply
A rule of thumb to determine
whether a reply fits into the 4yz or the 5yz category (see below)
is that replies are 4yz if they can be successful if repeated
without any change in command form or in properties of the sender
or receiver (that is, the command is repeated identically and the
receiver does not put up a new implementation.)
IE, same sender + same reciever + later date = requeue
Perhaps the right thing to do is to scrap that last MX from the list of MXes
to try, keeping the one returning 4xx on the list. Then also discard the 5xx
message and thus end up with 4xx -> retry. Using the new list of MXes, retry
after a reasonable amount of time. If no MX hosts remain on the list, return
the message to its sender.
This would mean keeping records on what MX hosts not to try when retrying to
deliver the message.
It would be an exception to other kinds of 4xx handling too
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/