Hi, your description is exact but I do not agree that there is not a huge problem. Gmail accepts majority of such mails. Only if I display the original message, I can see DKIM FAIL and DMARC FAIL. However, I had problems with forwarded messages and important invoices were not delivered and I was penalized for not paying on time because the mail with the invoice was rejected by gmail. I have a mailserver for math-gnostics.eu at seznam.cz which has a very strict policy. If the result for an incoming mail is DKIM FAIL + DMARC FAIL, the mail is rejected and I am not informed that a mail was rejected
Zdeněk Wagner http://ttsm.icpf.cas.cz/team/wagner.shtml http://icebearsoft.euweb.cz út 5. 3. 2019 v 2:36 odesílatel <msk...@ansuz.sooke.bc.ca> napsal: > > 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/
