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

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 7 Dec 2015 07:23:52 -0800

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

---

From: Eliot Lear <[email-masked]>
Date: Tue, 8 Dec 2015 19:26:02 +0100

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

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 8 Dec 2015 12:20:19 -0800

> the token.  Depending on their length I would drop these inline or in an

I can put together an appendix with some examples. I was thinking that
having a better explanation would provide more value so I guess I got your
suggestion backwards :-)

--Kurt

---

From: "John Levine" <[email-masked]>
Date: 8 Dec 2015 21:00:31 -0000

>having a better explanation would provide more value so I guess I got your

I'd prefer that you post the current version of the draft so we can
see what the context is.  Draft revisions are cheap, posting three in
a week if there are changes is not unreasonable.

R's,
John

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 8 Dec 2015 15:57:24 -0800

> a week if there are changes is not unreasonable.

-13 has now been posted with these changes in full context.

--Kurt

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Thu, 10 Dec 2015 02:19:15 +0900

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

 > 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

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

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

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

>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"?

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

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 10 Dec 2015 23:05:43 -0800

>     message, though they usually do.

Do we think that's necessary here, or is that same advice which is (I'm
fairly sure) present in RFC6376 and RFC7208 sufficient?  I guess another
way to word that is: How independent is this work from full understanding
of those?

I suppose in the end it can't hurt to be sure and repeat this caveat here.

> the "sender" is (author? RFC5322.sender?)

I would also change "In the SPF" to "In that", since the context is
established in the first sentence.

I agree, I'm not sure what that second sentence says at all.

-MSK

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 12 Dec 2015 17:19:01 +0900

Murray S. Kucherawy writes:
 > On Wed, Dec 9, 2015 at 9:19 AM, Stephen J. Turnbull <[email-masked]> wrote:

 >>     bear no relationship ...

 > Do we think that's necessary here, or is that same advice which is
 > (I'm fairly sure) present in RFC6376 and RFC7208 sufficient?  I
 > guess another way to word that is: How independent is this work
 > from full understanding of those?

I've already expressed my opinion, but I hope I'll be forgiven a gloss
on my previous words.

In Mailman we have three levels of "ownership": *list*, (virtual)
*domain*, and *site* (host system).  Mailman list and domain owners
can choose their mitigation policies, and they need a guide.  I hope
this BCP can be written in a way that allows them to identify their
own use case, and choose an appropriate mitigation.  Needless to say,
almost all of them would find RFCs 6376 and 7208 useless, and many
site owners are in the same boat -- they don't really understand MTAs,
MIME, HTML (sorry, but yeah that's necessary), or digital signatures,
and most are kinda fuzzy on the roles of MUAs and the email header.
Mailman has already pretty much decided what mitigations we can and
will implement; I haven't seen anything else we need to do.

I suspect most indirect mailflow managers are in the same boat.  It
seems to me that more than the implementers themselves, it's going to
be system managers choosing implementations and channel managers
choosing behaviors who need refer to, and will benefit from, this BCP.

Steve