On Mon, Mar 23, 2015 at 7:27 AM, Franck Martin <fra...@peachymango.org> 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
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
