Closed
Bug 380088
Opened 17 years ago
Closed 17 years ago
encrypted message in "Sent" folder is NOT a true copy of what was sent
Categories
(MailNews Core :: Security: S/MIME, defect)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: nelson, Assigned: KaiE)
Details
Attachments
(2 files)
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•17 years ago
|
||
Reporter | ||
Comment 2•17 years ago
|
||
Comment 3•17 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•17 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
Closed: 17 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•