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