On Thu, Jan 11, 2024 at 11:51 AM Damien Alexandre <Damien.Alexandre= [email protected]> wrote:
> Hello, > > A question I have reading the RFC7489 and more precisely the part «6.6.1 > Extract Author Domain». > https://datatracker.ietf.org/doc/html/rfc7489#section-6.6.1 > > > The RFC first states: > > "Messages bearing a single RFC5322.From field containing multiple > addresses (and, thus, multiple domain names to be evaluated) are > typically rejected because the sorts of mail normally protected by > DMARC do not use this format;” > > And a few lines below: > > "The case of a syntactically valid multi-valued RFC5322.From field > presents a particular challenge. The process in this case is to > apply the DMARC check using each of those domains found in the > RFC5322.From field as the Author Domain and apply the most strict > policy selected among the checks that fail.” > > I find the two propositions quite contradictory and not sure which one > should be applied. > > DMARCbis has rewritten these sections and has text that you may find helpful. https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-29.html#name-extract-author-domain 5.7.1. <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-29.html#section-5.7.1>Extract Author Domain <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-29.html#name-extract-author-domain> The domain in the RFC5322.From header field is extracted as the domain to be evaluated by DMARC. If the domain is a U-label, the domain name MUST be converted to an A-label, as described in Section 2.3 of [RFC5890 <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-29.html#RFC5890>], for further processing.¶ <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-29.html#section-5.7.1-1> If zero or more than one domain is extracted, then DMARC processing is not possible and the process terminates. See Section 11.5 <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-29.html#denial-of-dmarc-attacks> for further discussion. https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-29.html#name-denial-of-dmarc-processing- 11.5. <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-29.html#section-11.5>Denial of DMARC Processing Attacks <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-29.html#name-denial-of-dmarc-processing-> The declaration in Section 5.7.1 <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-29.html#extract-author-domain> and elsewhere in this document that messages that do not contain precisely one RFC5322.From domain are outside the scope of this document exposes an attack vector that must be taken into consideration. Because such messages are outside the scope of this document, an attacker can craft messages with multiple RFC5322.From domains, including the spoofed domain, in an effort to bypass DMARC validation and get the fraudulent message to be displayed by the victim's MUA with the spoofed domain successfully shown to the victim. In those cases where such messages are not rejected due to other reasons (for example, many such messages would violate RFC5322's requirement that there be precisely one From: header), care must be taken by the receiving MTA to recognize such messages as the threats they might be and handle them appropriately. <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-29.html#section-11.5-1> -- *Todd Herr * | Technical Director, Standards & Ecosystem *e:* [email protected] *p:* 703-220-4153 *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
