Re: [dmarc-ietf] Proposed rework of the wording in section 2.1 of draft-dmarc-interoperability

[Eliot Lear <[e-mail]>]

Hi Kurt,

I need a bit more time to review this text, but I want to point out that
one of my main issues was that an example or two that highlights the
fields or the SMTP exchange would be helpful.  I am willing to toss
something together for the group's consideration if you want me to pass
the token.  Depending on their length I would drop these inline or in an
appendix.

Eliot


On 12/7/15 4:23 PM, Kurt Andersen (b) wrote:
> Rather than submit this directly as a draft update, I wanted to
> circulate my proposed change for "pre"comment to see if it addresses
> the concern with undue textual density in section 2.1, particularly
> the last paragraph about SPF identifiers. My proposed rework for
> section 2.1 follows below. I have split the section into subsections
> dealing each with the DKIM and SPF identifiers and expanded the
> discussion around the SPF identifiers.
>
> Comments welcome.
>
> --Kurt Andersen
>
> Currently, section 2.1 reads:
>
> 2.1. Identifier Alignment
>
> DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform message
> source validation. The DMARC [RFC7489] mechanism refers to source
> domains that are validated by DKIM or SPF as Authenticated
> Identifiers. DMARC requires an Authenticated Identifier to be related
> to the domain found in the message's RFC5322.from header field
> [RFC5322]. This relationship is referred to as Identifier Alignment.
>
> DMARC allows for Identifier Alignment to be achieved in two different
> modes: strict and relaxed. Strict mode requires an exact match of
> either of the Authenticated Identifiers to the message's RFC5322.from
> header field [RFC5322]. Relaxed mode allows for Identifier Alignment
> if Authenticated Identifiers and the message's RFC5322.from header
> field [RFC5322] share the same Organizational Domain. In general,
> interoperability issues between strict and relaxed modes are the same,
> with strict mode constraining the application of possible solutions.
> The mitigations described in this document generally require a relaxed
> mode of Identifier Alignment.
>
> DKIM provides a cryptographic means for a domain identifier to be
> associated with a particular message. As a standalone technology DKIM
> identifiers are not required to be relevant to the content of a
> message. However, for a DKIM identifier to align in DMARC, the signing
> domain of a valid signature must be part of the same Organizational
> Domain as the domain in the RFC5322.from header field [RFC5322].
>
> In addition, DKIM allows for the possibility of multiple valid
> signatures. The DMARC mechanism will process Authenticated Identifiers
> that are based on DKIM signatures until an aligned Authenticated
> Identifier is found (if any). However, operational experience has
> shown that some implementations have difficulty processing multiple
> signatures. The impact on DMARC processing is clear: implementations
> that cannot process multiple DKIM signatures may incorrectly flag
> messages as "failing DMARC" and erroneously apply DMARC based policy
> to otherwise conforming messages.
>
> SPF can provide two Authenticated Identifiers. The DMARC relevant
> Authenticated Identifiers that SPF provides is the RFC7208.MAILFROM
> [RFC7208] based on the RFC5321.mailfrom [RFC5321] domain, or, if the
> RFC5321.mailfrom address is absent (as in the case of "bounce"
> messages), on the RFC5321.HELO/EHLO SMTP domain. The SPF validated
> domain in RFC7208.MAILFROM must be part of the same Organizational
> Domain as the domain in the RFC5322.from header field to be aligned.
> It is important to note that even when an SPF record exists for the
> domain in RFC5322.from [RFC5322], SPF will not authenticate it unless
> it is also the domain checked by SPF. Also note that the
> RFC7208.MAILFROM definition is different from the RFC5321.mailfrom
> [RFC5321] definition.
>
> -----------------------
> Proposed rework:
>
> 2.1. Identifier Alignment
>
> DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform message
> source validation. The DMARC [RFC7489] mechanism refers to source
> domains that are validated by DKIM or SPF as Authenticated
> Identifiers. DMARC requires an Authenticated Identifier to be related
> to the domain found in the message's RFC5322.from header field
> [RFC5322]. This relationship is referred to as Identifier Alignment.
>
> DMARC allows for Identifier Alignment to be achieved in two different
> modes: strict and relaxed. Strict mode requires an exact match of
> either of the Authenticated Identifiers to the message's RFC5322.from
> header field [RFC5322]. Relaxed mode allows for Identifier Alignment
> if Authenticated Identifiers and the message's RFC5322.from header
> field [RFC5322] share the same Organizational Domain. In general,
> interoperability issues between strict and relaxed modes are the same,
> with strict mode constraining the application of possible solutions.
> The mitigations described in this document generally require a relaxed
> mode of Identifier Alignment.
>
> 2.1.1. DKIM Identifier(s)
>
> DKIM provides a cryptographic means for one or more domain identifier
> to be associated with a particular message. As a standalone technology
> DKIM identifiers are not required to be relevant to the content of a
> message. However, for a DKIM identifier to align in DMARC, the signing
> domain of a valid signature must be part of the same Organizational
> Domain as the domain in the RFC5322.from header field [RFC5322].
>
> In addition, DKIM allows for the possibility of multiple valid
> signatures. The DMARC mechanism will process Authenticated Identifiers
> that are based on DKIM signatures until an aligned Authenticated
> Identifier is found (if any). However, operational experience has
> shown that some implementations have difficulty processing multiple
> signatures. The impact on DMARC processing is clear: implementations
> that cannot process multiple DKIM signatures may incorrectly flag
> messages as "failing DMARC" and erroneously apply DMARC based policy
> to otherwise conforming messages.
>
> 2.1.2. SPF Identifier(s)
>
> The SPF specification [RFC7208] defines two Authenticated Identifiers
> for each message. These identifiers derive from:
>
>     a. the RFC5321.mailfrom [RFC5321] domain, and
>     b. the RFC5321.HELO/EHLO SMTP domain.
>
> In the SPF specification, the RFC7208.MAILFROM [RFC7208] value is
> defined to be based on RFC5321.mailfrom unless that value is absent
> (as in the case of "bounce" messages) in which case, the second
> (RFC5321.HELO/EHLO) identifier value is used. This "fallback"
> definition has occasionally been misunderstood by senders since
> "bounce" messages are often an "automatic" feature of MTA software.
>
> For the purposes of DMARC validation/alignment, the hybrid
> RFC7208.MAILFROM [RFC7208] identifier's domain is used if, and only
> if, it is aligned with the RFC5322.from [RFC5322] domain. The
> alignment of the validated domain is determined based on the DMARC
> record's "strict" or "relaxed" designation as described above for the
> DKIM identifiers and in [RFC7489].
>