-
Notifications
You must be signed in to change notification settings - Fork 37
Most mailing list are breaking DKIM signatures by editing the subject or adding a footer. You can hide the DKIM header for this e-mails by adding a sign rule (more about it here).
Besides a bug, it may also be your mail provider, altering the incoming e-mails, for example by changing the encoding of the e-mail. Known mail provider/server to do so:
- Verizon (USA)
- Outlook.com / Hotmail / Office365 / Microsoft SMTP Server
- Sendmail (for
text/plain
if specified by the F=9 delivery agent flag, see5.4. M -- Define Mailer
in the Sendmail Installation and Operation Guide)
In case the receiving server is altering incoming e-mails, enabling the reading of the Authentication-Results header instead of a client side verification may be an option for you.
If you are not certain that the problem is caused by the mail provider, please report the issue and send some of the invalid e-mails as saved .eml files to [email protected], so I can try to find out that the problem is. If you don't have such an e-mail without personal information that you don't want me to see, I could also first send you a signed e-mail.
Partially. The add-on does verify all DKIM signatures, but because of space considerations, only shows the result of one of the signatures.
The signature to be shown is determined by the following criteria:
-
The overall result of the verification (valid / temporary error / permanent error)
-
Whether there exist warnings for a valid signature
-
Whether the From address is in the SDID or the List-ID is in the SDID
The add-on probably fails to connect to the first DNS server. Disable the loading of DNS servers from the OS configuration (this are tried first) and only include in the "DNS name server" field working DNS servers. More info about the DNS options can be found here.
Make sure you are using the libunbound resolver. The default JavaScript DNS library does not support DNSSEC. More info about the DNS options can be found here.
There are two possible causes for this.
1. A sign rule says the e-mail should be signed.
Search in the "Signers rules" and "Default signers rules" for the responsible rule. If the rule is in "Signers rules" either modify or remove it. If the rule is in "Default signers rules" please report it. Until this is fixed in the default rules you can either create a custom rule overwriting the responsible default one (example here) or disable the usage of the default rules completely.
As this is only a heuristic it can produce false result. If you encounter such a false result create a custom sign rule for the problematic domain explicitly saying e-mails from the domain do not have to be necessarily signed (example here).
In some cases there is a problem with the local DNS forwarder "dnsmasq" returning no result even if the key exists. Disable the loading of DNS servers from the OS configuration to use a different DNS server. More info about the DNS options can be found here.