encrypted message in "Sent" folder is NOT a true copy of what was sent

RESOLVED INVALID

Status

MailNews Core
Security: S/MIME
RESOLVED INVALID
11 years ago
9 years ago

People

(Reporter: Nelson Bolyard (seldom reads bugmail), Assigned: kaie)

Tracking

Trunk
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

Using a recent trunk build of SeaMonkey, 
I sent an encrypted message to myself.  Consequently, I have two copies
of the message: one copy in my sent folder, and another copy in my inbox.

The two messages SHOULD be identical, except for the additional headers
added as the message went through various MTAs.  They should especially 
be identical in the encrypted part of the two messages.  But they're not.

The encrypted parts are not even of the same length (!) much less identical
contents.  I will attach the two non-identical copies of the message.

I tried this experiment in the debugger, and found that the entire CMS
message encoding process (which does the encryption and/or signing) was
being done twice during the sending of a single message.  

IMO, this is a major failing of SMIME feature of our mail clients.
One should be able to rely on the copy in the Sent folder being a true
copy of what was sent.  It should stand up in court as a true copy.
What we have now clearly would not.  

I don't know if this is a problem in the mail code or in PSM.  
I'm assigning this to PSM, but CC'ing David.  Guys, please advise on 
where this problem lies, and how big of a problem it would be to fix.
(Reporter)

Comment 1

11 years ago
Created attachment 264157 [details]
encrypted message as received in inbox
(Reporter)

Comment 2

11 years ago
Created attachment 264158 [details]
encrypted message as left in Sent folder

Comment 3

11 years ago
Why should the copy in the Sent folder be encrypted at all?  Doesn't that prevent the sender from reading the message, as it's encrypted with the public key of the recipient?
(Reporter)

Comment 4

11 years ago
I now think this is Invalid.  
I should have studied this more before reporting it.  

I suspect that base64 encoded section was apparently rewrapped by an MTA 
while in transit.  Comparing the base64-encoded parts, 
The message in the Sent folder had 16 lines of 72 characters each,
The message in the inbox       had 18 lines of 64 characters each.
The decoded contents of the two base64 sections are identical.  

It's still a mystery why the the libSMIME code gets invoked twice in the
sending of a single encrypted email, but it doesn't cause the problem
I reported in this bug.  Sorry.

In answer to Jesse's question:  The sender is always an implicit recipient
of the message.  The sender can decrypt the messages he sends with his 
own private key.  They're kept encrypted in the sent folder for the same
reason they're encrypted over the wire.  
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INVALID

Updated

9 years ago
Component: Security: S/MIME → Security: S/MIME
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.