On 01/22/2015 09:46 PM, Franck Martin 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,
the current draft is heading for Informational status, not standard
status. Having said that I fully agree with:
I'd like to see more code before I form an opinion.
as from an interoperability point of view it is important to know what
the various implementations of the current implementors do exactly with
SPF re. the point raised by Anne (SPF use of RFC5321.MailFrom vs.
RFC5321.EHLO/HELO).
As for the 'SPF part of DMARC only an 'SPF pass' counts it must be
crystal clear how an 'SPF pass' is reached. Therefore, if (repeat: if)
all current implementations of DMARC only use the RFC5321.MailFrom, I'd
suggest to use RFC2119 terminology here, like:
-13 text:
Note that the RFC5321.HELO identity is not typically used in the
context of DMARC (except when required to "fake" an
otherwise null
reverse-path), even though a "pure SPF" implementation
according to
[SPF] would check that identifier.
Suggested text:
If RFC5321.MailFrom identity is present and not null, the RFC5321.HELO
identity MUST NOT be used in the
context of DMARC, even though a "pure SPF" implementation
according to
[SPF] would check that identifier.
/rolf
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
