On Fri, Jan 23, 2015 at 3:27 PM, Anne Bennett <[email protected]> wrote:
> ** 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. > Right. The statement is a very general one about making edits this late in a protocol document's life cycle, not something specific to how DMARC works. 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". > I think that's impossible to resolve completely because, for a given receiver, there's no guarantee that you'll be told your message was rejected specifically because of DMARC policy. Some operators specifically choose never to reveal which test you failed so that you don't have any specific information about how to get through their filters. (See Section 5 of RFC7372.) Thus, you may never know what result a DMARC-compliant receiver assigns to your messages since there are other factors that can come into play before your message gets rejected. > 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! > You're not talking about the same goal posts I am. The DMARC document has been alive for no less than three years, and we've had one last call after another for making changes or finding defects. The changes get made, everyone says we're ready, we make some progress, and then some other big change gets proposed. I believe we've reached a point of diminishing returns for this version of the document, imperfect as it might still be, in terms of holding it for one more edit and one more edit. Despite issues like the one you've raised that might still be in there, there's also abundant evidence that it is useful to some operators in its current form. That might be because they've all assumed, agreed, etc., that the HELO value is not used, and just forgot to write that down. Or it might be coincidence that many (but not all) implemented it that way since the goal is to match as well as possible against what's in the From: field. For reasons not worth getting into now, this version of the base specification is on track to be published not as a standard but as an "Informational" document, kind of as a handoff step between the team that first developed DMARC and the IETF, which is more rigorous in terms of developing standards. The goal posts to which I'm referring are the completion of that handoff. We need to publish DMARC in its current state, even if it's not full-standard quality yet, to do so. If we reset that process every time a defect is identified, we might not be done for a really long time. DMARC will not be final when this version is published. If it's broken, I agree it should be fixed, and we have a process for that. This iteration of the document, though, shouldn't be held indefinitely. So how long is long enough? We need to draw a line someplace, and hand off what's left to the working group for a proper standardization effort. I've already opened a ticket in the working group's tracker identifying this issue so the working group can decide if and how it wants to handle this matter. > 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. > But how can you tell? I'm not trying to deflect your question -- I know you want at least the DMARC part to be deterministic, which isn't an unreasonable request -- but there's really no way to determine whether a particular receiver is applying bare DMARC or is applying local stuff on top of it. So if receiver behaviour is unreliable in the first place, how can one reasonably claim that this is clearly a defect in DMARC? DMARC's not introducing that uncertainty; clearly the issue you're talking about certainly isn't helping it either, but it's not as if resolving that here will suddenly make receiver handling of email deterministic. ** 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. > There is no prescription of how SPF or DKIM results are communicated to the DMARC agent. Authentication-Results (RFC7001) is one way, but it's not the only way. There are DMARC implementations (mine, for example), that use that header field to signal results between modules attached to the MTA, but there are commercial implementations where that information is passed across API calls within the same process. It doesn't matter, really, so DMARC doesn't specify. So I claim "will be expected" is false. Moreover, Authentication-Results does support returning two SPF results, and disambiguating them. On the other hand, RFC7001 is the suggested way to report DMARC results to whatever wants to consume them, though again that's not mandatory. Personally, I fall on the "doesn't matter" side because I don't believe this is a change in behaviour between the two versions of the SPF specification. Both of them say checking HELO is RECOMMENDED, leaving it to the careful discretion of the receiver. We'd therefore have to have a rather good reason for making a normative reference in DMARC to an obsolete document. ** 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. > > 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. > I would leave off "implementations differ", but that's fine with me if it's fine with others. It's probably more accurate. > 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. > This is there for two reasons: a) because (as you've acknowledged) we can't force the receiver to do anything; and b) because if SPF rejects the message by enforcing "-all" after MAIL FROM, there's no chance for DKIM to report a "pass", which could satisfy the DMARC test. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
