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