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

[Francesco Gennai <[e-mail]>]

Il 2024-02-15 05:30 John C Klensin ha scritto:

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

+1
IMHO, the DMARC WG must find a valid solution without having to deal 
with the complicated issue of managing From lists.

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

+1

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

+1

Regards,
Francesco

> 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


-- 
Istituto di Scienza e Tecnologie dell'Informazione (ISTI)
National Research Council (CNR)
Area della Ricerca CNR di Pisa
Via G. Moruzzi 1, 56124 Pisa ITALY
Cell/ufficio: [phone]
Skype: fgennai
email: [e-mail]