----- Original Message ----- > From: "Anne Bennett" <a...@encs.concordia.ca> > To: dmarc@ietf.org > Sent: Friday, January 23, 2015 3:27:46 PM > Subject: [dmarc-ietf] the painful issue of SPF HELO > >
> > Murray proposed this text for 4.1, based on my suggestion: > > [SPF], which authenticates the domain found in an [SMTP] > MAIL command, or the domain found in the HELO/EHLO command if > the MAIL command has a null path. Note that in contradiction > to [SPF], in the context of DMARC, this latter identity is > typically only used in the case of a MAIL null path. > > Franck objects to the word "contradiction", and suggests: > > [SPF], which authenticates the HELO identity and the MAIL > FROM identity: the domain found in an [SMTP] MAIL command, > or the domain found in the HELO/EHLO command if the MAIL > command has a null path. Note that in the context of DMARC, > this later identity is only used. > > Hmm. How about this: > > [SPF], which authenticates: > - the domain found in an [SMTP] HELO or EHLO command > (the "HELO result"), and/or > - the domain found in an [SMTP] MAIL command, or the domain > found in the HELO/EHLO command if the MAIL command has a > null path (the "MAIL FROM" result). > It is not specified whether DMARC uses the "HELO result" > or the "MAIL FROM result"; implementations differ. > Your text is clearer but replace the last sentence by: DMARC uses the MAIL FROM result. If you look Terri's, my implementation, which is used at least by another large ISP, and Tim's conformance tests, that were used for much code out there. Then I can say DMARC uses the MAIL from result today. I cannot speak for everyone, but this is what I feel is true out there. I have not seen any evidence that DMARC uses the HELO result, so your implementation differ is conjecture. > It certainly exposes the ugly truth. ;-) > > But speaking of ugly truths, the document already allows for > differences; in section 6.7 we have: > > -12> DMARC-compliant Mail Receivers typically disregard any mail handling > -12> directive discovered as part of an authentication mechanism (e.g., > -12> ADSP, SPF) where a DMARC record is also discovered that specifies a > -12> policy other than "none". Deviating from this practice introduces > -12> inconsistency among DMARC operators in terms of handling of the > -12> message. However, such deviation is not proscribed. > This was mainly added in the case of people that follow -all to the letter and reject emails on sight. > > ** A tiny rant ** > > Necessary as this flexibility is if this document is to be > finished any time soon, it causes problems for a person trying > to create SPF and DMARC records in a way that will not cause > more problems than it solves! While it's tempting to stay away > from this stuff until it all settles down, that's becoming more > difficult, and not only because my parent domain at work might > be poised to publish a DMARC record which could interfere with > my domain's outgoing mail. Even at home, a few months ago, > Gmail started tagging my outgoing mail as spam, and when I > tried to troubleshoot this, their "why is this spam" web page > essentially insisted that I publish an SPF record before going > any further! > (end of rant) > > It's only fair to admit that despite my frustration, I'm > grateful for all the work being done on these issues, both to > combat spam, and to document what on earth is going on. > I think once you get aggregate reports, all these questions won't matter much... Seriously, if you DKIM sign your email with an aligned domain, then it will give you a DMARC pass, SPF will be here for the <0.5% of cases where DKIM fails for not apparent reason (provided you can DKIM sign your bounces, which many people can but forget to do). _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
