No, rewriting From without other changes does not help. First, looking into DNS, the SPF for tug.org is set as:
$ dig TXT tug.org +short "v=spf1 a a:freefriends.org mx:freefriends.org a:fencepost.gnu.org include:_spf.google.com ~all" The sender for the TL list is here in the permitted servers. SPF will thus always pass. Now assume that someb...@nodkim.org sned a mail to the list. @nodkim.org has neither DKIM nor DMARC. The mail is distributed to the subscribers. SPF passes, @nodkim.org does not provide DKIM and there are no headers. There is thus nothing to verify and the recipient just reports that SPF passes, there is nothing else what can be done. Rewritingt From does no harm but it is of no use. Now assume that u...@example.com does the same but @example.com defines DKIM and DMARC. The message is signed, the list of signed headers is defined by @example.com. This mail is then distributed to subscribers and some headers are added and/or modified. The subscribers first verify SPF which passes. Further it finds the DKIM headers. They contain the identifier of the key. The ley id and the domain name define the URI of the TXT record containing the public key and the list of the headers that are signed by the original sender. It is possible to signed an empty (missing) header which means that the mailing list is not allowed to add such a header because it invalidates the signature. * If the mailing list adds/modifies headers that were not signed by the original sender, the signature remains valid and DKIM passes. * If the signed contents is modified, the signature is no longer valid and DKIM fails 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. 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 If the From header is rewritten to someth...@tug.org and DMARC at tug.org is set to the former option, the result will be SPF PASS, DKIM FAIL, DMARC PASS and the recipients will thus silently accept mails with invalid signatures. This overcomes the problem with DKIM but IMHO allowing to accept messages with invalid signatures is not the right way. The mailing list must remove existing DKIM signature, change the >From header and then either provide its own DKIM + DMARC and sign the mail or do not provide them at all and rely on SPF only. And the last thing, setting of DMARC at tug.org is wrong, the DNS query returns the SPF record, not the DMARC record. If you want to see a working server, you can examine math-gnostics.eu: dig TXT math-gnostics.eu +short – this returns the SPF record dig TXT default._domainkey.math-gnostics.eu +short – this returns the public key (I have only one key) dig TXT _dmarc.math-gnostics.eu +short – this returns the DMARC record which is very permissive on my server dig TXT seznam.cz +short – this returns the included SPF record It took me a few days to configure DKIM properly... Zdeněk Wagner http://ttsm.icpf.cas.cz/team/wagner.shtml http://icebearsoft.euweb.cz po 4. 3. 2019 v 22:53 odesílatel Julian Bradfield <j...@inf.ed.ac.uk> napsal: > > In mail.xetex, you wrote: > > Hi all, > > > > mere rewriting of the From header will not work. There are four beasts > > involved: > > Yes it will. It's what I successfully use for my user(s) who want > their mail forwarded to gmail, and if it works for that, it works for > anything! > > > The recipient sees that MAIL FROM says that the mail came from > > tug.org. It thus looks at DNS, finds the SPF record (in fact a special > > type of TXT) and verifies whether the IP address is in the list of > > allowed servers. This is configured correctly at tug.org hence SPF > > passes. > > However, this is not an SPF pass for DMARC purposes, because DMARC > only considers an SPF pass when the From: address "aligns with" the > envelope sender (which usually means being the same domain). > > > DMARC is a more flexible way superseding ADSP. It looks both at SPF > > and DKIM and then decides what to do. Remember that DKIM as well as > > DMARC are defined by the mail systems of the original senders hence > > tug.org cannot do anything. In addition, it is not known which eaders > > are included in the signature. > > But DMARC only looks at the policy of the From: address, so if you > rewrite the From: address to a tug.org address, tug.org's DMARC policy > will be applied. It doesn't matter that the message now fails the > original DKIM signature (though for cleanliness it's better to remove > the broken signature). > > So re-writing the From: address should solve the problem. > > In addition, DKIM-signing the (modified) message with a tug.org key > will increase the chance of the message not being diverted to spam > folders.
