Thanks for your comments.
The language in the quoted document about "multiple from messages are
usually rejected" was interesting. It reflects what I would intend to do,
and what I think others should do, but I assumed that we could not
explicitly advocate for that, since we could be accused of rewriting
RFC5322. That language does not appear to have been repeated, so I guess
we have successfully danced around that part of the problem.
I flinch at using MUST or SHOULD on instructions about how evaluators can
collect and use data for purposes of message evaluation. These directives
should be used for situations where a violation has a high likelihood of
hurting the actor ("You MUST NOT publish DKIM private keys in DNS") or hurt
others ("You MUST NOT operate as an open relay.") If we are going to
constrain with good reason, we need to be clear about the reason. For this
case, I would add something to explain the directive, such as:
"Any attempt to evaluate multiple author domains would create excessively
complexity in software while introducing a denial of service attack
vector. Therefore, evaluators SHOULD not do so."
For result classification, I would punt this way:
"Local policy can choose whether to treat such messages as NONE, PERMERROR,
or FAIL."
Doug
On Thu, Dec 9, 2021 at 11:13 AM Todd Herr <todd.herr=
[email protected]> wrote:
> 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
>
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
