----- 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.... _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
