On Friday, January 23, 2015 18:27:46 Anne Bennett wrote: > I seem to have wandered into a bit of a minefield. :-/ > > Obviously I like Murray's proposed changes, since they're > based on mine :-), but I see that he has added "typically" > in a couple of places... and I begin to understand why it's > necessary to waffle somewhat. > > > ** What is interoperability in this context? ** > > Interestingly, Murray explains that changes "will be limited to > correcting serious problems that would prevent current DMARC > implementations from interacting properly". If I may be a > bit pedantic for a moment, it doesn't look as though DMARC > implementations interact (with each other) at all. Rather, > as mail receivers, they "interact" with values published in > the DNS by mail senders. > > In that light, one could argue that a problem which prevents > a sending domain from predicting what "pass/fail/none" result > a DMARC-compliant receiver will assign to its messages, is a > problem which "prevents proper interaction". > > Unfortunately, since this effort is one to document what's out > there now, and since (it's slowly becoming clear to me) not > all DMARC implementations produce the same evaluation results, > it's impossible to define the DMARC mechanism unambiguously. > Murray would like the "goal posts [to] sit still for a while", > but I think the goal posts are behaving more like waves than > like particles! > > > ** A technical problem: how many results from SPF? ** > > [SPF] defines a test which is recommended to be applied to > two separate identifiers (HELO and MAIL FROM), where the receiver > can consider the results of each test independently. (However, > I can publish only one SPF record for a name - that is, I cannot > say "my policy is *this* if the name is used for HELO, but my > policy is *that* if it is used in MAIL FROM". But that's not a > topic for this list.)
FWIW, in a decade of doing SPF work I've yet to run into a case where this was a real life problem. > Along comes DMARC, which expects to receive *one* result from > "the SPF test", but there are *two* possible SPF tests. Scott > takes the position that this doesn't much matter, and for all > I know he may be right in practice, but from the point of view > of the poor sod trying to figure out what will happen when she > publishes SPF and DMARC records, it sure makes life difficult. > > I doubt we're going to be able to do much better than the > proposed "-13" (or something very similar) with respect to HELO, > but at least it raises the issue instead of leaving people like > me perplexed, and it admits that there's more than one way a > DMARC implementation could choose to use (or ignore!) the two > SPF results. > > > ** A "political" issue: how is receiver policy determined? ** > > Scott points out, with respect to the SPF RFCs, that the results > of each SPF check are unambiguous, that "The almost complete > lack of receiver policy specification in RFC 4408 (and RFC 7208) > is not an oversight. It was a deliberate design choice", and > that "[Franck's] mistake [is] to insist that there be one and > only one defined way to deal with SPF results from both HELO > and Mail From and there isn't". > > All of this is fair enough and true, but some of it is > tautological: the receiver can do as it pleases, and no one can > stuff an unwanted e-mail message down someone else's throat. > I suspect I can choose to refuse all mail on Tuesdays if I want > to, so certainly I can do whatever I wish with SPF results. > > I think that discussion about who determines the receiver's > policy misses the point. The current draft even states that > "Final disposition of a message is always a matter of local > policy". > > The point, IMHO, is that when I publish DMARC and SPF and > DKIM records, I should be able to reliably predict whether > a given message will result in a DMARC pass, fail, or none, > quite regardless of what the receiver will choose to do based > on that result. > > It looks as though that won't happen in this go-round, no > matter what. :-( You may not be able to get to 100%, but you can get very close. > > ** 4408 vs 7208 - does it matter? ** > > Hector points out that SPF implementations using the "obsoleted" > RFC 4408 will be around for some time, and expresses > the concern (if I understand him correctly) that if DMARC > references the newer 7208, there may be an implication that the > 5322.Authentication-Result header will be expected to be present > so DMARC can "consume" it. But there's no mention of the use > of these headers in the current draft (except, in passing, > "Original-Authentication-Results"). The draft mentions using > the *results* of the SPF and DKIM tests, but not how they are > obtained, and I think that may be the right approach. RFC 7208 didn't replace Received SPF, it just added reference to the A-R header field as an option. Since that was already documented in other RFCs, that didn't change anything. How authentication information is communicated to different parts of an entity's mail system is a local choice without a global interoperability impact. One way to do it is by adding either a Received SPF or A-R field to a message for consumption by a downstream process. There are others. In the case of SPF Received versus A-R, all that matters is that the SPF verifier includes the one that the downstream processor can use. Adding A-R to RFC 7208 changed nothing. Not trying to specify internal mail system design details (which is what the current DMARC draft does) is the correct approach. > Or, Hector, are you concerned that DMARC implementations > will be expected to *provide* one or both those headers, > and if so, that this should be explicitly stated? It would be SPF implementations. A DMARC verifier might need to be prepared to consume both data formats (as opendmarc does), but that's really not very hard. It's also unrelated to RFC 4408 versus RFC 7208 because even if RFC 4408 had never been updated, there were standards track RC defining how to use A-R to report SPF results. > > ** The word "contradiction" ** > > Murray proposed this text for 4.1, based on my suggestion: > > [SPF], which authenticates the domain found in an [SMTP] > MAIL command, or the domain found in the HELO/EHLO command if > the MAIL command has a null path. Note that in contradiction > to [SPF], in the context of DMARC, this latter identity is > typically only used in the case of a MAIL null path. > > Franck objects to the word "contradiction", and suggests: > > [SPF], which authenticates the HELO identity and the MAIL > FROM identity: the domain found in an [SMTP] MAIL command, > or the domain found in the HELO/EHLO command if the MAIL > command has a null path. Note that in the context of DMARC, > this later identity is only used. This is close. It's really only the SPF Mail From result that's used. The trick is that in the case of a null Mail From, that result is calculated using a synthetic Mail From built using the HELO domain. > Hmm. How about this: > > [SPF], which authenticates: > - the domain found in an [SMTP] HELO or EHLO command > (the "HELO result"), and/or > - the domain found in an [SMTP] MAIL command, or the domain > found in the HELO/EHLO command if the MAIL command has a > null path (the "MAIL FROM" result). > It is not specified whether DMARC uses the "HELO result" > or the "MAIL FROM result"; implementations differ. > > It certainly exposes the ugly truth. ;-) I think this is good too, but we can simplify it, I think. > But speaking of ugly truths, the document already allows for > differences; in section 6.7 we have: > > -12> DMARC-compliant Mail Receivers typically disregard any mail handling > -12> directive discovered as part of an authentication mechanism (e.g., > -12> ADSP, SPF) where a DMARC record is also discovered that specifies a > -12> policy other than "none". Deviating from this practice introduces > -12> inconsistency among DMARC operators in terms of handling of the > -12> message. However, such deviation is not proscribed. > > > ** A tiny rant ** > > Necessary as this flexibility is if this document is to be > finished any time soon, it causes problems for a person trying > to create SPF and DMARC records in a way that will not cause > more problems than it solves! While it's tempting to stay away > from this stuff until it all settles down, that's becoming more > difficult, and not only because my parent domain at work might > be poised to publish a DMARC record which could interfere with > my domain's outgoing mail. Even at home, a few months ago, > Gmail started tagging my outgoing mail as spam, and when I > tried to troubleshoot this, their "why is this spam" web page > essentially insisted that I publish an SPF record before going > any further! > (end of rant) > > It's only fair to admit that despite my frustration, I'm > grateful for all the work being done on these issues, both to > combat spam, and to document what on earth is going on. I appreciate you sticking with it. It's good to get in depth review from new sets of eyes. I certainly was sure I was sure I knew what the discussion about SPF meant, but then I already knew what was intended, so it's good to have someone else reviewing. How about this: [SPF] can authenticate both the domain found in an [SMTP] HELO/EHLO command (the HELO identity) and the domain found in an [SMTP] MAIL command (the MAIL FROM identity). DMARC uses the result of SPF authentication of the MAIL FROM identity. Section 2.4 of [SPF] describes SPF MAIL FROM processing for cases in which the MAIL command has a null path. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
