On 12/20/2014 11:18 PM, Jim Fenton wrote: >> 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.
Jim, It's not 'overloading' anything. Authentication is a term of art. It's meaning is well-established. For example: Internet Security Glossary, Version 2 https://tools.ietf.org/html/rfc4949 $ authentication (I) The process of verifying a claim that a system entity or system resource has a certain attribute value. There are many authentication mechanisms. The issue is not whether DMARC's authentication is 'different from' SPF or DKIM. The issue is whether it is authenticating something. It is. The fact that SPF and DKIM are in the mix is not relevant to the question of whether DMARC is authenticating something. It is authenticating the domain name in the rfc5322.From field. Neither SPF nor DKIM make any assertions about the validity of the domain name in the rfc5322.From field. > 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. The results of SPF and DKIM say nothing about the rfc5322.From field. The assertion of validity for the domain name in that field is a bit of value-add that is specific to DMARC. Value-add of that sort is classically called authentication. >>> 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 don't read that existing last sentence the way you do. However on reflection, I think the first sentence can be improved and would prefer some wording changes for the paragraph, too. Perhaps: DMARC's filtering function is based on whether the rfc5322.From field domain is aligned with (matches) an authenticated domain name from SPF or DKIM. When a message has a published DMARC policy associated with the domain name in the RFC5322.From field, and that domain is not validated through SPF or DKIM, the disposition of that message can be affected by the DMARC policy. >>> 4. Policy >>> >>> Paragraph 4 basically says, ... >> 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. It does not 'make SPF and DKIM more brittle'. It does not affect their operation at all. As for DMARC 'coming first', I don't understand that. DMARC can't operate without an existing SPF and/or DKIM infrastructure. At any rate, as for your 'it would be better' assertion, it well might be true. But responding to that concern can't happen in isolation. To deal with it appears to impose more overall complexity. And systems complexity creates its own base of errors that we would then have to deal with. >>> 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. 'Perfectly' and 'considerable' do tend to add a bit of marketing tone. I think that dropping those two words moves the entire paragraph into the realm of offering a simple and common justification for use of the DNS, presumably instead of inventing a new query mechanism. People often do not understand the benefit of re-using an existing mechanism rather than defining a new one, especially when the mechanism involves a deployment and operation of a global infrastructure. (cf, DKIM vs. IIM...) >>> 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? When the receiver has some basis for knowing that it's ok to deviate from this portion of the specification. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
