Authentication-Results seems to be parsed wrongly, seemingly leads to "Valid" listing despite multiple "fail" headers in the actual e-mail source

[ell1e]

Setup for the bug: Because I use automatic PGP on unencrypted incoming mail provided by the paid e-mail provider I use, I have to disable DKIM checking through the addon itself because the automatic encryption breaks the signature. I therefore have to rely on DKIM Verifier displaying the results of the "Authentication-Results" headers for me. My usual developer e-mail is forwarded through a custom SMTP that I run that adds DKIM check results, and then ends up at an SMTP by a standard paid e-mail provider that also adds DKIM check results before applying Auto-PGP. You can see both of these Authentication-Results headers in the chain below, the lower one being from my forwarder SMTP.

Expected result: As soon as DKIM Verifier finds any Authentication-Results headers somewhere in the entire chain that say "dkim=fail" or "dkim=none", even if that may also trigger on a spoofed fail result attached by the sender to the return path, that should lead to a fail being displayed.

Actual result: As soon as the top-most Authentication-Results header is present and mentions DKIM, DKIM Verifier seems to display "Valid", even if that very top-most header says "fail". This is with local DKIM check disabled, due to above reasoning.

[lieser]

The expected result you describe it pretty much the opposite form the current intentional behavior, which picks the most "valid" one to show.
I'm also unaware that the RFC describes such a behavior as you want.

If you want to have more control over which Authentication-Results header (ARH) is used take a look at https://github.com/lieser/dkim_verifier/wiki/Account-Options#trusted-authentication-servers.

Of course if all ARHs contain a fail result, the add-on should not make a valid result out of it.
Could you send me one affected e-mail as a saved eml file to [email protected] (or at lest the complete headers)? Would make it a lot easier to figure out what is going wrong. If you don't have an email you would be willing to share with me we could also try to see if the debug logs are enough.

[ell1e]

What I proposed is the most defensive default behavior I could possibly think of, in case no specific server is marked as trusted. I think that would make the most sense if no server is marked as trusted to fail on whatever fail/none is found anywhere in the chain, since then an attacker could at best only mark themselves as failed (which seems like a bonus if they do, if anything).

[ell1e]

I did some more testing, and for my work e-mail a few hours ago I made the change of making my SMTP strip any external "Authentication-Results" headers which works splendidly as a fix for this. It prevents the addon from picking up any untrusted external headers. However, for my private e-mail I don't have that sort of access to the SMTP server, so it would be nice if in such a situation the default behavior was safer.

[lieser]

Thanks for providing me the e-mail. Like you noticed yourself already it contained a third ARH that did not show up in your screenshot, where the add-on did pick up the valid result from.

I totally agree that the current default behavior could be considered insecure. If one is concerned about such attacks the already mentioned trusted authentication servers needs to be configured for each account!
As the RFC requires the servers to strip any ARH result with it's own server-id, this should ensure you see only ARH from your server.

I choose this default because I fear for many it is to complicate if they need to configure this id.
My admittedly a little weak justification for this suboptimal default behavior (from a security perspective) is that that I'm not aware of ARH spoofing being widely used as an attack.

I will think more about your proposal, like you may have noticed I'm currently not yet that convinced of it. In some cases (especially for SPF, but also DKIM with e.g. mailing lists) and under the assumption the ARH header is not spoofed, I could imagine cases there one would like to see the more valid result of an earlier ARH (this of course would be best combined with ARC #87).
And your proposal would not prevent attacks in all cases, at least as long ARH reading can be enabled globally. Currently you could have two accounts, account A adding ARH, but the other account B not. If now one does not take the effort to enable ARH reading just for A, ARH spoofing would still be possible with your proposal for B.

One better default behavior I have been thinking about is trying to guess some reasonable default for the allowed server id from the configured server domain or e-mail address of the account.
But I imagine this maybe to often resulting in a server id that does not match the correct one.

[ell1e]

And your proposal would not prevent attacks in all cases, [...]

While that is true, it might be pretty safe when ignoring any Authentication-Results that contains any DKIM info other than dkim=none if there isn't actually a DKIM signature. Then you'd cover the common case where at minimum one trusted intermediate SMTP checks DKIM but only inserts headers when there was DKIM present.

it is to complicate if they need to configure this id.

It may not need to be, since I think the only "attack" might be an intermediate intentionally(!) trying to make DKIM incorrectly fail, which seems unproblematic. And just guessing a server id seems less safe than failing on any dkim=fail or dkim=none found. My apologies if I'm missing something, however.

[ell1e]

For what it's worth, I just confirmed from digging in my mails that one of my accounts uses multiple subdomains to add in the Authentication-Results header. Therefore, unless it is configured to strip out all other subdomains which I assume it may not be, it's not possible to set a guaranteed safe set of server ids. However, failing on any dkim=fail or dkim=none should be safe for my config if I'm not mistaken, since all my accounts have a trusted SMTP at the top of the chain that will add the failure whenever applicable.