Hello,
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
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp