S/MIME signature and encryption status not correctly shown for messages imported from Outlook 2003



12 years ago
8 years ago


(Reporter: Jeremy Hall, Unassigned)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [closeme 2010-02-15])


(1 obsolete attachment)



12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: version 1.5 (20051025)

After importing messages from an existing installation of Outlook 2003, signature and encryption status does not display.  Before adding my certificates to the store, the encrypted messages simply appeared with a blank body.  After installing my certificates, the messages were properly decoded, however they still do not show the signed and encrypted icons.

With the message open, clicking on View, Message Security Info displayes "Message Has No Digital Signature" and "Message Not Encrypted" messages along with the descriptions of the status.

The first time the certificates are accessed after the Thunderbird session has been started, the store asks for the store password in order to decrypt and display the affected messages.

Reproducible: Always

Steps to Reproduce:
1.  Install Thunderbird and allow it to import settings from Outlook.  Some messages in Outlook must be S/MIME encrypted and signed.
2. Open one of the known-encrypted messages.  Note there is no indication that the message is signed/encrypted and simply appears as a blank body.
3. With the message open, click on View, Message Security Info. displayes "Message Has No Digital Signature" and "Message Not Encrypted" messages along with the descriptions of the status.
Actual Results:  
After performing setps above, Thunderbird displayes "Message Has No Digital Signature" and "Message Not Encrypted" messages along with the descriptions of the status.  Note the proper contents of the message are decrypted and displayed.

Expected Results:  
The message should show the correct "signed" and "encrypted" status.  The information is obviously there or it would not be able to decrypt the message.

I consider this a major bug as the end user could accidently delete encrypted messages believing they are blank until they install the appropriate certificates that are required to decrypt them.  Please feel free to adjust severity if you feel I have overrated it.

Comment 1

12 years ago
Related to bug 296587?

Comment 2

12 years ago
I think it is similar, however I am able to open the affected messages once I have my certificates installed into Thunderbird, but the encrypted and signed status still does not show up.  The other bug did not state whether or not they could open the messages after installing the proper certificates.

Also, I am purely using the built in S/MIME encryption, not PGP/GPG and the Enigmail plugin.

I do feel that the two bugs are close enough to be able to mark this one as confirmed though.  They have the same core issue, but this one is closer to the root since additional plugins/extensions are not involved.

Comment 3

12 years ago
Bumping to keep this bug from timing out before someone else takes time to confirm it.

Comment 4

11 years ago
I have just entered some more comments to bug 296587 which I believe are related to this one, and attached there an example email which appears blank.  This bug continues to appear in TB on FC5.


8 years ago
Depends on: 296587


8 years ago
Duplicate of this bug: 296587
Created attachment 411055 [details]

attached testcase email from dupe bug #296587
As show from testcase this is an open bug.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20091108 Lightning/1.0pre Shredder/3.0pre ID:20091108032229
Ever confirmed: true
Keywords: testcase

Comment 8

8 years ago
Comment on attachment 411055 [details]

The attachment contains a message that doesn't conform to the S/MIME standard; it is not relevant for this bug.
Attachment #411055 - Attachment is obsolete: true

Comment 9

8 years ago
I agree that it's reasonable for TB to not parse invalid S/MIME messages.

The question in my mind is who broke it? The most likely candidates:

1. The original sender used a mail client that crafted a non-compliant S/MIME message. Outlook tolerated the bustage.
2. The Outlook server received a valid S/MIME message, but mangled it after receipt.
3. The Outlook server received a valid S/MIME message, and faithfully sent it to the Outlook client, which promptly broke it. 
4. The original message was fine, and the Outlook server/client didn't touch it, but TB botched things during the migration process.

Number 4 is something we can something about here, but we need to really isolate the problem. Although it would be a little work, if you can demonstrate that a legal message got all the way to the Outlook client and then failed to migrate correctly, we'd have a shot at getting this fixed.  

I might propose that you use TB3 to send the original message, and cc an address that also uses TB3. That way you can be sure the email is valid at the start.  You might also receive the email in Outlook, and then save it to a file, and see if you can then use TB3 to read it. (File/Open Saved Message...) If you can do that, and the message is fine, then it's the migration process.  If it fails, then the message is getting mangled somewhere else, and there's not much TB can do to help.

Comment 10

8 years ago
Marking Unconfirmed until we get a test case that demonstrates (or at least provides strong circumstantial evidence) that there is an import bug here.

Also, changing component to Migration.
Assignee: dveditz → nobody
Component: Security → Migration
Ever confirmed: false
QA Contact: thunderbird → migration

Comment 11

8 years ago
Thanks Bob.  Marking testcase-wanted
Keywords: testcase → testcase-wanted
Whiteboard: [closeme 2010-02-15]
RESOLVED INCOMPLETE due to lack of response to last question. If you feel this change was made in error, please respond with your reasons why.
Last Resolved: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.