This is basically a new derivate of the already fixed non-locale-related bug reported at
http://debian.2.n7.nabble.com/Bug-328655-mutt-Verification-failure-PKCS7-verify-wrong-content-type-pk7-smime-c-173-td51012.html#a3108819

The problem of mutt's failure to detect S/MIME encrypted messages
persists when receiving mail with localized Content-Description header
for S/MIME, i.e.

 Content-Description: S/MIME Encrypted Message

will work and display the encryption flag "P" correctly in the mail index, while
the localized german description header

 Content-Description: S/MIME Verschlüsselte Nachricht

will NOT work, i.e. neither flag the message as encrypted, not decrypt
the message using the set smime_decrypt_command. Changing the header to
english manually is a valid, yet uncomfortable workaround.

It is apparently not a good idea to use the Content-Description alone as
indicator of S/MIME encryption since this is subject to localization on
the senders side.

Maybe it would be better to distinguish by presence of the headers
 Content-Type: application/pkcs7-mime
vs.
 Content-Type: multipart/signed;
    protocol="application/pkcs7-signature"
whether or not we have an encrypted/signed message.

Regards
-Klaus Knopper

The attached patch "works for me", though it is not 100% logically
correct.

It assumes that email containing the pkcs7-mime header and NOT having
subtype smime-type, is encrypted, regardless of its Content-Description.

Regards
-Klaus

Control: tag -1 confirmed

(That was #328655, for reference.)

I have the same problem, ack.

Mutt does try to do something with the mail, so it actually knows it
is s/mime encoded. No idea what extra use looking at
Content-Description serves at all...

Sounds plausible.

Christoph