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