On January 21, 2015 5:01:53 PM EST, Franck Martin <fra...@peachymango.org> wrote: > > > > >----- Original Message ----- >> From: "Scott Kitterman" <skl...@kitterman.com> >> To: dmarc@ietf.org >> Sent: Tuesday, January 20, 2015 9:36:57 PM >> Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it >> >> On January 21, 2015 12:31:45 AM EST, Franck Martin ><fra...@peachymango.org> >> wrote: >> > >> >----- Original Message ----- >> >> From: "Scott Kitterman" <skl...@kitterman.com> >> >> To: dmarc@ietf.org >> >> Sent: Tuesday, January 20, 2015 9:02:26 PM >> >> Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at >it >> >> >> >> On Tuesday, January 20, 2015 17:40:39 Franck Martin wrote: >> >> > ----- Original Message ----- >> >> > >> >> > > From: "Scott Kitterman" <skl...@kitterman.com> >> >> > > To: dmarc@ietf.org >> >> > > Sent: Tuesday, January 20, 2015 2:49:01 PM >> >> > > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while >I'm >> >at it >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > Last time I had stats, it was about 10% as common as Mail From >> >oriented >> >> > > records. Much less common, but I wouldn't say rare. When >done >> >this way, >> >> > > there isn't a singe "SPF" result, there are two: SPF/Mail From >> >and >> >> > > SPF/HELO. Only SPF/Mail From is relevant to DMARC. >> >> > >> >> > Why do you say that? >> >> > >> >> > DMARC takes the result from SPF (pass/fail/...) and the string >that >> >SPF >> >> > used >> >> > for this result be it mail from or helo, to check for alignment. >> >> > >> >> > Did I miss something? >> >> >> >> DMARC takes the SPF result and the Mail From as an input (which in >> >the case >> >> of >> >> a null Mail From is a synthetic Mail From built using HELO, but >> >that's just a >> >> coincidence). SPF isn't just a result (pass, fail, etc), it also >has >> >a >> >> domain >> >> and a related identity. >> >> >> > >> >If I recall the SPF spec, it specifies a MAIL FROM which is not the >> >RFC5321.mailfrom, but a mix of RFC5321.mailfrom and RFC5321.helo >based >> >on which one was used to get the SPF result. >> > >> >The original SPF spec is quite confusing on that, at least for me. >On >> >senderid, I think they call this field mfrom to avoid confusion. >> > >> >It seems weird that the SPF results would depend more on the HELO >than >> >the RFC5321.mailfrom because if spammer.com put a SPF then >> > >> >mailfrom: secur...@example.com >> >helo spammer.com >> > >> >would seem quite problematic.... >> >> Which is precisely why I said HELO pass doesn't mean anything. HELO >is really >> for rejection on fail. >> >>From http://www.openspf.org/Implementations Mail::SPF has passed the >test suites > >http://search.cpan.org/dist/Mail-SPF/lib/Mail/SPF/Request.pm >"Note: In the case of an empty MAIL FROM SMTP transaction parameter >(MAIL FROM:<>), you should perform a check with the helo scope >instead." > >I think we are going in circles here. > >The SPF spec is not clear or there is a disconnect with what's out >there, or both...
By design, SPF doesn't go very far into what receivers should do. Unlike DMARC, it actively avoids specifying receiver policy. It's not clear what to do because what to do is outside the scope of the specification. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
