Sorry for delay, Elizabeth did more fixing and I'm going through the reviews now. See comments inline.
----- Original Message ----- > From: "Murray S. Kucherawy" <superu...@gmail.com> > To: "Franck Martin" <fra...@peachymango.org> > Cc: "dmarc" <dmarc@ietf.org> > 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 < 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 ] 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 > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
