John Levine wrote:
Which, if any, of a, d, and r get retried? Why or why not? What if
the 554 were a 421 or 451?
DATA 554 trumps them all. No Retries for this transaction. If this is
not the case, then indeed, it goes on to explain why we have serious
issues for clients mainly but also for servers who has to bear the
burden of clients not following a long time solid state machine and
In your answer, please consider RFC 2821 section 4.2.5, particularly
the suggestion to requeue the message in the antepenultimate paragraph
of that section.
You are referring to:
4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF>
When an SMTP server returns a permanent error status (5yz) code
after the DATA command is completed with <CRLF>.<CRLF>, it MUST
NOT make any subsequent attempt to deliver that message. The
SMTP client retains responsibility for delivery of that message
and may either return it to the user or requeue it for a
subsequent attempt (see section 188.8.131.52).
Ok, it all makes sense now. I will say that the last sentence is
conflictive with the first sensitive. It can't say "MUST NOT
subsequent attempt" yet give the client an option to do so in the last
sentence. Thats a specification conflict and IMV, it SHOULD be fixed
if people seriously believe this is problem. I don't think its a
problem but I hope systems are behaving this way - I don't believe
they are and probably isolated to systems who accept everything and
discard and bounce mail with highly subjective trust concepts. So
even if its a DATA 554, the data was captured and read and it really
doesn't matter if its acknowledge or not.
Thats that to say clients will do what they want - like decide to
requeue. But that one the definitions of insanity:
Believing results will be different when you do the same thing
over and over again.
The main point is that in all the documents, with the exception of the
above, I don't believe there is a technical conflict. Maybe this is
the only sentence that introduces that conflict.
There is a strong tie-in with the social engineering and legal aspect
of computer-based messaging in the form of acceptance and rejection.
Starting with 821, the principle was followed and it was very clear
there is only one form for signaling acceptance, a positive OK
SMTP 821 Section 4.1.1 - COMMAND SEMANTICS
Special mention is needed of the response and further action
required when the processing following the end of mail data
indication is partially successful. This could arise if
after accepting several recipients and the mail data, the
receiver-SMTP finds that the mail data can be successfully
delivered to some of the recipients, but it cannot be to
others (for example, due to mailbox space allocation
problems). In such a situation, the response to the DATA
command must be an OK reply. But, the receiver-SMTP must
compose and send an "undeliverable mail" notification
message to the originator of the message. Either a single
notification which lists all of the recipients that failed
to get the message, or separate notification messages must
be sent for each failed recipient (see Example 7).
This does not say that a DATA 554 means the RCPT 250 replies will get
the messages and that you can retry the others non-250 RCPT replies.
It does not say that.
IMTO, clients who continue retrying with a DATA 55z response
regardless of z, regardless of the RCPT list, is seriously broken
Hector Santos, CTO