--On Sunday, November 24, 2019 12:35 +0100 Alessandro Vesely
<vesely(_at_)tana(_dot_)it> wrote:
On Sat 23/Nov/2019 13:35:00 +0100 John C Klensin wrote:
there is an effort afoot to get revisions to 5321 and 5322
out there.
Where?
I will let the ADs address this at their convenience. Any
questions about apparent top-down planning for WGs should also
be addressed to them and/or to the Nomcom as they consider
criteria for open slots. In fairness, please give the ADs a
week or two to recover from IETF, any associated travel or
vacations, etc., before setting off a speculative storm of
postings on that topic and this list.
This rather long response is addressed rather more to a future
discussion about a scope statement for a possible WG to update
some mail documents as it is a specific answer to Alessandro.
As a result, he should probably be recognized for opening a can
of worms :-)
And see my personal comment and opinion that make up the last
half of this note.
[... guidelines for extension publishing omitted ...] because
there is about zero chance that anything would be included in
a 5321bis that would force it back to Proposed Standard.
Yet, I think something will have to be said about the now
common habit of From: rewriting. Section 3.9, Mailing Lists
and Aliases, still considers only rewriting of the envelope
from. Reality now differs.
Almost anything that addresses "From:" (I assume you are
referring to the message header field, not the MAIL command)
rewriting would need to be at least partially a 5322bis issue,
not a 5321bis one. We've typically had to explain more times
than I care to remember (and in what has often turned out to be
a rather painful process) that SMTP is (still) allowed to
transport message content that does not conform to 2822/5382 and
that having MTAs mess with what 5321 thinks of as content
endangers that principle. 2821 and 5321 weakened that boundary
somewhat relative to the very clear boundary between 821 and
822, but it is not clear whether weakening it more is desirable.
A similarly-fuzzy boundary exists between 5322, which is very
clear that it is not in the MIME business, and the MIME specs,
noting that Content-Type:, Content-transfer-encoding:, and even
MIME-version: header fields are, structurally, very much part of
the main message headers and not material specific to body
parts.
I don't think such changes would imply going back to PS, given
the loosely normative content of that section.
I had hoped to postpone this discussion or to never have it,
but, especially given that it bears on Viruthagiri's suggestion,
let me be clear on how I feel about opening 5321/5322. This is
just a personal opinion and I'm not trying to avoid work.
Indeed, Barry, Pete, and Alexey already have a working draft and
collection of questions about 5321bis in hand although the
questions I'm about to raise are, IMO, the more serious and
complicated ones and _not_ in that draft and set of notes.
First, I think it is bad for the IETF and probably bad for the
Internet if we create new standards that are generally ignored.
Old standards that practices have evolved away from are
unfortunate too but, IMO, less serious. FWIW -- and it is
somewhat more than anecdotal evidence -- sites that track
academic papers and what they reference are still telling me
that far more references are being made to 2821 than to 5321.
That is more then eleven years after the latter was published.
One could claim that use of 5321 among those who are actually
implementing and deploying SMTP is proportionally much higher,
but the substantive technical differences are few anyway.
Second and more important, we appear to be in a situation in
which a very small number of large email providers are doing
whatever they think serves their needs and their customers well,
independent of whether or not their actions are consistent with
the standards and at least equally independent of their effects
on email users who are not their customers. One way to look at
those actions could lead us to the conclusion that concentration
is a good thing because, if links between MTAs are adequately
encrypted, having all mail traffic move among a small number of
providers prevent those who can sniff origins and destinations
on links from determining who is sending messages to whom. If
that is our conclusion, and we also conclude that those
providers are perfectly capable of working out interchange
requirements with each other, than maybe further IETF work on
email standards, especially basic transport (and maybe header)
standards, is a waste of time (or worse).
If, instead, we conclude that concentration is not a good thing
and that many of the ideas those providers are coming up with
are bad for the Internet (or at least for the idea of a highly
distributed and robust mail system), it appears we have a choice
between trying to hold the line on what we believe is really
good for the Internet long-term (and having the near-certainty
of being ignored) and trying to make minor adjustments to, or
compensations for, whatever is being done with a large fraction
of email in practice so as to make the effects less bad. The
problem isn't just with the large providers but includes other
ways in which Internet mail has evolved. Specifically, I
suggest that there are a small number of design principles or
assumptions that underlie the SMTP architecture. One is that
once a message starts moving, via SMTP, across the Internet, no
one alters the message content or even inspects the content to
figure out if moving it onward is a good idea until after the
message arrives at the final delivery server. If we still
believe that, we not only would not be rewriting header fields
like "From:" in transit, we wouldn't be doing in-transit
inspection or filtering for spam or malware. We can get around
that requirement by splitting hairs about the definition of
administrative boundaries but the question is whether we are
ready to "face reality" and modify or remove that restriction
from SMTP.
Perhaps even more fundamentally, the Internet email architecture
assumes that, if a message is sent out, it will either be
delivered as specified or a non-delivery response or message
will get back to the message originator. A version of this is
spelled out in Section 6.1 of RFC 5321. Concerns about blowback
attacks, disclosure of information to actual or potential
attackers, and some tricky issues involving the assumption of
equal functionality on forward and reverse paths have
significantly reduced the validity of that assumption, possibly
getting worse with each succeeding year. Sections 6.2, 7.8,
and 7.9 allow for messages to be rejected or discarded for
various operational reasons. However, it seems to me that, if
we are going to open 5321 and try to move a successor document
to Internet Standard, we are obligated to ask ourselves whether
discarding messages that some system decides cannot or should
not be delivered has become enough of the current practice that
those sections should to be revised to be more prescriptive
about what should or should not happen rather than simply
providing a foundation for people discarding messages without
being in technical violation of the standard.
Again this is just personal opinion but it seems to me that, if
we are going to open 5321 and 5322 at this stage, we are under
some obligation to address those questions and try to reach some
sort of consensus about what to do about them. And, if only
from observation of comments on this list in the last few years,
I predict that won't be easy.
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp