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

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

Doug,

(top post)

I had promised myself to not respond to anything more or to
further touch 5321bis until after we hear from the WG Chairs,
but I want to note, after reading your note below and Steffen's
follow-up to it, that it appears to me that there is a really
simple solution to the problem you are talking about.  That is
to adjust DMARC (which, as you point out, has an at least
nominally active WG) so that it says that, if multiple mailboxes
appear in the "From:" header field, only the first is used for
authentication purposes.  If you need to say more, it would be
that _for DMARC authentication purposes_ any mailboxes after the
first should be treated as if they appeared in "Cc:" header
fields.  That would completely avoid trying to treat the
additional listed "From:" authors as if they need to be
authenticated, much less how they are associated with any sort
of message signature.  It also completely avoids the layering
problem Murray described because it is not changing the syntax,
only assigning some extra semantics to the first listed address
and doing so only narrowly and only for DMARC purposes.

As several of us have pointed out, you had better also look at
"Sender:" if it is specified, noting that it can only specify
one mailbox.

That solves the problem as you have described it (even though
you have asserted the need to authenticate all authors listed in
"From:", you have given no reason for that, at least any that I
can understand, much less any indication of how it might work).
It requires no change to rfc5322bis and certainly not reopening
it.

If someone can identify a reason for it, it would seem to me to
be quite reasonable to put a sentence into the A/S advising
implementations that are passing message along to avoid
reordering the mailboxes in a multiple-mailbox "From:" header
(and maybe headers in forward pointing header fields as well)
but I'm having trouble figuring out where that might be an issue
if implementations conform to rules we already have in place.

Finally, do keep in mind that, while, as you pointed out,
EMAILCORE and DMARC (and maybe other groups that might be
relevant) are all open, EMAILCORE faces a very significant
restriction relative to the others.  This WG's main mission is
to move a pair of specifications for very long-established
protocols -- protocols for which there are prior specifications
and decades of very broad adoption and experience (whether one
counts contemporary implementations by organizations who appear
to think that they are important enough to not have to follow
standards or not) into Internet Standards.  The requirements on
the WG for documents that are intended to be published as
Internet Standards are fairly tough.  In particular, a change
that makes implementations that were valid and conforming under
RFCs 5322 and 5321 non-conforming to the new versions would
generally be forbidden (that is consistent with Murray's comment
about scope which arrived after this note was nearly finished).

best,
   john

p.s. Murray, thanks for stepping in on this.  I hope your doing
so will save us some time.


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

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