Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D
On 6/2/2020 8:45 PM, Douglas E. Foster wrote: Someone said that the Sender Address is all we can trust. Nonsense. +1 As to identifiers: The RFC 5321 MAILFROM sender is intended, at least in my understanding, to represent the login account used to create the message, while the RFC 5322 From Header represents the "speaker", the person whose ideas are being represented by the content. It matters if someone puts words in someone else's mouth, and From fraud is exactly that type of fraud. You bring up a basic fundamental reason what the 5322.From field is the only signature binding requirement for DKIM. When it comes to exclusive mail, it is the anchor that is associated with: - Login Account - The Alias or Display Name, - The Default From name for local messages and if the message is exported for a network mail system then we have the additional related identities: - 5322.From - 5321.Mail From In the restrictive DKIM Policy Model, all these identities are closely tied together. They are usually represented and traceable to one person and thus illustrating the long time "Proof Of Concept" that a restrictive DKIM Policy is so powerful, "It's Scary!" A break or deviation from this expectation is a strong candidate for rejection. I simply cannot grasp how DMARC conflicts with RFC 5321 or RFC 5322, inhibits authorship, or creates any other attribution problem. This assertion was simply not explained. I believe they are simply catching up with the list problem. Thats all. The problem was recognized long ago with SSP, ADSP. But when ADSP was abandoned for these lists problem and replaced with DMARC, the list problem was no longer a concern but DMARC did not resolve the list problem and it appears DMARC "Proposed Standard" will not try to address it. -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Requirements for a DKIM Signing Practices Protocol
I have to ask these engineering questions because we spent a lot of time developing this functional specifications. How much does DMARC follow the DKIM Signing Policy functional specs? Requirements for a DKIM Signing Practices Protocol https://tools.ietf.org/html/rfc5016 In addition, is DMARC consistent with the DKIM Service Overview? DomainKeys Identified Mail (DKIM) Service Overview https://tools.ietf.org/html/rfc5585 -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
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
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
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. We do not require 'signatures' on Subject: or the Body or Date:. This is just one more field. 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. Users are tricked by the content of the message, not by the From: (or Author:) field. 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. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
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. I, for example, would configure to display Author: in the listing of [dmarc-ietf] and similar folders. Reply-to-Author would also be a useful button, if not abused. It's fine to fulfill advanced users' wishes as long as average user behavior is not forced to change. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
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? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields
On Tue 02/Jun/2020 19:00:55 +0200 Dave Crocker wrote: > On 6/2/2020 9:44 AM, Jesse Thompson wrote: >> I'm relaying these DMARC questions/concerns on behalf of an email admin at >> another university. [...] >> >> " >> I don't see on the list of issues the most fundamental problem of DMARC, >> namely that it conflicts with RFC 5322 on the use of the From and Sender >> header fields [1] and possibly with RFC 6326 as to the significance of DKIM >> fail [2]. The former is the more serious problem. Making DMARC alignment >> part of a standard for Internet messages requires a revision of RFC 5322. I'd >> love to see this resolved. > > [...] > > DMARC enforcement requires that the DKIM/SPF domain be the same as the author > From:. That is, the folk doing email operations have to be able to sign the > DMARC aligned domain. > > Hence the From: field is now really the Sender: field. The From: field fixup > hacks that are needed by intermediaries, to avoid DMARC-based rejections, > makes > this fact painfully clear, even as they serve to undermine recipient use of > the > From field for author-related message management. > > [...] > > The only suggestion I've been able to formulate is: create a new field, such > as Author:. +1, that's the proper way to fix the issue Jesse relayed. Re-senders who rewrite From: should copy its value to Author: unless such field is already present. MUAs should be discouraged from displaying or using Author:, unless (verifiably) signed by a trusted domain or otherwise configured by the user. > (Give it a simple, clean, appropriate name, rather than something like > Original-From.) Yes, and let's note that the issue is so fundamental that solving it also solves the long-standing problem of how to standardiz mailing lists behavior with DMARC. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
