----- Original Message -----
> From: "Rolf E. Sonneveld" <[email protected]>
> To: "Franck Martin" <[email protected]>, "Michael Jack Assels"
> <[email protected]>
> Cc: [email protected]
> Sent: Thursday, January 22, 2015 3:08:51 PM
> Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny
> nits, while I'm at it
>
> On 01/22/2015 09:46 PM, Franck Martin wrote:
> >
> >
> >
> > ----- Original Message -----
> >> From: "Michael Jack Assels" <[email protected]>
> >> To: [email protected]
> >> 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 <[email protected]> wrote:
> >>
> >>> ----- Original Message -----
> >>>
> >>>> From: "Murray S. Kucherawy" <[email protected]>
> >>>> To: [email protected]
> >>>> 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 <
> >>>> [email protected] >
> >>>> 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.
>
No, no... :P
if you send a bounce, and usually some MTAs have trouble to sign the bounce
they generate (not anymore true with postfix but a bit tricky to setup), then
the only way to recover the message is to ensure there is an SPF aligned on the
string presented by HELO.
So basically, I would say DMARC takes only the result of the check_host for the
MAIL FROM entity which contains the postmaster@helo if the RFC5321.mailfrom is
empty.
Murray, I think the elegant way in DMARC to refer to RFC7208 is this.
"DMARC uses only the result of the check_host() applied on the MAIL FROM entity
as defined by RFC7208. The MAIL FROM entity is the one used for alignment
checking.".
If I recall the operational test created by Tim, were checking these cases:
http://dmarc-qa.com/ (2.1)
We all ran these tests during inter-op for conformance.
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
