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

[Douglas Foster <[e-mail]>]

On John's main question:  Yes, I believe that this issue is worthy of a
pull-back.

We are in the middle of a once-in-a-lifetime opportunity, because
EmailCore, DKIM, and DMARC are being revisited simultaneously, using a
substantially overlapping brain trust to revise all three documents.    One
of the underlying objectives should be to ensure that the efforts integrate
well, and the issue of From lists is possibly the most important place
where integration is required.

One can construct a 6-cell probability matrix based on message
characteristics (wanted or unwanted) and outcome (rejected by recipient,
accepted with only the first message displayed, or accepted with both
messages displayed.)    In this group, the implicit argument is that this
feature is too widely used on wanted mail to justify desupport, while in
the DMARC group, the argument has been advanced that such messages are so
unlikely to be accepted that the problem can be ignored.   An integrated
set of standards cannot have it both ways.

For the feature to be useful for wanted messages, it has to be initiated by
the sender and accepted by the recipient's evaluator.   I suggest that
"sufficient coverage" is already in doubt.  Legitimate senders are not
likely to do the pre-qualification work to determine which recipients will
and will not accept multiple-address messages.   Illegitimate senders, on
the other hand, are not so constrained.   Some are content to use broad
scale attacks and accept what gets through, while other attackers will pick
out a high-value target and do extensive pre-qualification to ensure
maximum impact on the intended victim.   In short, the feature looks much
more useful to attackers than to legitimate senders, and this is inference
is supported by the anecdotal comments that a Google representative has
made in the DMARC discussion.

But if I grant the dubious assumption that the value to legitimate traffic
is so high that the feature must be preserved, then it also becomes
incumbent on our design to provide a way to distinguish between legitimate
and illegitimate use, i.e. to provide an authentication solution.   But
there is, in fact, no authentication solution which can produce a credible
PASS on all names in a list.  Most legitimate messages will be unable to
authenticate all names, while some illegitimate messages may be able to
finagle that result.   To get even this very imperfect result, DMARC
implementers need to add a lot of code complexity to produce a result which
will ultimately fail to detect malicious impersonation.

The best answer is for DMARC to repudiate multiple-address From, but that
group cannot do that because that is a layer violation against this august
group.

Doug Foster




On Wed, Feb 14, 2024 at 11:27 AM John C Klensin <[e-mail]> wrote:

> 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
> >>
> >>
> >>
>
>
>