Subject: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-interoperability-01.txt

From: Franck Martin <[email-masked]>
Date: Mon, 23 Mar 2015 09:27:28 -0500 (CDT)

Looking better... 

Special thanks to Elizabeth for improving the document after I integrated (all?) previous comments. Please see this revision and post comments/reviews against it. 

Thanks. 

A new version of I-D, draft-ietf-dmarc-interoperability-01.txt 
has been successfully submitted by Franck Martin and posted to the 
IETF repository. 

Name: draft-ietf-dmarc-interoperability 
Revision: 01 
Title: Interoperability Issues Between DMARC and Indirect Email Flows 
Document date: 2015-03-20 
Group: dmarc 
Pages: 19 
URL: http://www.ietf.org/internet-drafts/draft-ietf-dmarc-interoperability-01.txt 
Status: https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ 
Htmlized: http://tools.ietf.org/html/draft-ietf-dmarc-interoperability-01 
Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-interoperability-01 

Abstract: 
DMARC introduces a mechanism for expressing domain-level policies and 
preferences for email message validation, disposition, and reporting. 
The DMARC mechanism can encounter interoperability issues when 
messages originate from third party sources, are modified in transit, 
or are forwarded enroute to their final destination. Collectively 
these email flows are referred to as indirect email flows. This 
document describes interoperability issues between DMARC and indirect 
email flows. Possible methods for addressing interoperability issues 
are presented. 

Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org. 

The IETF Secretariat

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 31 Mar 2015 13:01:15 -0700

On Mon, Mar 23, 2015 at 7:27 AM, Franck Martin <[email-masked]>
wrote:

> Looking better...
>
> Special thanks to Elizabeth for improving the document after I integrated
> (all?) previous comments. Please see this revision and post
> comments/reviews against it.
>

It sure seems better.  :-)

A few comments on this version:

Section 1 and the Abstract use an impersonal writing style (this document
does this, this section does that) while in Section 2 it changes to using
"we".  I suggest sticking with the former style.

OLD:

   What do we mean by "interoperability issues"?  We say that DMARC
   introduces interoperability issues or problems, when conformance to
   the DMARC specification leads an implementation to reject a message
   that is both compliant with the architecture as specified in
   [RFC5598 <http://tools.ietf.org/html/rfc5598>] and would have been
viewed as legitimate in the eyes of the
   intended recipient.  Therefore, we can already conclude that DMARC
   poses no interoperability problems when legitimate messages properly
   validate through its specified processes.  The rest of this section
   delves into how legitimate messages may get rejected.

NEW:

Interoperability issues are introduced when conformance to the DMARC
specification leads an implementation to reject a message that is both
compliant with the architecture as specified in [RFC5598] and would
have been viewed as legitimate in the eyes of the intended recipient.
Therefore, it can already be concluded that DMARC poses no interoperability
problems when legitimate messages properly validate through its specified
processes.  The rest of this section delves into how legitimate messages can
be rejected.

...etc.

The last paragraph of Section 2.1 opens with a run-on sentence.  Also,
since that chapter is entirely about SPF, all of the [RFC7208]
references can be omitted; they make an already-long sentence rather
cluttered.

Also, this paragraph (and I think the one before it as well) talk
about alignment being defined as the two identifiers sharing the same
Organizational Domain, but in fact that depends on whether relaxed or
strict mode is active, right?

It also has this:

   Even when an SPF record exists for the domain in RFC5322
<http://tools.ietf.org/html/rfc5322>.From, SPF
   will not authenticate it unless it is also the domain SPF checks.

I'm confused.  When is the SPF record for the RFC5322.From domain ever
checked? Shouldn't that be the DMARC policy, not the SPF policy?

In Section 2.3, the "RFC6376 [RFC6376]" is redundant and can be cleaned up.

What does "Furthermore, the use of the length flag is by no means
universal." mean?  Does that mean not everyone uses it, or not all
software implements it?

"DKIM has two canonicalizations: simple and relaxed." ...is true for
both the header and the body.

"The relaxed canonicalization used to be computing intensive and may
not have been preferred in the early deployment of DKIM." It's still
true that relaxed requires more processing than strict, but I've never
heard that used as a basis for not using it.  It's not a heavyweight
process.

Section 3.1.1:

"marked by an inherent difficulty in modifying" -- It's not modifying
that's hard, it's establishing alignment that's hard.

A pure syntax point: All the entries in that bullet list end in
periods, but are not capitalized; either make them phrases (drop the
period) or make them sentences (capitalize)

Section 3.1.2.1:

Should "8-bit mail" be "8-bit MIME"?  I don't know what a "mail section" is.

Also, I think RFC6376 has some discussion about this.  Might be useful
to refer to it.

Section 3.1.2.2:

"In addition, group syntax will remove the ability for the DMARC
mechanism to find an Organizational Domain that aligns with any
authenticated domain identifier from SPF or DKIM."  Is that strictly
true?  Didn't we say in DMARC (I forget now) that a receiver could
evaluate all such domains?  Or am I thinking of the wrong problem?

Section 3.1.3 talks about application of SIEVE, but wouldn't that sort
of thing happen after SPF and DKIM have already been evaluated?

Section 3.2.3, same earlier syntax point about the bullet list.  Also,
RFC6377 contains a more detailed description of the third-party bounce
problem and how it can be destructive.

Would it be worth pointing out that the typical MLM changes are not
only common, but perfectly valid within the context of email?  Or that
declaring those things as no-longer-permitted is not likely to
succeed?

Section 3.2.4: "acquired companies domains" should be "acquired
company's domains".  Also "To: header" should be "RFC5322.To header
field".

Section 3.2.5 should mention that whether a boundary filter introduces
an interop problem depends on where the DKIM and SPF evaluations are
done.  If they're inside a modifying filter, there's a problem, but
not otherwise.

Section 4: "proper handling multiple DKIM signatures" should be
"proper handling of multiple DKIM signatures"

Also Section 4: What are "the DMARC headers"?

Section 4.1: Should we list potential side effects of each of these?
Changing the From: to something aligned affects what the end user will
see as the author, for example.

Section 4.2: "email headers" should be "email header fields",
"preferring preserving" should be "preferring to preserve"

Section 4.3: Another "header" that should be "header field", and
"yet-another" shouldn't have a hyphen.

Section 4.4.1.2: "email headers" to "email header fields"

Section 4.4.1.3: "at the appreciation of the postmaster"?  I'm not
familiar with that expression.  Perhaps "at the discretion of the mail
administrator"?

Section 4.5.1: "depending if" -> "depending on whether".  Also the
bullet starting "Finally" is (a) comma-spliced, and (b) not the final
item in the list.  And the reference to RFC7372 is correct, but it
might be worth saying that it's not widely deployed yet.

Section 4.6: Misspelling of "alignment".  More generally, I'm confused
by what this section is saying.  How is the message store involved in
DMARC?

That's it for this pass.

-MSK