On Thursday, January 22, 2015 20:16:30 Franck Martin wrote: > ----- Original Message ----- > > > From: [email protected] > > To: "John Levine" <[email protected]> > > Cc: [email protected], [email protected] > > Sent: Thursday, January 22, 2015 5:41:46 PM > > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny > > nits, while I'm at it> > > > >DMARC leverages the Mail From identity, so I don't see how independent > > > >HELO checks can be relevant. > > > > > > If you look at sections 2.3 and 2.4 of RFC 7208, a reasonable > > > interpretation is that you check the HELO identity, and if you get a > > > "definitive policy" result, you're done and return that to the caller. > > > > > > So a message comes from host mail.provider.com with From: > > > [email protected]. The recipient host does an SPF check on > > > mail.provider.com, it passes, so SPF is done. DMARC sees that the SPF > > > domain isn't aligned so it ignores it, and DMARC says it's unaligned, > > > even though an SPF check of customer.com might have passed. > > > > > > I can't say whether this is a bug in 7208 or a fundamental flaw in > > > DMARC, but something is clearly wrong and this does not match what > > > running code does. As things are written now, I don't see any way to > > > demand that SPF look at the MAIL FROM if it likes the HELO. > > > > > > Fix 1: file an erratum on 7208 to say to switch the order, do the MAIL > > > FROM check first and only do the HELO check otherwise. This may match > > > some running code, I haven't looked. > > > > > > Fix 2: change 7208 to say that SPF can return multiple results. Ugh. > > > > Filing an erratum for purposes of documenting the issue is fine, but since > > this > > is a substantive change to the protocol it far exceeds the scope of what > > approval of an erratum is allowed to do. As such, I believe the best > > outcome you can get here would be "held for document update". > > I tried to understand Scott, and I think this is what is missing in RFC7208. > > Each check_host() is meant to be done as soon as you have the data to do it. > > So after the HELO phase in SMTP RFC5321, you do check_host(HELO identity, > IP). You get a result and apply the SPF policy (and disconnect if policy > says so) after the mail from phase, you do check_host(MAIL FROM identity, > IP). You get a result and apply the SPF policy (and disconnect if policy > says so) > > This makes sense then, except when SPF policy on both check_host is not -all > > The difficulty then comes when you do these check_host() later in the > RFC5321 transaction, as you have to emulate, this serialization. And then > there is still some uncertainty on what to do when both SPF records exist > and do not have -all both (or when receivers consider -all as ~all)
There is no uncertainty. What you do it apply local policy. End of story. The only tricky part is you have to decide what local policy is. This is not new. > I think RFC7208 confused more this serialization, that was implicit in > RFC4408, like the elephant in the room. :P > > To come back to operational matters, I think SPF implementations just do > check_host(MAIL FROM identity, IP) as Terry pointed out, this is why I > suggest DMARC spec could just say that: "DMARC uses only the MAIL FROM > identity and results of the check_host() of the MAIL FROM identity as > defined in RFC7208)" > > And we will fix RFC7208 later to match operational deployments, but this > ought to be recorded somewhere. > > (add reporting to emails, and you get plenty new questions about > standardizations :P) What the code I've written and distributed does is check HELO and if there's not a reject (definitive result) store the helo result and then check Mail From (using the synthetic postmaster@HELO if needed). If the message is not rejected/deferred then the appropriate result header (SPF Received or auth- res) is added for both results. There is a configuration option to only check HELO if Mail From is null, but it's not the default. By default, Postfix (which is what I'm writing for) delays all such checks until rcpt to, so no. There's absolutely no need to do check_host() as soon as you have the information. IIRC I first wrote that code in about 2007 based on RFC 4408. The only way it didn't do explicitly what 4408 required was that it didn't both doing a Mail >From check that would have been pointless since the message was already going to be rejected. We fixed that bug in the spec in RFC 7208 during SPFbis. I really think this is making a mountain out of the tiniest of molehills. Recall: The almost complete lack of receiver policy specification in RFC 4408 (and RFC 7208) is not an oversight. It was a deliberate design choice. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
