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

["Kurt Andersen (b)" <[e-mail]>]

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].