On January 22, 2015 3:46:59 PM EST, 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: >> >> > ----- Original Message ----- >> > >> > > From: "Murray S. Kucherawy" <superu...@gmail.com> >> > > To: dmarc@ietf.org >> > > Sent: Thursday, January 22, 2015 10:27:40 AM >> > > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two >more >> > > tiny nits, while I'm at it >> > >> > > On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy < >> > > superu...@gmail.com > >> > > wrote: >> > >> > > > I am asking the IESG and the ISE what the process is for >> > > > making such adjustments now. >> > > >> > >> > > > Mainly my resistance to further change comes from the fact >> > > > that we've done last calls of varying kinds on this >> > > > document more times than I can count. It really is time to >> > > > put the non-IETF version to bed and hand it off, even with >> > > > its weaknesses, and let the standards process take it from >> > > > there. There's a working group already chartered to do >> > > > exactly that; in fact, that was one of the premises of >> > > > creating that working group. >> > > >> >> > > I've consulted with the Area Director sponsoring the >> > > document's conflict review, and the ISE. Both of them agree >> > > that we will only make changes approved by the ISE and only >> > > during AUTH48 at this point, and those will be limited to >> > > correcting serious problems that would prevent current DMARC >> > > implementations from interacting properly. Anything else can >> > > be left to the DMARC working group on its standards track >> > > deliverable. >> > >> > > An argument can be made that this proposed change qualifies >> > > under that definition, so please review it and comment as to >> > > whether it satisfies the defect identified, or whether the >> > > change is necessary at all. I will assume "yes" unless I hear >> > > otherwise. Again, the diff is here: >> > >> > > http://www.blackops.org/~msk/dmarc/diff.html >> > >> > 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." > >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.
Mail::SPF is a library that can be called by various applications. It's not an application which is where such logic would be implemented. You're quoting one library author's recommendations to application developers, not an actual implementation detail. Note:also not yet updated for RFC 7208. Also, DMARC isn't standards track. DMARC leverages the Mail From identity, so I don't see how independent HELO checks can be relevant. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
