Re: [Emailcore] Time to deprecate multiple-address From

[John C Klensin <[e-mail]>]

Doug,

Some specific comments inline but, just to be clear, I don't
feel very strongly about multiple addresses in "From:" one way
or the other.  My principal concern is about one issue about
which I am convinced there is strong consensus in the WG: it is
time to get the two base documents (rfc5322bis and rfc5321bis)
finished so we can take a careful look at the A/S, revise it as
needed, and then get it finished and wrap up this effort.   From
that perspective, one of my questions that you did not answer is
really the most important, i.e., whether you are proposing that
we pull rfc5322bis back from "Publication Requested" and
consider this issue?

It is not my only concern; more inline below but those comments
are less an argument against what you are suggesting as they are
starting points for questioning some of your assertions.

--On Wednesday, February 14, 2024 07:14 -0500 Douglas Foster
<[e-mail]> wrote:

> Yes, I am addressing the problem created by multiple From
> addresses.
> 
> I could live with obsolete status, but I would favor
> de-support.  With either status, we cannot prevent people from
> using a list even if it is not standards-compliant.   Existing
> code will continue to interpret the additional entries as
> addresses rather than comments or noise.

Of course, that is what the spec says to do.

> I realized after writing that my results may be correlated
> because all of the UIs connect back to the same mail store, if
> the client protocols supply the From information so that the
> client does not have to re-parse the message headers.
> Perhaps someone with better data can demonstrate that the
> feature is widely supported.

It is just my guess, but don't think anyone is going to be able
to make a case for "widely supported", especially if that is
taken to mean "widely used".  

> When I have proposed innovate concepts, the Area Director has
> assured me that IETF documents tend to follow industry
> practices, not lead them. But in this case, we are resisting
> change that acknowledges what the industry practices have
> already become.

That raises two issues.  First, without knowing what question
the AD was asked or what the response was, I hope that it was
more nuanced than that.  If the IETF waited until industry
practices developed and then followed them, we wouldn't have the
modern Internet.  Depending on how "industry practices" are
defined, we would not even have any of the SPF, DKIM, DMARC, and
ARC protocols that are apparently at the core of your arguments
(see below).  Many, probably most, of our standards have been
somewhat aspirational.  Similarly, for the other, definitions of
"industry practice" may vary.

Now, for documents moving to Internet Standard, "no one actually
does that so it failed as an idea" is a powerful argument for
changing a requirement level or even taking something out
entirely.  Your comments so far appear to me to fall well short
of "no one".  Indeed, as you indicate below, your proof that the
feature is not supported rests on a very small number of
implementations (no matter how many users they have).   Even if
one looks at "industry practice", there is a big difference
between counting implementations or individual implementations
and counting, e.g., message traffic, especially if bulk mailings
are included in the latter.

> These are the problems with From lists:

> 1) From lists are uncommon, therefore the supporting code is
> rarely exercised and consequently poorly tested.

I suspect the latter might be true, but I don't think "uncommon"
implies "therefore..."

>   Experience
> has shown that infrequently used code sections are ripe
> territory for malformed-content attacks, because latent bugs
> exist in that code.

Again, while I do think "ripe territory..." follows, it does not
follow that "infrequently used" implies "latent bugs"... at
least unless you believe that all programming is sloppy and/or
that no one does prerelease testing.

> 2) From lists are inherently unverifiable.   All email begins
> with at most one authentication step, using one
> username/password combination or one trusted IP connection
> from a trusted server.   There are few ways to insure that one
> login represents two different human actors, especially if the
> From list involves accounts in two different security domains.
> More particularly, there is no basis for knowing that a
> specific message from a specific account represents multiple
> authors, while other messages from the same account represent
> only a single authors.   In a world where every message was
> legitimate and truthful, like the early research-oriented
> Arpanet, a multiple-author From was plausible.   But that
> world has passed.   Most incoming messages are unwanted, many
> are maliciously identified, and many are harmful.    Messages
> that are inherently impossible to authenticate are a security
> hole that will be primarily used by malicious actors.

FWIW, I disagree with many of the statements above or at least
with the obviousness you seem to attach to them.  Someone who
believed that multiple "From:" addresses are valuable could
reasonably take approximately the same position that
professional journals that allow papers with long lists of
authors make, i.e., that one of them is the "correspondence
author" or principle point of contact and/or that one of the
authors (who can be authenticated) is the responsible party and
authenticates the others -- i.e., that little purpose is served
by trying to authenticate additional authors.  That could lead
to an argument that the problem with multiple mailboxes in
"From:" isn't that more than one is allowed, it is that one of
them is not explicitly primary.  If, for example, a "first one
is primary" rule were adopted, it seems to me that most of your
argument would disappear.  Put differently, you appear to be
assuming that "message author(s) as listed in the 'From:' header
field" and "message signer or authenticator" have to be the same.

Indeed, one can argue that rfc5322bis (and all of its
predecessors going back to at least RFC 822) already have
provision for making the distinction outlined above, e.g., one
could have a message that contained:
    From: [e-mail], [e-mail], [e-mail]
    Sender: [e-mail]

Whether one should accept a message when only one author can be
authenticated and whose identity is used to authenticate the
message is an interesting question, but I don't think that an
answer that "unless all authors can be authenticated, the
message is inherently impossible to authenticate" is obvious.
And, to at least some extent, the arguments you are making are
at least as strong as case that existing authentication
protocols are inadequate (and at least not properly designed for
the multiple author case) as they are an argument that the
multiple author option should be discarded.

These standards also need to cover intra-organizational mail and
messages, where the conditions you assume may be quite different.

> In short, the opportunity window for From lists has passed.

Possibly, but I'm not sure it follows from your comments above.

Possibly constructive suggestion, especially if the WG decides
to not reopen rfc5322bis for this discussion:  Propose a
paragraph for the A/S that describes the problems you see with
multiple addresses in "From:" and recommend against its use. 

best,
   john




> On Wed, Feb 14, 2024, 1:30 AM John C Klensin
> <[e-mail]> wrote:
> 
>> Doug,
>> 
>> Just to clarify what you are asking for and make an
>> observation or two:
>> 
>> * When you are talking about "From lists", you are referring
>> to the "From:" header field and the <mailbox-list> syntax in
>> rfc5322bis.  Correct?
>> 
>> * FWIW, while I don't think I have seen it used in several
>> years (have not been paying much attention), I have seen more
>> than one mailbox in a "From:" header field in the past.  It
>> is/was used to express the notion of multiple people
>> collaborating on a message and does that far more precisely
>> than, e.g., including some of those people / mailboxes in a
>> "Cc:" header field.  To at least some extent, that history is
>> a refutation of "dubious idea with little actual need".
>> Others here, notably Dave Crocker, can certainly do a better
>> job than I can of explaining the origins and justification
>> for that construction.
>> 
>> * At least two of the three systems you identified both have
>> extensive histories of non-compliance to IETF specifications.
>> Adding this case to those histories may be worthwhile but does
>> not, in itself, justify changing the spec.  At the point that
>> the defining criteria for how Internet email is specified
>> becomes "whatever Google does", "whatever Microsoft does", or
>> "whatever Google and Microsoft do together", we would be
>> writing rather different specs.
>> 
>> * RFC 5322 and 5322bis introduced the concept of an obsolete
>> syntax that receivers are expected to support even though
>> senders are discouraged from using.  I gather you are
>> proposing that we eliminate the mailbox-list in "From:"
>> header fields entirely, not just treating it as an obsolete
>> construction.   Is that correct?
>> 
>> * Working Group Last Call on rfc5322bis closed on January 15,
>> almost a month ago.  draft-ietf-emailcore-rfc5322bis-10 is now
>> in "Publication Requested", awaiting AD signoff to start IETF
>> Last Call.  You are proposing to call off the publication
>> request so the WG can review this idea, get a new document
>> generated, and do an additional (at least partial) WG Last
>> Call, right?
>> 
>> thanks
>>   john
>> 
>> 
>> 
>> 
>> --On Tuesday, February 13, 2024 22:04 -0500 Douglas Foster
>> <[e-mail]> wrote:
>> 
>> > After a vigorous discussion in the DMARC group, about the
>> > authentication strategy for From lists, I decided it was
>> > time to ensure that my spam filters tested for From lists.
>> > That required some tests cases, which I then examined in my
>> > three user interfaces (webmail, Outlook client, and Google
>> > cell phone client).   I was expecting some diversity in
>> > behavior, but there was not:   all three products from
>> > three different vendors made the same choice:   the first
>> > address was displayed and the second address was ignored
>> > and hidden.
>> > 
>> > In sum
>> > (a) I have never having seen a From list in the wild,
>> > (b) I have learned that Google has refused From lists for
>> > about a decade without meaningful evidence that their
>> > decision hinders user needs, and (c) two widely used UI
>> > products and one niche product have all dropped support for
>> > From lists.
>> > 
>> > Since you are in the process of updating RFC 5322 to reflect
>> > current reality, it is time to admit that From lists were a
>> > dubious idea with little actual need.   Sender
>> > authentication has become an important part of email
>> > safety, and From lists are inherently incompatible with
>> > authentication.
>> > 
>> > It is time to define From as a Single-Address,
>> > Single-Occurrence header, matching the specification to
>> > existing usage.
>> > 
>> > Doug Foster
>> 
>> 
>>