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

From: Franck Martin <[email-masked]>
Date: Mon, 27 Apr 2015 19:52:26 -0500 (CDT)

Sorry for delay, Elizabeth did more fixing and I'm going through the reviews now. See comments inline. 

----- Original Message -----

> From: "Murray S. Kucherawy" <[email-masked]>
> To: "Franck Martin" <[email-masked]>
> Cc: "dmarc" <[email-masked]>
> Sent: Tuesday, March 31, 2015 1:01:15 PM
> Subject: Re: [dmarc-ietf] New Version Notification for
> draft-ietf-dmarc-interoperability-01.txt

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

fixed 

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

fixed 

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

fixed 

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

fixed 

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

fixed 

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

fixed 

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

true, but early implementation may not have been that great too 

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

fixed 

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

fixed 

> Section 3.1.2.1 :

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

fixed 

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

group syntax does not give you a domain. 

From: undisclosed-sender; 

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

sure but "SIEVE may become an issue when the email is reintroduced in the transport infrastructure." 

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

this is the problem section, solutions are later 

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

added but differently 

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

fixed 

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

fixed 

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

just DMARC, fixed 

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

added some and your point 

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

fixed 

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

fixed 

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

fixed 

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

gone 

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

fixed 

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

fixed 

> That's it for this pass.
> -MSK

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc