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.
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 postmas...@bar.com and check that against the SPF record for foo.com. That will pass.
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.
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.
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 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. 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.
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.
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.
--S.
_______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org 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)
