Hi, Dave - On 12/19/2014 02:30 PM, Dave Crocker wrote:
[2.4 Out of Scope] >> 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. What it does is different enough from SPF and DKIM that I think it's overloading the term "authentication" to use it again here. It doesn't contribute to a clear understanding. It looks at the results of SPF and DKIM, which operate at the domain level, so this bullet isn't really necessary. > > > >> 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. Yes, paragraph 2. My point is that a the last sentence seems to say that if a message arrives from a server authorized by SPF, it will not be affected by DMARC policies. > > If someone thinks the text needs changing, they need to offer candidate > text. DMARC's filtering function is based on whether SPF or DKIM can provide an authenticated, aligned identifier for the message under consideration. Messages that purport to be from a Domain Owner's domain and arrive from servers that are not authorized by that domain's SPF and do not contain an appropriate DKIM signature can be affected by DMARC policies. [I think the additional "that domain's" will do it.] > > > >> 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. The point is that use of DMARC may come first, and makes SPF and DKIM more brittle. Domains that have deployed DMARC may want to deploy both SPF and DKIM (having already deployed one or the other), but it would be better if they didn't have to turn off DMARC to do so. Agree that this is a bit of a corner case. > > >> 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. Now section 5.1, paragraph 2. Honestly, this reads like marketing fluff that doesn't belong in a specification like this. > > > >> 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. This is already predicated on having discovered the DMARC policy, so the org domain search is irrelevant. If this is only a SHOULD, under what circumstances might a Mail Receiver follow a different procedure, or not do this at all? This reporting procedure is one of the core aspects of DMARC; if someone is doing something different, I would think that the specification would want to say that it's not DMARC any more. > > > >> 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. +1 > > >> 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... The paragraph I was referencing (having to do with "mailto" URIs) is not in -08. > > >> 10.1 Extract author domain > 6.6.1 in -08 5.6.1, actually > >> "Such messages SHOULD be rejected": > looks like it's been removed. Yes, it has. > > >> 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. This is more of a comment about document organization. The previous sections have been talking about things that follow discovery of the policy record, and now when talking about aggregate reports there's another section about discovery. Why here; isn't this a little redundant? > > >> 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? SHOULD isn't strong enough for the Report Receiver to depend on. There are other ways to get the information that is encoded into the filename. If the spec wants to suggest, "here's a nice file name format that you MAY want to use", that's fine. But SHOULD is both too weak if the recipient can't depend on it and too strong if it's merely advice. > > >> 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. I suppose. Seems like there might be other choices that would be less likely to cause an issue, but I suspect that ship has sailed already. > > >> 14.1 Data Exposure Considerations Now section 8.1 >> >> Last paragraph: what's an "unexpected Mail Receiver"? That's now paragraph 5, and I now think it's clear enough. >> >> 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? Because it's the retrieval (or search for) the DMARC record might reveals that. But on rereading this, paragraph 4 addresses this sufficiently. New issue: Paragraph 3 refers to "Both report types" but since iodef was removed, it should just say "The AFRF report type". > > >> 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 -Jim _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
