On 12/19/2014 1:30 PM, Murray S. Kucherawy wrote: > Could I get the WG (forgive me, co-chairs!) to comment
Some of Jim's note are about writing style, precision, specific terminology usage, points of nuance, or requests for clarification. I'll leave clarification to Murry, and I'll assume that Murray and/or the RFC Editor will deal with such niceties. The niceties matter, but don't group require discussion, IMO. So my feedback is limited to points I consider substantive or even possibly controversial: Meta-concern: Since Jim cited paragraph numbers rather than explicitly quoting text, I've no idea whether I'm looking at the correct text. In fact, I've started to fear that his par numbering is zero based... Substative Meta-concern: It's important to distinguish between comments that make sense to pursue in an effort at further development -- that is, the new working group -- versus ones that clarify the existing spec or identify significant failures in it. > The posting: > http://www.ietf.org/mail-archive/web/dmarc/current/msg00764.html > From: Jim Fenton <fenton at bluepopcorn.net> > To: "dmarc at ietf.org" <dmarc at ietf.org> > Date: Wed, 16 Apr 2014 12:11:45 -0700 ... > Bullet 10: Again, DMARC doesn't do authentication, even for domains; it > relies on other authentication mechanisms. I originally thought this, too, but in fact DMARC does do authentication: DMARC asserts authenticity of the rfc5322.From field domain name. That's a distinct semantic increment over anything SPF or DKIM do on their own. > 3.1.2 General Concepts ... > Paragraph 3 doesn't quite capture the sense of alignment properly, > especially for SPF. A message that is authorized by SPF might have an > unaligned envelope-from address, so the validity of SPF for such > messages is moot. I think this is par. 2 in the -08 draft and that text looks fine to me. If someone thinks the text needs changing, they need to offer candidate text. > 3.2 Organizational Domain > > I remain very concerned about this algorithm since I have been > previously told very specifically not to do this by the DNS folks. I'm > also concerned about the inconsistency (interoperability impact) that > could result from different operators using different public suffix lists. Everyone is concerned about it. But it's the best that is currently available. > 4. Policy > > Paragraph 4 basically says, if you don't want a particular > authentication scheme to be considered by DMARC, don't use it at all. > For a domain that is using SPF and DMARC (for example), this could be an > impediment to their deployment of DKIM because they could not test with > it without having it immediately affect recipients' message handling. > One possibility would be to ignore DKIM if the testing (t=y) flag is > set, although a campaign would be needed to get the many domains > currently using t=y to turn it off. Another possibility would be to have > a setting in DMARC to ignore a specific authentication method entirely. The first possibility isn't viabile, for the reason cited. The second possibility might be worth pursuing in the DMARC working group, rather than in a document that captures existing DMARC practice. There are, of course, other possibilities, such as not having DMARC pursue operational nuance that makes the spec more complex, trying to handle special cases. That is, if a site isn't ready to use DMARC, it shouldn't. > 5. DMARC policy record > > Paragraph 2: Again, "matches perfectly with the DNS" is an inaccurate > characterization. If the query requirement matched perfectly with the > DNS, DNS would have a way to determine the Administrative Domain without > resorting to suffix lists and such. Just strike the sentence; this isn't > relevant here anyway. -08 doesn't have this language. > 7.1 Verifying External Destinations > > Paragraph 3: "verification steps SHOULD be taken" These steps are to > protect another domain from attack. It needs to be a MUST. 6.1 in -08. Given the problems with the search for org domain, a SHOULD is as far as is practical here. I'd suggest noting that that's a reason this can't be a MUST. > 8. Policy Discovery ... 5.6.3 in -08 > Second-to-last paragraph: "If the RFC5322.From domain does not exist in > the DNS" is basically changing what RFC5321/5322 allow. This isn't the > place to be making fundamental changes to the behavior of email. It isn't meant to be. -08 text says: "If the RFC5322.From domain does not exist in the DNS, Mail Receivers SHOULD direct the receiving SMTP server to reject the message. The choice of mechanism for such rejection and the implications of those choices are discussed in Section 9.3." I suggest removing it. Although a common anti-abuse mechanism, it's out of scope for DMARC. > 9. Domain Owner Actions 5.5 in -08 > Last paragraph doesn't seem like it fits. Suggest it be removed. While I could imagine a better place for it in the doc, having a /terse/ pointer like this to some authentication pedagogy seems useful to me, in an authentication-related spec... > 10.1 Extract author domain 6.6.1 in -08 > "Such messages SHOULD be rejected": looks like it's been removed. > 11.1 Discovery 6.2.1 in -08 > Mail Receivers can also discover reporting requests from the > Organizational Domain. That should be mentioned here. But I'm a little > confused why we have another Discovery section at all. The text's use of the word 'corresponds' handles the mapping to org domain, IMO. > 11.2.1 Email > > The whole thing about filenames needs to go away. Since it's only a > SHOULD requirement, the Report Receiver needs to be able to handle > reports that don't follow this format as well as those that do. "SHOULD" is a very strong normative statement. Note that it permits non-conformance only in the presence of singular knowledge by the non-conforming party. Filename labeling is generally considered useful. Why wouldn't it be useful here? > I also > wonder if some operating systems have trouble with filenames containing > the "!" character. If they are, they already need to be able to resolve the issue. > 14.1 Data Exposure Considerations > > Last paragraph: what's an "unexpected Mail Receiver"? > > The privacy consideration here, which isn't obvious from the wording, is > that users may currently use forwarding in a way that prevents the > sender from determining the ultimate delivery address. DMARC has the > potential to break that. This might be important in the case of a user > that is trying to distance themselves from a stalker. How is that a DMARC-specific 'exposure' consideration? > 14.2 Report Recipients > > Some potential exists for report recipients to perform traffic analysis: > to obtain metadata about the receiver's traffic. In addition to > verifying compliance with policies, receivers need to consider that > before sending reports to a third party. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
