John,
First of all, I completely agree with Dave's recent comments
about the draft. Without changes that respond to those points,
it is not possible (at least for me) to respond to most
questions or issues without speculating on what the draft
accomplishes and where it fits in the scheme of things.
More below...
--On Thursday, March 31, 2022 13:08 -0400 John Levine
<johnl(_at_)taugh(_dot_)com> wrote:
It appears that John C Klensin <john-ietf(_at_)jck(_dot_)com> said:
Let me add one thing to your suggestions. While it does not
appear in the headers, the last sentence of Section 1 of the
current draft claims that this updates RFC 5321. I suppose
that is necessary because it adds a reply code that is not in
the list that now appears in 5321, following the model of RFC
7504.
This reminds me, why don't we have an IANA registry for SMTP
return codes? That would greatly simplify exercises like this.
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). While those comments
were written specifically about extensions, they also apply to
addition of reply codes for specific purposes, especially reply
codes that deal with needs and situations that are specific
enough that the odds of broad support (beyond "look only at the
first digit" seem fairly low. In addition, 5321 has a rather
extensive treatment of reply codes, their relationships, and the
underlying relationships in Section 4.2 (with predecessors going
back to RFC 821). Capturing all of that information, including
the relationship between a new code and older ones, in an IANA
registry would be daunting, especially if most of the
information in Section 4.2 (and elsewhere in 5321) were not
moved to the registry and 5321bis rewritten to adjust for that
change. The latter would probably not be impossible, but it
would be difficult, error-prone, result in larger changes than
any difference we've seen between 5321 and 5321bis so far. I
suspect, given discussion so far, that we'd want a new
subsection of Section 4.2.4 of rfc5321bis or some considerable
enhancement to the existing Section 4.2.3 to explain the
applicability of the code -- again, not a job for an IANA
registry. Momentarily putting on my editor's hat, please
don't go there unless there is a _very_ strong set of reasons.
I suggested to Alex that his draft needs to define an
extension to let client MTAs tell servers that they understand
259:
ehlo cruddy.mail.org
250-sceptical.server.com
250-STARTTLS
250-PIPELINING
250-ENHANCEDSTATUSCODES
250 MAYBESPAM
mail from:<sleazy(_at_)sleazy(_dot_)org> MAYBESPAM
250 2.1.0 Sender accepted.
rcpt to:<victim(_at_)somewhere(_dot_)wtf>
250 2.1.5 Recipient accepted.
data
354 Go ahead
-- blah blah blah --
.
259 2.6.8 That smelled pretty bad.
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, which
then then looks up Comcast and starts using its MX records. If
the submission server does not recognize and advertise
MAYBESPAM, either the mechanism is dead or it is useless: it
won't include MAYBESPAM in its MAIL comment and, if Comcast
sends the code anyway, there is no point. In addition, Comcast
today lists the same preference for all of its MX records and
presumably, each of those servers can perform MDA functions (see
earlier comments about "inboxes" and "spam folders"). But
suppose they change their strutural setup and become more like,
e.g., Google or, for that matter, dcrocker.net and use
multiple-preference MXs. Now, even if all of the systems
involved advertise MAYBESPAM (on their server side) and
including it in the MAIL command (on their client side), those
intermediate servers either have to take the message content
apart looking for spam (seriously violating provisions of
RFC5321 and, at least so far, 5321bis) or all they can do is
open a connection and send it off to a server listed in a
better-preference MX record. If it does the latter, it must
(probably MUST) return 250 because it just does not have enough
information to return anything else. And, when the message gets
to the delivery server and it determines that the message is
maybe spam, we are in MDN territory, not that of reply codes.
So, let me add a third item to Dave's list:
3. It needs to have a sufficient case analysis that includes the
above and other situations and an analysis of how each would
affect usability.
In that case it doesn't update 5321, since it's not changing
what SMTP clients and servers do in the absence of that
extension, but it would be nice to have a registry so the
codes don't accidentally overlap.
And that, it seems to me, is another argument for one or more
enhanced status codes rather than messing with the SMTP reply
code set. I have a relatively open mind and, given answers to
Dave's two requirements and my additional one, could easily
change my mind. But, right now...
With respect to 259 vs 559, Comcast is a pretty big mail
system. If they think this could be useful, which they
apparently do, I think it would be a fine idea to try the
experiment (which does not need an RFC since we are still not
the Network Police) and then later perhaps advance the
proposal with experience of what it does. Experiments would be
easier if it were possible to reserve the code points without
a lot of overhead.
See above. But, precisely because Comcast is a pretty big mail
system, sending and receiving mail from at least four domains I
can think of immediately (and assume there are more), with at
least two different sets of DNS-listed mail servers (some of
which use multiple preference levels), I recommend some
intra-company experiments. That would require no RFC-type
documentation at all. A report on those experiments would
contribute significantly to the information Dave and I are
asking for. And, if desired, I would hope that it would be
really easy to get a well-written document that was a report of,
and recommendations from, Comcast's experiment published: much
easier than starting off with a tentative proposal.
Even for that experiment, I'd still suggest using enhanced codes
with 250 (again, the message is being delivered and to which
folder is not an SMTP problem). 2.6.8, as you suggest above, is
not available because it is used for something involving UTF-8
mailbox names. But perhaps they could use
2.6.11 That smelled pretty bad.
and
2.6.12 I am too far from the recipient inbox to analyze its
smell
which would even address the relay problem outlined above.
If, on the other hand, they had a need for a new SMTP reply code
--something that clearly has not been demonstrated -- I haven't
done the analysis of 259 against Section 4.2.1's "theory"
requirements. If they authors have done that, it should be in
the draft too.
Finally, with apologies in advance if anyone finds this snarky,
if the justification for this discussion --and several of us
spending time trying to make suggestions about fixes or
alternatives to the provisions of a document that feels more and
more like an incomplete set of ideas (or incomplete
documentation of more extensive thinking) is that "Comcast is a
pretty big mail system", with little or no demonstration or the
workability of the idea for the many and varied systems on the
public Internet (even as an experiment), the discussion is
rapidly deteriorating into free consulting for Comcast. Maybe
there are better ways for them proceed.
best,
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp