On January 22, 2015 5:47:42 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 1:20:35 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 14:46:59 CST, >> 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: >> > > >> > > > [....] >> > > > >> > > > 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." >> >> This is what the proposed change says, isn't it? >> >> > 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. >> >> I think we've crossed wires here. I unreservedly agree that >> RFC7208 does NOT represent what all DMARC implementations do, >> and it may not even represent what all SPF implementations do. >> Perhaps RFC7208 needs correction, but given what it says now, >> and given that DMARC has an obvious dependency on SPF, it's >> important that DMARC's standard should say "contrary to what >> RFC7208 recommends, DMARC normally SPF-checks HELO only when >> MAIL FROM is <>". >> >> I don't think we're disagreeing about what DMARC does, or even >> about what SPF usually does, despite what RFC7208 says. >> > >Yes, this is my point, seems to me RFC7208 needs an errata... than >DMARC... but I'm ok with the proposed language, I just think DMARC >should avoid to fix problems with lower protocols... > > >If you read the previous RFC: >http://trac.tools.ietf.org/html/rfc4408 section 2.2 > > [RFC2821] allows the reverse-path to be null (see Section 4.5.5 in > RFC 2821). In this case, there is no explicit sender mailbox, and > such a message can be assumed to be a notification message from the > mail system itself. When the reverse-path is null, this document > defines the "MAIL FROM" identity to be the mailbox composed of the > localpart "postmaster" and the "HELO" identity (which may or may not > have been checked separately before). > > SPF clients MUST check the "MAIL FROM" identity. SPF clients check > the "MAIL FROM" identity by applying the check_host() function to the > "MAIL FROM" identity as the <sender>. > >so the MAIL FROM entity contains postmaster@helo if the >RFC5321.mailfrom is empty... > >Now in this document, it says to do the check_host on mail from and >helo separately, it says the check_host function will return a result, >and that result is deterministic, I see the code. However I reread >quickly the spec, it does not say how you would merge both results to a >single one: Did SPF passes or not? For instance, RFC7001 expects one >result. http://tools.ietf.org/html/rfc7001#section-2.6.2 > >RFC7208 was written to make the text of the document more suitable for >a "Standard" track. The charter was to not modify the protocol. So >RFC7208 is not addressing this issue either.
Sigh. RFC 7208 doesn't say the HELO result determines anything. It says IF (I say again IF) a decision has been reached about message disposition based on the HELO result, there is no requirement to go ahead and do a pointless Mail From check. Avoiding a check that has been determined to be pointless is the only change in this area in RFC 7208. This is much ado about nothing and really, really irrelevant to DMARC. Scott K P.S. No erratum needed _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
