S/MIME verification incorrectly reports "invalid" when Date: header and signingTime differ by more than one hour

[VauHa]

Thunderbird currently rejects otherwise valid S/MIME signatures (error 1041 – “Unknown problems with the signature”) if the message’s RFC 5322 Date: header differs from the CMS signingTime attribute by more than 3600 seconds.

This behavior is not defined in any S/MIME or CMS standard, and it causes false negatives in legitimate automated workflows.

Steps to reproduce

1. Save a correctly verified message.
2. Modify the outer Date: header to differ by more than 1 hour.
3. Open the message in Thunderbird.

The status message includes "... There are unknown problems with this digital signature ... (1041)". This is at least misleading. The digital signature is correct, the email was sent only later.

Expected result

Do not treat a time difference as a cryptographic failure. Verification should succeed, or, at least, the message should not be marked “invalid.”

It could be converted to a warning, that should clearly state “Message Date and signingTime differ by more than 1 hour.”

Ideally, this behavior should be optional or downgraded to a warning, controlled by a preference such as
mail.smime.warn_signingtime_skew.

Further arguments

The S/MIME RFC and CMS RFC specifications define signingTime as informational. It is even labeled as optional in the thunderbird code (mailnews/mime/src/mimecms.cpp:414. No normative requirement links it to the RFC 5322 Date: header.

Many automated or large-batch signing systems prepare messages in advance, where the Date: header is added later by an MTA or scheduling process. The one-hour hard-coded skew check breaks these use cases even though the signature and messageDigest are perfectly valid (those which are required).