On Wed 03/Jun/2020 19:27:52 +0200 Dave Crocker wrote: > On 6/3/2020 10:20 AM, Alessandro Vesely wrote: >> On Wed 03/Jun/2020 18:43:16 +0200 Dave Crocker wrote: >>> On 6/3/2020 9:38 AM, Alessandro Vesely wrote: >>>> MUAs should be discouraged from displaying or using Author:, unless >>>> (verifiably) signed by a trusted domain or otherwise configured by the >>>> user. >>> Why? >> That avoids the dreaded back-to-square-one path that Brandon conjectured. It >> prevents attacks based on this field, while maintaining the DMARC paradigm. > > The barrier you specified sounds reasonable. But it isn't. > > Any signature put in place when the Author: field is created is likely broken > by the time it gets to the recipient. That's the entire problem that > necessitates rewriting the From: field.
That depends on who creates the Author: field. I'd imagine it can be created on rewriting From:. If it exists already at that time, one can still check (by ARC?) if it was signed, and, in case, sign it in turn. > We do not require 'signatures' on Subject: or the Body or Date:. This is just > one more field. Right. To sign Author: wouldn't be a DKIM or DMARC rule. It's just a hint for MUAs. Rather than thoughtless treating Author: as From: by default, do some serious checking and/or trust user settings. > The concern about square one is misguided, apparently mostly because it > continues the erroneous belief that the validation work is done for the end > user, rather than the filtering engine. Besides that, it ignores the fact that > authentication mechanisms are presumably still in place. Some authentication results are displayed to the end user. They are important in edge cases. > Users are tricked by the content of the message, not by the From: (or Author:) > field. The content is only seen if the message is opened. In the message listing I only see the display name. So, it is important that the display name comes from a trusted field. That is to say, from From:, at least in the default configuration. When the message is open, on edge cases the user should first look at the authentication results, which shows the domain name on a decent MUA. > On the other hand, a clean From: (or Author:) field enables consistent MUA > organizing of messages. Messing with the From: (or Author:) field by > intermediaries defeats that. Intermediaries already mess up when they rewrite the From:. Adding an Author: allows that mess to be partially undone. Experience seems to indicate that mailing list software reacts more quickly than MUAs. MUAs will not add an Author: field any time soon, especially if it has to be a copy of From:, with zero added information. And then an Author: field is only needed by mailing lists and similar minorities, when the From: is rewritten. Recall DMARC was adopted because the amount of such traffic is negligible. In addition, I'd dare hypothesize that users who subscribe to mailing lists are more skilled than average (?) They should be able to configure a MUA to deviate from the "safe" behavior in certain cases. Best Ale -- _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
