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

From: Matej Sustr <[email-masked]>
Date: Fri, 26 Feb 2016 15:42:12 +0100 (CET)

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 26 Feb 2016 15:50:58 +0000

>       does not put up a new implementation).

It says "can be", not "will be in the foreseeable future".

For example, suppose the spool is full. Probably that problem will pass 
quickly, but it doesn't have to. It depends on what filled the spool. The 
"4xy my spool is full" response therefore doesn't guarantee that the spool 
will have free space in the foreseeable future.

A robust SMTP client should try another MX on 4xy.

Arnt

---

From: Paul Smith <[email-masked]>
Date: Fri, 26 Feb 2016 16:14:31 +0000

On 26/02/2016 14:42, Matej Sustr wrote:
> 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

It says 'MUST *be able to* try', not 'MUST try'.

It continues to say:

"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."

So, just trying one address is allowed (but not encouraged) by the standard.

There are arguments both ways.

If I get a 4xx response (eg due to greylisting) then it is entirely 
possible (maybe likely) that I get it from all MX servers, so trying all 
of the servers just adds work for no benefit.

If I can't connect to one server, then I should almost certainly try the 
next one.

If I get a 5xx response, then should I try the other servers or not? By 
your reading of the standard you should, but I'd say probably not. (But 
a 5xx could potentially be 'this server's configuration is totally 
broken' rather than 'that recipient is unrecognised')

In the case of 4xx or 5xx there are reasons you can think of why you 
should or shouldn't try the other servers.