On Tue, 5 Mar 2019, Zdenek Wagner wrote: > DMARC can be set as one of the following ways: > * The mail is valid if at least one of SPF and DKIM passes > * If the mail is signed, it is valid if both SPF and DKIM pass > > Let's assume that we have the latter case and we try to "solve" it by > changing the From header to someth...@tug.org. Now the mail is sent > from @tug.org but is signed by a key from @example.com, hence DKIM > fails.
As described in RFC 7489 section 6.6.3, the RFC5322.From domain is queried for the DMARC policy to apply. If that returns nothing, there is a fallback to the "Organizational Domain" of the RFC5322.From but it still has to come from the RFC5322.From domain. That means that if there's a policy on "tug.org" but not on "foo.bar.tug.org," then a message From: an @foo.bar.tug.org address is required by DMARC to be handled under the policy of tug.org. But that's the only way in which a policy other than that of the exact domain in the From: header can ever be applied by a compliant implementation. [From RFC 7489:] 1. Mail Receivers MUST query the DNS for a DMARC TXT record at the DNS domain matching the one found in the RFC5322.From domain in the message. A possibly empty set of records is returned. 2. Records that do not start with a "v=" tag that identifies the current version of DMARC are discarded. 3. If the set is now empty, the Mail Receiver MUST query the DNS for a DMARC TXT record at the DNS domain matching the Organizational Domain in place of the RFC5322.From domain in the message (if different). This record can contain policy to be asserted for subdomains of the Organizational Domain. A possibly empty set of records is returned. 4. Records that do not start with a "v=" tag that identifies the current version of DMARC are discarded. 5. If the remaining set contains multiple records or no records, policy discovery terminates and DMARC processing is not applied to this message. [end] If a user from example.com, which domain signs with DKIM and sets a restrictive policy, sends mail to the list and the list rewrites the From: header to an @tug.org address, then the RFC5322.From domain will be "tug.org" and only the DMARC policy published by tug.org will be used to determine handling by an RFC 7489 compliant recipient. DKIM does not pass if tug.org didn't sign, passes if tug.org did sign, but either way it is tug.org's policy (or lack thereof) that determines handling. The policy of example.com is out of the picture entirely, and DKIM signatures from example.com still attached to the message cannot be used to determine handling by a compliant recipient. Of course there can be non-compliant recipients out there, and there could be other behaviour with recipients that implement SPF or DKIM without DMARC, and for the benefit of such recipients it might be a good idea to strip off incoming DKIM signatures. But I don't think that's terribly important. Random extra DKIM signatures from unaligned domains are not rare in the wild and they don't seem to be causing huge problems; at the very least, just rewriting From: without stripping incoming signatures would be a big improvement over the current situation of the XeTeX list. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before tribes. https://ansuz.sooke.bc.ca/