----- Original Message ----- > From: ned+dm...@mrochek.com > To: "John Levine" <jo...@taugh.com> > Cc: dmarc@ietf.org, skl...@kitterman.com > 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: > > b...@customer.com. 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) 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) _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
