I had been working on proposed language to strengthen section 5, which has a very weak justification of the use of the From address, because the prior discussion has left the issue hanging. The current text is followed by my proposed replacement text. Perhaps the group and the chairs are ready to address issue 73?
Doug Foster Current language: 5. Use of RFC5322.From One of the most obvious points of security scrutiny for DMARC is the choice to focus on an identifier, namely the RFC5322.From address, which is part of a body of data that has been trivially forged throughout the history of email. Several points suggest that it is the most correct and safest thing to do in this context: * Of all the identifiers that are part of the message itself, this is the only one guaranteed to be present. * It seems the best choice of an identifier on which to focus, as most MUAs display some or all of the contents of that field in a manner strongly suggesting those data as reflective of the true originator of the message. The absence of a single, properly formed RFC5322.From field renders the message invalid. Handling of such a message is outside of the scope of this specification. Since the sorts of mail typically protected by DMARC participants tend to only have single Authors, DMARC participants generally operate under a slightly restricted profile of RFC5322 with respect to the expected syntax of this field. See Section 6.6 for details. Proposed 5. Use of RFC5322.From DMARC's use of the RFC5322.From address has been challenged as arbitrary, especially since many MUAs display it only upon request. However, the RFC5322.From has consistently been understood to represent the person or other entity who is the author of the content and for whom responsibility should be attributed, so the integrity of RFC5322.From is critical to the credibility of the content. If the content is to be reliably attributed, the FC5322.From address needs to be reliably verified. Only the RFC5322.From address can serve this purpose. The RFC5322.From has all of the necessary characteristics for the purpose of attribution. First, it is a globally unique identifier. Secondly, it is stable over time. Because it is unique, it distinguishes this author from all other authors with similar names. Additionally, because many users have multiple email addresses for different purposes, the RFC5322.From address also distinguishes between different roles taken by a single individual. For all of these reasons, it is very useful for searching and sorting. The RFC5322.From address is the only identifier that is presented to the user which can be verified. The RFC5322.From address is the value which the user expects will be used for replies to the message. A successful spoof of the RFC5322.From address permits the attacker to "put words in the mouth" of the spoofed individual, an action which could cause great harm to the sender's reputation. If the recipient of the spoof replies to the spoofed originator, the recipient might also suffer significant embarrassment. By comparison, the Friendly Name provides no uniqueness, has no settled format, has no verifiability, and has no permanence. Since the Friendly Name is usually configured in the MUA, the Friendly Name may change randomly based on the MUA currently being used by the sender, and the sender can alter it at any time to any value for any reason. Attackers have been known to mimic the Friendly Name of someone known to the recipient to increase the effectiveness of the attack. When a user sees suspicious content from a trusted Friendly Name, one appropriate response is to compare the Friendly Name to the RFC5322.From address to test for logical consistency. Often, this is sufficient to detect the deception. The value of the RFC5322.From address has been established by two disparate groups: users of mailing lists and criminal actors. Neither of these groups can be considered supporters of DMARC. Mailing list users have complained vigorously because DMARC enforcement has caused mailing lists to alter the RFC5322.From address in ways that make sorting, searching, and other actions more problematic for them. Criminal actors have responded to DMARC by using look-alike domains that seek to impersonate the identity of a well-known domain without being subject to DMARC controls. This action demonstrates that the criminal subculture, which DMARC seeks to restrict, knows that a successful spoof of the RFC5322.From address will be beneficial to their efforts. ---------------------------------------- From: listsebby=40me....@dmarc.ietf.org Sent: 9/17/20 6:10 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC as Signal to MLMs for Rewrites (or not) On 17 Sep 2020, at 20:59, Jesse Thompson <jesse.thompson=40wisc....@dmarc.ietf.org> wrote: > On 9/17/20 2:11 PM, Sabahattin Gucukoglu wrote: >> Wouldn't it be nice if you could ask for MLMs to transform, just using a >> DMARC policy, even p=none, > > It is possible via p=quarantine pct=0. > > I think it makes sense to consider codifying beyond this defacto standard > hack. Isn't this part of DMARCbis? It was discussed, anyway. Which ones are > active? https://trac.ietf.org/trac/dmarc/report/1 These tickets seem to be relevant: #22 (Perverse incentives to use p!=none & pct=0): https://trac.ietf.org/trac/dmarc/ticket/22 #73 (Need decision on importance of From domain): https://trac.ietf.org/trac/dmarc/ticket/73 #63 (Make p=none with no reporting URI invalid-Closed): https://trac.ietf.org/trac/dmarc/ticket/63 I did not realise that this "hack" had become widespread. I agree that it should be codified, or else p=none explicitly needs to support it (and in that case reporting must remain optional). I can't speak to the pct parameter, because my sites are too small to really benefit from it. Cheers, Sabahattin _______________________________________________ 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
