On Tue 26/Nov/2019 03:45:38 +0100 John C Klensin wrote:> --On Sunday, November
24, 2019 12:35 +0100 Alessandro Vesely 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.
Right, I more or less agree with Bron's "NOW? (for some value of)"
(RFC 9821 would seem to be due in 2024, at current speed.)
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 :-)
Thanks for your endorsement :-)
[... 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.
Except that Section 3.9, Mailing Lists and Aliases, for example, says:
However, in this case, the message header section (RFC 5322 [4]) MUST
be left unchanged; in particular, the "From" field of the header
section is unaffected.
Changing that sentence won't break any compliance. Rather the opposite.
That short section is, AFAIK, the main mailing list spec. As most readers
know, the catching on of DMARC brought serious troubles to many ML, especially
after some big players set up strict policies. A WG was set up to mitigate ML
disruption. Conditional DKIM signatures were considered the least broken
solution. Although there was an implementation, that solution was abandoned in
favor of a different protocol, ARC, which does not solve the problem. In that
situation, all what ML could do was From: rewriting. Yet, nobody took the
burden to specify it.
I agree it is probably better to specify ML in a separate document. Then
rfc5321bis can drop Section 3.9 entirely. That won't reduce the number of
pages very much, but still help in that quest.
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.
You don't mean the yam work, do you?
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.
That practice to derive a paper worthiness by the number of citations is
questionable. In some cases, the choice of citations should determine the
worthiness of the paper at hand.
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.
And then the harder they come
The harder they'll fall, one and all
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).
Yeah, in that hypothesis your second conclusion is correct, unless published
standards could be useful for law making (which doesn't seem to be, AFAICS.)
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.
Nicely said.
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.
The current state of the art is that new mail operators can naively encounter
situations where their mail is not delivered. Some times, that is because
their volumes are too small to be relevant. Some times, they happen to inherit
bad IP addresses. Not to mention filtering inbound traffic. It is all too
easy to outsource. That way, the path toward a very small number of large
email providers gets larger and larger.
Email authentication should be enough to overcome the risk of backscattering,
so there should be a way to let authors know that their mail was dropped, even
for messages being forwarded. Actually, spammers are the most diligent
implementors of authentication protocols, using a number of trash, yet real,
domains. To avoid gaming, however, receivers are not going to inform about
quarantined messages. Perhaps, if email authentication was taken more
seriously, this kind of crippled behavior could be overcome.
Should the standard consider a database of pen pal domains?
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.
Surely not
Best
Ale
--
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp