On Thu, Dec 9, 2021 at 6:27 AM Douglas Foster < [email protected]> wrote:
> I have trouble with this statement in section 5.7.1: > > "Multi-valued RFC5322.From header fields with multiple domains MUST be > exempt from DMARC checking." > > This language will serve as an invite for spammers to create multiple-from > messages to ensure that they will evade DMARC. To avoid creating security > holes, we need to bring this configuration within scope. Here is a > proposal: > > To ensure DMARC PASS, senders MUST ensure that each RFC5322.From address > evaluates to a PASS result independently. Evaluators may choose to > evaluate one, some, or all of the addresses. For example, evaluators may > choose to evaluate to the first Fail result, and then > disposition the message based on that failure. RFC5322 does not specify a > maximum number of allowed From addresses, but evaluators may choose to > impose a limit to prevent abuse of evaluator resources. DMARC reporting is > based on the single RFC5322.From address which is most important for the > evaluator's disposition decision. > > > The entire paragraph from which that sentence was pulled reads: The case of a syntactically valid multi-valued RFC5322.From header field presents a particular challenge. When a single RFC5322.From header field contains multiple addresses, it is possible that there may be multiple domains used in those addresses. The process in this case is to only proceed with DMARC checking if the domain is identical for all of the addresses in a multi-valued RFC5322.From header field. Multi-valued RFC5322.From header fields with multiple domains MUST be exempt from DMARC checking. In the case where DMARC checking is not performed, there will be no DMARC pass. If you believe DMARC to be a security tool, why do you deem a case with no DMARC pass to be a security hole, when the absence of a pass should put the message in a weaker position than one where there is a pass? The text at issue here is, as I recall, designed to address concerns regarding this text in RFC 7489: 6.6.1 <https://datatracker.ietf.org/doc/html/rfc7489#section-6.6.1>. Extract Author Domain The domain in the RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From field is extracted as the domain to be evaluated by DMARC. If the domain is encoded with UTF-8, the domain name must be converted to an A-label, as described in Section 2.3 of [IDNA <https://datatracker.ietf.org/doc/html/rfc7489#ref-IDNA>], for further processing. In order to be processed by DMARC, a message typically needs to contain exactly one RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From domain (a single From: field with a single domain in it). Not all messages meet this requirement, and handling of them is outside of the scope of this document. Typical exceptions, and the way they have been historically handled by DMARC participants, are as follows: o Messages with multiple RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From fields are typically rejected, since that form is forbidden under RFC 5322 <https://datatracker.ietf.org/doc/html/rfc5322> [MAIL <https://datatracker.ietf.org/doc/html/rfc7489#ref-MAIL>]; o Messages bearing a single RFC5322 <https://datatracker.ietf.org/doc/html/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; o Messages that have no RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From field at all are typically rejected, since that form is forbidden under RFC 5322 <https://datatracker.ietf.org/doc/html/rfc5322> [MAIL <https://datatracker.ietf.org/doc/html/rfc7489#ref-MAIL>]; o Messages with an RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From field that contains no meaningful domains, such as RFC 5322 <https://datatracker.ietf.org/doc/html/rfc5322> [MAIL <https://datatracker.ietf.org/doc/html/rfc7489#ref-MAIL>]'s "group" syntax, are typically ignored. The case of a syntactically valid multi-valued RFC5322 <https://datatracker.ietf.org/doc/html/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 <https://datatracker.ietf.org/doc/html/rfc5322>.From field as the Author Domain and apply the most strict policy selected among the checks that fail. That final paragraph opens up DMARC supporting receivers to denial of service attacks, since a bad guy could possibly construct a From: header field that is syntactically valid with many many domains, causing the DMARC validator to attempt to look up each domain, just as you're proposing here. What if there were ten, twenty, or one hundred domains? To mitigate the risk of the denial of service, the text was proposed that the only time to support multiple From addresses is when all domains are the same. -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* [email protected] *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
