Feature request: ignore expired signatures

[sersorrel]

Some DKIM signatures have relatively short expiry periods (e.g. expiry timestamp 24 hours or less beyond the signature timestamp). If I don't open Thunderbird for a day, this results in a lot of false-positive DKIM warnings.

Would you consider adding a feature to improve this situation? e.g. an option to:

• ignore expired signatures entirely (like the existing advanced settings for weak keys/sha1/...)
• check signatures based on the time the mail was received at the server, if known (e.g. Received headers, Delivery-date header, ...)

[lieser]

check signatures based on the time the mail was received at the server, if known (e.g. Received headers, Delivery-date header, ...)

This should already happen since version 5.2.0, see #336. Do you have an email where this does not work which you could send to me via e-mail so I can look into it ([email protected])?

ignore expired signatures entirely (like the existing advanced settings for weak keys/sha1/...)

Could you clarify which of the two cases you mean:

• You currently get a warning for the expired signature, and want to ignore the warning only.
• The verification of the signature fails (e.g. because the key is no longer available). And you want don't want to see the failed result in case the signature is marked as being expired anyway,

I'm not completely against possibly adding an option for expired signatures if they cause a lot of problems. But I want to fist better understand your use case, and make sure your need does not just come from a failing received time detection which could be fixed/improved instead.

[sersorrel]

I've sent you an example mail. (I'm not sure whether Thunderbird was open or not at the point it arrived, sorry)

If this is actually caused by a failure to pick up the proper timestamp to verify against, and fixing that would stop the warnings showing up, that would also be fine! I'm kind of indecisive, but thinking about the two possible cases:

1. signature is expired, but the key is still available (I guess this is what I'm seeing?)
2. signature is expired, key no longer available

to me it makes sense to treat the first case similarly to an ill-formed selector tag (which is configurable already): maybe the provider messed up their timestamps, but the email is still signed with a good signature, and in most cases there is not a lot I can do about this (I don't run e.g. the GitLab mail server) – so I mostly don't care that much about it.

[lieser]

Thanks for proving me with an example. I can confirm that there is a problem with the parsing of the time that I will fix.

And yes what you are seeing is the first case.
I'm also not completely against adding a new option to ignore the expired warning, but I would rather want to wait for someone to have an actual use for it.
E.g. in your case where is hopefully no longer a need for it after the parsing bug is fixed.