On January 22, 2015 4:20:35 PM EST, Michael Jack Assels 
<mjass...@encs.concordia.ca> wrote:
>On Thu, 22 Jan 2015 14:46:59 CST, 
>Franck Martin <fra...@peachymango.org> wrote:
>
>> ----- Original Message -----
>> > From: "Michael Jack Assels" <mjass...@encs.concordia.ca>
>> > To: dmarc@ietf.org
>> > Sent: Thursday, January 22, 2015 12:00:58 PM
>> > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two
>more tiny nits, while I'm at it
>> > 
>> > On Thu, 22 Jan 2015 12:48:03 CST,
>> > Franck Martin <fra...@peachymango.org> wrote:
>> > 
>> > > [....]
>> > > 
>> > > Hold on...
>> > > 
>> > > What is the decision matrix of SPF?
>> > > 
>> > > SPF uses two strings, the RFC5321.mailfrom and the
>> > > RFC5321.helo. Each string may or may not have an SPF record.
>> > > What gives the spf status?
>> > 
>> > As I read RFC7208, it doesn't explicitly provide a decision
>> > matrix, but it does clearly recommend in section 2.3, that
>> > [i]f a conclusive determination about the message can be made
>> > based on a check of "HELO", then the use of DNS resources to
>> > process the typically more complex "MAIL FROM" can be avoided."
>> > 
>> > Section 2.4 provides that "SPF verifiers MUST check the
>> > [RFC5321.mailfrom] identity if a [RFC5321.helo] check either
>> > has not been performed or has not reached a definitive policy"
>> > 
>> > I can't think of a way to read that that doesn't imply that
>> > a "pass" or a "fail" on the basis of an SPF record for the
>> > RFC5321.helo indentity (if such a record exists) is the spf
>> > result; otherwise, the result is based on the RFC5321.mailfrom
>> > identity.
>> > 
>> > I believe that this is not what DMARC implementations actually
>> > do, and that the proposed change to the draft correctly points
>> > out the difference and makes it clear what DMARC does, so if
>> > I had a vote, I'd vote "yes" to the change.
>> > 
>>
>> Ok, but a specific well known implementation does not seem to
>> do that: 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."
>
>This is what the proposed change says, isn't it?
>
>> an RFC to reach standard status needs to represent what is out
>> there, I'd like to see more code before I form an opinion.
>
>I think we've crossed wires here.  I unreservedly agree that
>RFC7208 does NOT represent what all DMARC implementations do,
>and it may not even represent what all SPF implementations do.
>Perhaps RFC7208 needs correction, but given what it says now,
>and given that DMARC has an obvious dependency on SPF, it's
>important that DMARC's standard should say "contrary to what
>RFC7208 recommends, DMARC normally SPF-checks HELO only when
>MAIL FROM is <>".
>
>I don't think we're disagreeing about what DMARC does, or even
>about what SPF usually does, despite what RFC7208 says.

I think that's close. DMARC doesn't do SPF, it uses SPF results. Nothing 
contrary to RFC 7208 (or 4408).  

Scott K


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to