1) The original assertion, that DMARC creates a conflict with prior specifications, appears to be undefended and incorrect. For From Addressing, It merely establishes some boundaries that the sender and the recipient choose to consider appropriate. For DKIM, it creates a use-case for a technology that was initially defined without any use cases. Consequently, I think this topic is ready for closure.
2) Some of the discussion appeared to resolve around the assertion that DMARC can have no value. Since that view is not universal, I think the project can continue with those who do believe that it adds value. 3) Some of the discussion has been about how to prevent soclal engineering of the recipient user. This is an important topic, but not directly related to the project. IETF would do well to establish some recommendations about how MUAs should behave, so that trust data can be displayed to the user. A typical user will have access to at least three different email clients: one on his cell phone, a product-specific web page, and a desktop product like Outlook or Thunderbird. If I wanted an organization policy that controlled when Friendly Name was displayed or DMARC status was displayed, I would have to find and distribute plug-ins to all of these products. As best as I have been able to tell, no such plug-ins even exist for Outlook and the other products do not accept extensions. There is an opportunity here for valuable standardization. ---------------------------------------- From: Alessandro Vesely <ves...@tana.it> Sent: 6/7/20 6:19 AM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields On Sun 07/Jun/2020 00:03:28 +0200 Jim Fenton wrote: > On 6/6/20 2:42 PM, Scott Kitterman wrote: >> On Saturday, June 6, 2020 5:26:08 PM EDT Dave Crocker wrote: >>> On 6/6/2020 2:23 PM, Scott Kitterman wrote: >>>> If things like DMARC, SPF, and DKIM do nothing more than get abusers >>>> to use different domains than they would otherwise, I think that's a >>>> win.>>> The issue here is DMARC, not SPF or DKIM, since DMARC is the only >>>> one of >>> the 3 that restricts the choice of domain name. >>> >>> With that in mind, I'll ask you why you think the kind of change you >>> cite is a win. >> 1. I think the domain displayed to the end user matters. In my sample size >> of 1, it matters to me. I know I'm not the average user, but independent of >> the question of how many users it matters to, there are some. > Same with me, but again I'm not the average user. +1, but then we're mailing list subscribers (leaving aside this list's topic.) >> >> 2. When abusers use different domains to send mail, it adds more information >> for filters to work on, so even if this is all about filtering, that works >> better too. > > But when abusers use different domains, the DMARC policy that applies is > controlled by them and is therefore meaningless. And the reports, if any > (probably none), are sent back to the attacker or their designate. > > Filtering might be done based on the DKIM signing domain or thesimilar > envelope-from domain if SPF is used, but neither of those require DMARC. The From: domain was chosen because that's the field that users can see. Now we conjecture that users don't actually see it. Oh boy. Certainly, if the From: domain is not visible we could filter on X-Filter-On-Me: and gracefully avoid the mailing list problem. On closer view, we seem to be discovering that the From: domain is obscured by the display name. We always neglected the display name. Furthermore, by letting the mailing list problem be dodged by creative From: rewriting, such as From: u...@example.com <actua...@someone.else> we are granting full citizenship to devious display names. Some clients (e.g. Thunderbird) can show only display name for people in the address book.[*] A close, perhaps formally easier, subject is the IDN homograph attack.[†] Would it make sense to ban, say, the use of the at sign (@) in display names? Best Ale -- [*] https://support.mozilla.org/en-US/kb/names-bug-no-email-addresses-are-displayed [†] https://en.wikipedia.org/wiki/IDN_homograph_attack _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
