User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:220.127.116.11) Gecko/20100401 SUSE/3.6.3-1.2 Firefox/3.6.3 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de; rv:18.104.22.168) Gecko/20100228 SUSE/3.0.3-1.1.1 Thunderbird/3.0.3 Encrypted mails could be displayed and verified (if signed) correctly. But further processing this mails is very limited. The following mail operations do not work as expected: 1. The "Forward" action creates a mail, which contains the original message as an encrypted "smime.p7m" block. It is unclear, if the receivers will be capable of decoding the attachment. Also it's not possible to delete parts of the "smime.p7m" attachment. It would be better, if TB handles encrypted mail forwards as unencrypted mail forwards, possibly with the default option to re-encrypt the new message. 2. The "edit message as new" operation creates a mail with an encrypted "smime.p7m" attachment. But TB should create a unencrypted message copy which could be edited, possibly with the default option to re-encrypt the new message. 3. It is not possible to display the unencrypted mail source code. Instead the encrypted mail source code "smime.p7m" is displayed. 4. It is not possible to permanently decode the mail an save the decoded mail. But this operation could be necessary, if for instance old mails should be archived unencrypted in a company network. I report these 4 missing operations in one bug report because I think all 4 operations depend on missing S/MIME decoding features. I tested with Thunderbild 3.0 and Seamonkey 2.0. Reproducible: Always
Component: General → Security
QA Contact: general → thunderbird
all that happens any OS (windows|linux) any version of thunderbird
this happens in Thunderbird 5b2 I've noticed any encrypted and signed email from MS Outlook does this. Say the email had an attachment test.txt. When you forward it, the attachment is smime.p7m. If you forward that email to a Thunderbird user, they see the attachment test.txt as intended but Outlook users see smime.p7m. The email has to be encrypted and signed for it to do this. Just signed or just encrypted does not cause the problem. The header info for the content type is below. It's the same whether the email is JUST encrypted, or encrypted and signed. Content-Type: application/x-pkcs7-mime; smime-type=enveloped-data name="smime.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m"
I verified that this bug does not exist (anymore) in Seamonkey. "Edit message as new" and forwarding S/MIME signed and encrypted messages works. I tested with Seamonkey 2.40.
You need to log in before you can comment on or make changes to this bug.