On 09/01/2013 08:29 PM, Steven M Jones wrote: > On 08/31/2013 Raman Gupta wrote: >> No, the hostname of the mail server is not a subdomain of the From >> domain. But the mail server is a valid SPF sender for that domain. > > This makes it sound as if you have a host in domain bar.com, > sending/receiving mail for the domain foo.com. The host is duly > authorized in the SPF record for foo.com.
Correct. > However if the host in bar.com generates a message with a null > reverse-path and an RFC5322.From in foo.com, the receiving system will > build an SPF identifier of [email protected] and check that against > the SPF record for foo.com. That will pass. Correct, that is indeed passing. > As was mentioned, DMARC requires an extra "alignment" between these > identifiers. It gets an SPF pass using the identifier bar.com, but an > RFC5322.From of foo.com - those simply will not match, and in the > absence of a DKIM pass (with identifier alignment), you'll get a DMARC > fail. These messages are DKIM signed, and therefore did pass DMARC. It was simply my perfectionist nature wanting the DMARC SPF to pass as well. > On 09/01/2013 Raman Gupta wrote: >> But this would imply that my mail server should be configured to send >> "HELO mydomain.com" instead of "HELO mail.mydomain.com" where "mail" >> is the hostname of the mail server. > > Won't help if the situation is what I described above with this server > generating messages for the other domain(s). But it's possible I've > gotten that all wrong - please confirm. You've gotten it right. I now understand the alignment issue is with the sender domain vs the RFC5322.From domain. I should have seen that before. >> It seems to me the DMARC spec should take into account that, for empty >> Return-Path's, the HELO/EHLO may be (and probably will be) a fully >> qualified hostname, not a domain, and adjust the rules for SPF >> identity alignment matching accordingly. > > DMARC allows for FQDN vs. DN - unless you override the default and add > "aspf=s" to your DMARC policy. I'm in relaxed mode. But based on the information above, I now realize the subdomain was not the issue with alignment, and my statement was in error. > I think you may be referring to a cross-domain authorization issue to > handle messages generated with a null reverse-path on a host not in > the same domain as the RFC5322.From. Correct. > DMARC is layered atop SPF, so it doesn't go poking around in SPF > records. Because of the problems DMARC is trying to solve, it > imposes additional alignment checks that SPF doesn't, after SPF has > rendered its verdict. That makes sense, usually. > IMO, DMARC is not designed for cases where Sieve scripts are > generating messages with a null reverse-path on a host in a different > domain. That's a design issue vs. an operational issue, and should be > hashed out on the IETF dmarc list > (https://www.ietf.org/mailman/listinfo/dmarc > <https://www.ietf.org/mailman/listinfo/dmarc>). Feel free to put > forward a use case there. Yes, I think this is a corner case in which DMARC should not impose the additional SPF alignment check. But given that DKIM still results in a DMARC pass, this could just be my perfectionist nature asserting itself. Regardless, I probably will post this use case to the IETF dmarc list. > If I've misunderstood or mis-characterized the situation you're > dealing with, my apologies. In that case it might be good to describe > the scenario step-by-step as a message is received and a response > generated by Sieve, etc. I think you've understood it, and clarified where I was wrong in my thinking, as well as validated my original belief that the DMARC design does not handle this situation "perfectly". Thanks. Regards, Raman _______________________________________________ dmarc-discuss mailing list [email protected] http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
