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

["Stephen J. Turnbull" <[e-mail]>]

Kurt Andersen (b) writes:

 > Proposed rework:

I'll look at -13 later.  Right now work is scrambling my brain so want
to write this while I'm thinking of it.  Basically, I find the wording
too technology-oriented, making it difficult for me to see the actual
problem domain.  As I see it, unlike the specifications it discusses
which address implementers, this draft addresses less technical admins
as well as the implementer/admins who hang out on this list.  (Eg, I'd
like to be able to quote chapter and verse on Mailman-Users.)

Disclaimer: All suggestions are written in my dialect and style in the
hope that they will be useful in some part.  I don't expect them to be
adopted verbatim (and they might look weird in context anyway).

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

I would add

    The Authenticated Identifiers defined by these specifications need
    bear no relationship whatsoever to the content provided by the
    author of the message or even to the system which injected the
    message, though they usually do.

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

I would substitute

    DMARC adopts these definitions, and further requires a relationship
    called "Identifier Alignment" between at least one of the
    Authenticated Identifiers and the domain found in the message's
    RFC5322.from header field[RFC5322].

 > 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

>From the Picky-Picky Department:
There are no interoperability issues between strict and relaxed modes,
except that the receiver must implement and select the correct mode as
chosen by the sender.  Better

    strict and relaxed modes exhibit very similar interoperability
    issues, but

 > strict mode constraining the application of possible solutions.

constraining -> constrains.  I prefer "applicability" to "application"
slightly.  Also, DMARC p=reject used for non-transactional mail is a
problem without real solutions at present.  The best we can do is
mitigate.

 > The mitigations described in this document generally require a relaxed
 > mode of Identifier Alignment.

"the relaxed mode".

Mention "multiple RFC5322.from domains" issue here?  E.g.,

    RFC 5322 permits only one From header field, but it may contain
    multiple addresses [mailboxes?].  Since DKIM requires only one
    valid signature, if the domains differ, an attacker could add
    their domain to the RFC5322.from field, provide arbitrary new
    content, and sign the message.  Therefore, DMARC chooses to
    require that there be only one domain in the RFC5322.from field,
    and in practice, since multiple addresses that field are extremely
    rare, implementations may require a single address.

I forget how that last came down.  Maybe DMARC itself now requires a
single address.

 > 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

>From the Picky-Picky Department: At least in my dialect of English,
the DKIM identifiers are never "relevant to" the content.  How about
"consistent with"?

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

Picky-Picky Department: Isn't the DMARC terminology "failing
Identifier Alignment" for the case where no Authenticated Indentifier
is found as well as when there's a mismatch?

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

I don't understand the last sentence, specifically why automated
bounces would lead to a misunderstanding of SPF identifiers, and who
the "sender" is (author? RFC5322.sender?)

Regards,

Steve