Hi Doug,
On Sat 11/Dec/2021 05:29:22 +0100 Douglas Foster wrote:
I suggest that it is time to propose that RFC 5322 section 3.6.2 be revised to
drop support for multiple From fields.
As Scott noted, Emailcore mailing list is next door.
The market has clearly spoken that there the feature is not needed.
No, the market didn't speak. The fact that most messages have a single From:
address happens because of the typical typing context of one author using one
device.
Occasionally, it happens to share authoring with a coauthor. Even then, unless
it is important for formal attribution of authorship, the typing author often
omits to add the coauthor in the proper field. If it /is/ important, however,
it'd better be supported.
Every MUA that I have used is designed to solicit From and Friendly Name as
separate and single-occurrence fields. Similarly, those MUAs present
Friendly Name and From as separate fields, with no evidence that they are
designed or tested for lists.
I'm using a stock Thunderbird package with average settings. It allows adding
coauthor, as in this case, and presents it by appending "et al." to the
friendly name in the message list pane.
On the technical side, From headers are difficult to parse even with a single
address. The address is not consistently enclosed in angle brackets, and the
Friendly Name is not reliability enclosed in quotes. Then one has to add the
complexity associated with internationalization, and the possibility of
local-parts that are quoted strings. I cannot help expecting that some
multi-address From lists will simply be mistaken as a complex Friendly Name
with a single From address.
That's right. Typos happen every time.
Of course, an RFC 5322 revision will not happen quickly if ever, and we do not
wish to hold our document or our breath waiting for that to happen. But I
would like the issue documented.
See also RFC 6854, Update to Internet Message Format to Allow Group Syntax in
the "From:" and "Sender:" Header Fields.
For our document, I think the chairs need to answer the question, can we mimic
RFC 7489 by having text that deprecates address lists, as long as we don't
prohibit it? I am thinking something like this
"Senders should be aware that although RFC5322 allows a message list,
few messages actually have more than one address, and as a result
recipients may not recognize or accept messages with multiple From
addresses."
That's cheating! Recipients seem to recognize messages with multiple From:
addresses very well. It is our protocol which is lacking.
For evaluators that want to both accept such messages and fully evaluate them,
it is impossible to argue against checking every address as the most complete
security review. In that since RFC 7489 is correct.
But I prefer language that says to evaluators, "if you want to accept these
messages, do it any way you want since it is at your own risk" Otherwise,
product developers may put a lot of effort into code that is rarely used and
poorly tested, simply to comply with the specification.
To minimize changes is why I propose to validate only the first address. The
validating software may recognize that there's a comma, presumably followed by
other mailboxes, and just disregard it. Much like the usual path.
Still, focusing on the first mailbox is consistent with the DMARC choice of
From: for its visibility. Thunderbird, for example, requires extra clicks to
display further addresses.
For reporting purposes, I think we can require that only one address be used
per message, if such messages are reported at all.
As long as only one domain per message is authenticated, no change is needed
for reporting.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
