--On Thursday, March 18, 2021 10:55 +0100 Arnt Gulbrandsen
<arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no> wrote:
On Thursday 18 March 2021 01:32:33 CET, John Levine wrote:
I'd flip it around. Do we have examples of MTAs that look at
the other digits
in responses to MAIL, RCPT, or DATA comands?
I searched github for "smtp 354" now, on the theory that that
number won't be used for much other than the response code.
Finding the first smtp client that expects 354 instead of 3
took maybe a whole minute. That package is a tool used by
innumerable web sites to send mail. I expect I'd find many
more if I were to spend a few more minutes looking.
While scrolling down I saw lots of unit tests that used 354,
which makes me suspect that half of that software would break
if fed 353 or 355 (and some would break in exciting ways).
Especially given the above and thinking about 5321bis rather
than anything more immediate...
My own understanding of the "first digit" rule has always been
that the intent was that:
* Servers should send the codes as specified (and try to
avoid inventing their own).
* Clients should read the three-digit code and take
whatever action on then that they deem appropriate. Of
course, if that action is to ignore all but the first
digit in some or all cases, that does not violate the
spec.
* _Only_ if a client reads a code and does not
understand it (because it is not explicitly in the list
specified by 821/2821/5321, standards track
registrations, because it is a private extension or
experiment, etc.) does the spec expect it to use the
first digit rather than, e.g., treating the message as
undeliverable. Because 5321 says that a message can be
rejected or not sent for any reason, "expect" is about
the strongest statement that can be made.
Now, if there is agreement that is the intent and either I have
gotten it muddled or have failed to un-muddle the text of
others, I apologize. And someone should take this to EMAILCORE,
ideally suggesting text but at least pointing to sections and
paragraphs that need work.
There are, I think, two unresolved question about the
interactions with extended reply codes. One is what a client is
expected to do it receives an unrecognized code --either one in
the ranges used by SMTP/5321 or completely out of range (666
anyone?)-- followed by some digits and periods that might be an
extended code? Even with the robustness principle. are such
strings to be treated as extended codes or ignored on the
assumption that, with a problem reply code, the strings cannot
be assumed to be extended response codes. The other is that,
if it were really the case that most MTAs are ignoring all but
the first digit, what are they transmitting back toward the
sender and does it include the extended codes and original text.
Fortunately, at least for me, both questions are far out of
scope for 5321bis.
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp