Feature request: option to treat DKIM signature that doesn't match "FROM" domain as failure, no matter which server did the DKIM verification

[ell1e]

I have a mailing list which signs some e-mails coming e.g. from @peoplecall.com and then presents a DKIM signature from googlegroups.com. This seems useless for verifying that the e-mail wasn't tampered with. While it would make sense for me to perhaps whitelist mailing lists to allow them to sign e-mails for me like that, I don't think it should be allowed by default. I would expect this mismatch to show a warning at minimum, if not a downright signature failure.

It would therefore be nice if 1. there was an option to require any DKIM signature, no matter if locally tested or if obtained from the Authentication-Results header, to be using keys matching the domain of the FROM address, and 2. perhaps that option should even be enable by default. Similarly as I pointed out in #465 many of the addon's defaults seem prone to trusting arbitrary 3rd party in the chain and apparently also arbitrary 3rd party signing domain, which seems dangerous as a default since users without deep DKIM knowledge will probably not understand the risks. My apologies if I'm just missing something here, however.

[lieser]

I don't think it should be allowed by default. I would expect this mismatch to show a warning at minimum, if not a downright signature failure.

If the add-on does the verification a mismatch between the from and SDID should already result in a warning by default.

For ARH you are right this is missing and should get fixed, this is tracked in #452. Probably will not make it into the next release but fixing that is one of the open things having a higher priority.

Regarding your other issues, sadly didn't have yet time to read your latest comment in detail and think about them.

In principal I agree with you that simply trusting some random 3rd party kind of defeats the validation of signatures. But I also think from a usability perspective one has to be careful to not end up with to many mails showing just big red warnings, even if they are legit mails just with a bad DKIM configuration.
This would just lead to users ignoring the bad results.

This was one of the reason of adding the favicons, trying to go more the way of highlighting good DKIM results instead of producing to many errors where the add-on itself can not decide how bad they are, risking the user to start simply ignoring all errors because they are to common.

But where are definitely some improvements like #452 that should be made, so please continue to point out defaults that you think are bad/unsafe.

---

Like i wrote I think this is a duplicate of #452 so will close this, but feel free to reopen it if you disagree.

[ell1e]

mails showing just big red warnings, even if they are legit mails just with a bad DKIM configuration.

For what it's worth, this would only happen if the user didn't specify an authorized ARH server in the first place, and if then there is a faulty enough server in the chain that it inserted a failure. I haven't seen that in the wild yet, so I don't think it's common. (And in cases where it happens, I don't see how it's naturally a given that pointing it out with a warning is necessarily a bad idea if there's a true misconfiguration.)

[ell1e]

Also please note I'm not suggesting you enable this behavior by default anyway. But an option would be greatly helpful.

Right now, it seems like I simply can't run DKIM verifier in a safe mode, because 1. autocrypt on the server side breaks DKIM checks on my machine, 2. I can't set a trusted single Authentication-Results host since the provider uses multiple, 3. some e-mail chains forwarded to me will not trim external Authentication-Results headers that can insert fraudulent positive results either. So without this option, I'm not sure how I would possibly get tampering-proof results.

[lieser]

2. I can't set a trusted single Authentication-Results host since the provider uses multiple,

Note that the trusted authentication servers that can already be set is a space separated list of server-ids, i.e. it should be possible to set multiple hosts. See also https://github.com/lieser/dkim_verifier/wiki/Account-Options#trusted-authentication-servers.

Should that not solve your problem or am I missing something?

[ell1e]

Happy new year 🎉 🎉 Sorry for writing a lot of text, I think your addon is amazing and the essential Thunderbird fix, so that's why I'm so invested.

Like i wrote I think this is a duplicate of #452

This seems like a duplicate, my bad!

trusted [...] servers that can already be [a list, ...] Should that not solve your problem or am I missing something?

If you're talking about the other issue I filed, it doesn't trivially, because I simply don't know what hosts my provider uses. I could guess, perhaps that would work, but it seems a bit tedious compared to what I think would be ideal for my use case:

As explained before, I think an option that would simply fail on any failed Authentication-Results header would solve it. Even if you don't enable it by default, it would be useful to have. I think it could even be enabled by default if no trusted server is set: 1. I don't see how this will cause excessive warnings, since I've never seen any mails that would possibly trip this up other than mailing lists were they were tampered with, 2. and I've seen plenty of e-mails pass by default that shouldn't, again mail altering mailing lists. I would also like to suggest that 99% of beginner users who would be confused by warnings will probably not be using mailing lists anyway.

[lieser]

If you're talking about the other issue I filed, it doesn't trivially, because I simply don't know what hosts my provider uses. I could guess, perhaps that would work, but it seems a bit tedious

No this was about something you wrote here that sounded like you are unable to configure ARH reading securely. Which I think should be possible.
Yes it is some work to manual configure it for every account, but would be surprised if you would really need to set more than a handful of host in the list, especially because it is possible to allow a complete domain.

---

All discussion about trying to improve the default behavior about which ARH results should be trusted when simply enabling ARH reading globally I would like to keep in #465. I will try to find time to look into that sometimes after the way overdue 5.5.0 version is released.

[ell1e]

I think we are talking about the same issue then! But fair enough, #465 seems like the right spot.

Thank you for your work on dkim_verifier, I've been using it daily since I found it.