--On Thursday, March 31, 2022 15:29 -0400 John R Levine
<johnl(_at_)taugh(_dot_)com> wrote:
On Thu, 31 Mar 2022, John C Klensin wrote:
Personal opinion: Simplifying "exercises like this" is not
necessarily a useful goal. Please note the last two
paragraphs of Section 2.2.1 of RFC 5321 (and its equivalents
in its predecessors going back to RFC 1425). ...
Well, the alternative is to squat on return codes and take
your chances. Be careful what you wish for.
As I hope you know, a few recent issues with SMTP
notwithstanding, I've become an increasingly strong advocate of
low-threshold registrations to prevent naming conflicts and
discourage squatting. But let's look at this one:
(1) The name (or, in this case, number) space is quite
restricted, especially when new codes are expected to conform to
the "what is each digit about" theory of 821-> 2821 -> 5321.
Restricted name spaces are, as you know, one of the legitimate
reasons given in the assorted documents for restrictive
registration policies. Dropping that theory to promote
registrations by people with half-baked ideas isn't obviously a
good tradeoff.
(2) Because of that rule about SMTP clients making operational
decisions based on the first digit only, SMTP is fairly robust
against bogus or unknown codes, a at least ones that otherwise
conform to the digit meaning theory. Where it makes a
difference, I'd prefer "pay attention to the full code if you
recognize it and it makes a difference and resort to looking
only at the first digit otherwise" to either just looking at the
first digit or the behavior exhibited by the library Ned
described. However, one of the places it makes a difference is
the distinction between codes in which recipients of the reply
are, or are not, expected/required to look at the text strings.
That involves an explicit list of codes in 5321 (a list that
this one would need to be on because of that numeric assessment
level).
(3) As I have said earlier, the discussions in 5321 of the
codes, their applicability, and whatever special circumstances
apply are fairly complex. I don't see a registry --at least any
IANA registry arrangement I ever remember seeing-- being
structured to handle that complexity. One basically needs a
narrative (ideally one that is easier to follow than 5321) and
that isn't what IANA normally means by "registry". That list of
codes that require the code-receiving client to pay attention to
the content of strings --which I had forgotten until I ran
across it earlier today-- is just another example of the
complexity.
(4) You may have data that shows a lot of reply code-squatting
but, to the best of my knowledge, there have been no serious
requests for new codes since RFC 7505 was published in 2015
(partially to support your "null MX" spec). Now, my definition
of "serious" gets back to a good approximation of Dave's list
about demonstrating utility and being much less tentative.
YMMD. I think it also requires an affirmative demonstration of
why some new, fine-grained, enhanced code or codes would not do
the job. The present document does not qualify on either
condition (although some future revision might).
How about a registry with an expert review rule that new codes
need to be enabled by an extension or else standards track RFC.
Better. But that still does not account for the interactions
within 5321[bis] and the associated registry complexities, the
practical limitations on the size of the code space (at first
glance one might guess there are 999 possible codes, but there
are actually much, much, less than 400), and so on. And AFAIK,
EMAILCORE has yet to reach consensus that extensions require
less than serious standards-track consideration.
I had a thought that a simple registry of codes in use might be
helpful, all of them pointing back to SMTP for explanations.
But then I realized that might actually be an invitation to
squatters by telling them what codes were not in use.
A different suggestion that I'm not sure I think it a good idea:
Define codes starting with 7yz and 8yz for experimental use.
Indicate explicitly in 5321bis that the model for the second and
third digits does not apply. Set up an IANA registry as FCFS,
FCFS with verified contact point required and included in the
registry, or as Specification Required. Given the tendency of
SMTP implementations and libraries to get indigestion about
codes with unrecognized first digits (they would be captured by
any unrecognized code test, of course), it would more or less
assure that the experiment would be carried out only among
consulting adults who were prepared to send and receive that
(temporary) code.
While it might work for, e.g., Comcast->Comcast messages and
some others (see below), I don't see it working well with the
model. Suppose we have a sender at example.net who generates
a message in an MUA, hands it off to a submission server, ...
Naah. The people using this will be ESPs, people who send
bulk mail for commercial clients. I promise you they'd
implement in in the aforementioned ten milliseconds.
But... (i) that makes the experimental code plan more plausible
(ii) I still don't understand why an enhanced code (or a few of
them) wouldn't do a better job, and (iii) after spending those
ten milliseconds and however much longer it took to deploy the
thing (see Ned's note), they would likely get really frustrated
if it didn't work as (what they construed as) advertised. And
that gets back to Dave's comment about needing a really clear
explanation of expected utility.
In addition, it has been a long day and I might be missing
something, but I'm not sure that I see the use case for them
with the plan about a reply code as specified. If they are
originating the message, all they need to implement is code,
probably in their submission servers such that, if they actually
get the 259 reply code, they know what to do with it. They
presumably do no need to implement receiver-SMTP or special MDA
code at all. They originate and send a message, to, using your
example, <victim(_at_)somewhere(_dot_)wtf>. Assuming the mailbox exists,
they can get back:
259 2.6.8 That smelled pretty bad (8/10) -or-
250 OK
but they have no clue as to whether the 250 indicates
inspected and looks ok
intermediate relay does not play this game -or-
destination server for somewhere.wft does not play either.
all they can really learn from getting back that 259 response is
that the message might have reached someone's "spam" or "trash"
folder. "Might" because I can't find anything in the spec that
says, e.g., "a server that issues the with the 259 code and a
score about 7/10 MUST deliver the message to a "spam folder".
They would learn a bit more from maybe three enhanced codes:
250 2.6.11 That smelled pretty bad, but I'm delivering it
to the inbox it anyway (4/10).
250 2.6.12 That smelled really bad, so I'm delivering it
to the spam folder (8/10).
550 5.6.11 Horrible odor (10/10), please bounce the thing.
550 5.6.12 Really horrible odor (11/10), please do not
return content to sender because it is probably dangerous.
250 2.6.13 Conforming to 5321, I'm not opening the
message far enough to determine what I think of it.
250 2.6.14 I am too far from the recipient inbox to
analyze its
smell
(I'd have to think some more about whether the last two are
different, For the use case I think you are describing, 5.6.12
would probably never occur, especially if the ESP were a good
citizen who never allowed seriously malicious messages or
attachments to be sent or if the relevant receiver-SMTP/MDA
simply dropped such messages.
In any of those cases, either 250 or 550 alone would imply "no
support for that feature" of which "server does not belong to
Comcast and has not implemented support for this stuff" is a
subset.
That actually suggests that, if a new reply code is needed at
all, two are needed -- perhaps 259 and 559 -- to indicate
support for this feature. However see comments about the size
of the code space for reply codes. If one did the MAYBESPAM
extension, that would be unnecessary because offering and
requesting the extension could be specified as requiring that
the extended codes be present and interpreted however the
extension specified.
And, again, I'm not sure implementing the extension and/or
support for the new code would really add much value to the ESP
unless either (i) almost everyone to whom they send mail had
Comcast as a mailbox provider or (ii) this were put into a 5321
update as a "MUST support" and the delivery servers for almost
every mailbox on the net (few of which would belong to those
distribution-oriented ESPs) moved to rapidly deploy it.
What am I missing?
best,
john
p.s. I'm not certain those extended codes should be in the x.6.y
series rather than x.7.7 or a whole new x.8.y one.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp