Closed
Bug 107817
Opened 23 years ago
Closed 23 years ago
Can not retrieve encrypted message from the "Sent" folder
Categories
(MailNews Core :: Security: S/MIME, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
psm2.2
People
(Reporter: alam, Assigned: KaiE)
References
Details
Attachments
(1 file, 1 obsolete file)
2.66 KB,
patch
|
ddrinan0264
:
review+
alecf
:
superreview+
roc
:
approval+
|
Details | Diff | Splinter Review |
Build Used: 2001-10-29-OTIS
Once you sent an encrypted message, try to retrieve it from the "Sent" folder
failed.
Step to reproduce:
1. Edit Mail Account setting to place an outgoing message in the "Sent" folder
in the IMAP mail account.
2. Compose and send an encrypted message. Verified that the recipient can
receive the encrypted message.
3. Go to the "Sent" folder in the IMAP account, and try to retrieve the just
sent encrypted message.
Actual result:
An alert dialog pop up saying the message is encrypted by the sender, but after
I click on the OK button, the message body didn't display in the message pane.
Instead, there is a "Part1.1" link in the attachment box, double clicking on it
causes the N6.2 to hang.
Expected result:
The sent encrypted message should be able to retrieved from the "Sent" folder
Remarks:
1. Retrieving a signed message from the "Sent" folder works fine.
2. Retrieving a signed/encrypted message from "Sent" folder has the same problem
3. Same problem if the message contain an attachment or not.
4. Same problem if I changed the setting to place an outgoing message in the
Local "Sent" Folder
Updated•23 years ago
|
Priority: -- → P1
Target Milestone: --- → 2.2
Reporter | ||
Updated•23 years ago
|
Component: Client Library → S/MIME
i'm a newbie in encryption/signing stuff but i thought i had similar problem:
I got a digital signature and certificate at Thawte.com on my computer at home.
Next, using this signature i requested a certificate for my computer at work.
Funnily enough, i could NOT read encrypted messages at my WORK computer from
threads that were send/received at my HOME computer.
I solved the problem by exporting the certificate from my home computer and
importing it at my work computer. I think the original cert (HOME) contains both
the private and the public key, and re-issues (WORK) only contain the public key.
Maybe that's part of the problem : the certificates that you use to read this
message my not be a proper one for this particular message?
Moreover, methink tis only logical you have no problems reading SIGNED messages:
nothing is changed in those message.
Updated•23 years ago
|
QA Contact: junruh → alam
Comment 2•23 years ago
|
||
I'm confirming the problem in Mozilla 0.9.8 on Linux..
In Netscape 4.x an encrypted sent message is readable by the sender..
Probably the problem is that the way S/MIME works, either the message is missing
some key for the sender or the message saved in the send folder needs to be
encrypted differently..
Comment 3•23 years ago
|
||
Re-assigning to Kai.
When creating an encrypted message, the sender should also be included as a
recipient if the sender is not already a recipient (i.e. on the to: cc: or bcc:
fields). All that should be needed here is to add the senders certs to the list
of recipient certs before calling nsCMSMessage::CreateEncrypted.
Assignee: ddrinan → kaie
Comment 4•23 years ago
|
||
S/MIME bugs are automatically nsbeta1 candidates. (this is a bulk update - there
may be some adjustment of the list).
Keywords: nsbeta1
Assignee | ||
Comment 5•23 years ago
|
||
Indeed, this small patch makes it work.
I think it is easier to add self's configured encryption cert to the list of
recipient certs, instead of querying the list of recipients.
Comment 6•23 years ago
|
||
Adding the senders cert should only be done if the sender is *not* on the to: or
cc: line.
Comment 7•23 years ago
|
||
Removing nsbeta1 nomination, as this bug has been nsbeta1+.
Keywords: nsbeta1
Comment 8•23 years ago
|
||
*** Bug 127580 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 9•23 years ago
|
||
> Adding the senders cert should only be done if the sender is *not* on the to: or
> cc: line.
My motivation for doing it that way was the following:
We currently do not have a check, whether the sender's email address is actually
identical to the email address contained in the configured cert.
Unless we enforce that to be identical everywhere, the safest thing to do is to
just add the sender's cert.
But I agree that we should not add the same cert twice to the list of recipient
certs.
I suggest, inside the loop when adding the recipient's certs, we try to detect
whether one is identical with the own encryption cert. If it is, we will
remember that, and not add that cert again.
Is that ok?
Comment 10•23 years ago
|
||
Kai,
To see what I mean, take a look at how Communicator does this. Look at
SECMIME_CreateEncrypted() in mozilla/security/nss/lib/pkcs7/secmime.c. There is
a piece of code that filters out the users cert if it has already been included.
for (rci = 0; rcerts[rci] != NULL; rci++) {
if (rcerts[rci] == scert)
continue;
if (SEC_PKCS7AddRecipient (cinfo, rcerts[rci], certUsageEmailRecipient,
NULL) != SECSuccess) {
SEC_PKCS7DestroyContentInfo (cinfo);
return NULL;
}
}
You should be able to do a similar thing in mozilla.
Comment 11•23 years ago
|
||
This works for me with the 3/20 Win2000 trunk build.
Status: NEW → RESOLVED
Closed: 23 years ago
QA Contact: alam → junruh
Resolution: --- → WORKSFORME
Reporter | ||
Comment 12•23 years ago
|
||
Tried with 2002032203 trunk on Win2K, and I still saw the same problem. It
showed <invalid encryption> in the header pane, and the message body is
disappered.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Assignee | ||
Comment 13•23 years ago
|
||
This patch prevents that self's certificate is added, if self was already on
the recipient list.
Attachment #69438 -
Attachment is obsolete: true
Assignee | ||
Comment 14•23 years ago
|
||
David, can you please review?
Comment 15•23 years ago
|
||
Comment on attachment 75963 [details] [diff] [review]
Updated patch
r=ddrinan
Attachment #75963 -
Flags: review+
Assignee | ||
Comment 16•23 years ago
|
||
Alec, can you please review?
Thanks.
Comment 17•23 years ago
|
||
Comment on attachment 75963 [details] [diff] [review]
Updated patch
sr=alecf
Attachment #75963 -
Flags: superreview+
Attachment #75963 -
Flags: approval+
Comment on attachment 75963 [details] [diff] [review]
Updated patch
a=roc+moz
Assignee | ||
Comment 19•23 years ago
|
||
patch checked in, fixed.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 21•23 years ago
|
||
*** Bug 135848 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•