[Top] [All Lists]

[ietf-smtp] RFC5321 delivery to secondary MX after timeout

2016-02-26 09:36:10

I have recently gotten myself into an argument with a vendor about RFC5321 and what constitutes a successful "delivery attempt", in a specific case when TCP/IP connection to primary MX succeeds but e-mail delivery fails either with a 4yz code or a timeout.

There is a slight ambiguity between RFC5321 section 5.1 (and also RFC2821 section 5) which says:
   ... To provide reliable
   mail transmission, the SMTP client MUST be able to try (and retry)
   each of the relevant addresses in this list [MX->A/AAAA] in order, until a
   delivery attempt succeeds.

and section 4.2.1/4yz which says:
   ...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).
also combined with section 3.8 which says to treat timeouts as a 451 code.

I could not find a strict definition of a "successful delivery attempt" though section 4.2.5 (DATA+<CRLF>.<CRLF>+2yz reply) is the closest I figure.

Consider a domain which has a broken primary MX relay (e.g. a broken antispam/antivirus feature). The SMTP dialogue will end with a 4yz code (or a timeout) and will keep doing so until an administrator intervenes. Other relay MXs with higher priorities may be working just fine.
The sending MTA has two options:
A) go with sect.4.2.1 and always retry the same receiving server; or
B) go with sect.5.1 and try another address.

I think B is the correct behavior which is how e.g. Postfix implements it. The vendor in question says that if the TCP/IP successfully connected on port 25/tcp, then they only need to retry the same server over and over again, and that this is correct per RFC5321.

The trouble with A is that user messages are queued and never delivered from senders that implement it this way, while the target is still receiving email from other senders. The trouble with B is that the administrator with improper monitoring of the relay MX may never find out their primary MX is malfunctioning until secondaries fail, too.

I do not wish for you to be the judge in my argument with the vendor, still I think the ambiguity (or a definition of successful delivery) should be cleared up in possible future revisions of the RFC.

Best Regards,

Matej Sustr

ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>