Closed Bug 107817 Opened 23 years ago Closed 22 years ago

Can not retrieve encrypted message from the "Sent" folder

Categories

(MailNews Core :: Security: S/MIME, defect, P1)

1.0 Branch
x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED
psm2.2

People

(Reporter: alam, Assigned: KaiE)

References

Details

Attachments

(1 file, 1 obsolete file)

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
Priority: -- → P1
Target Milestone: --- → 2.2
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.
QA Contact: junruh → alam
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..
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
Blocks: 106724
S/MIME bugs are automatically nsbeta1 candidates. (this is a bulk update - there
may be some adjustment of the list).
Keywords: nsbeta1
Attached patch Suggested fix (obsolete) — Splinter Review
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.
Keywords: nsbeta1+
Adding the senders cert should only be done if the sender is *not* on the to: or 
cc: line.
Removing nsbeta1 nomination, as this bug has been nsbeta1+.
Keywords: nsbeta1
*** Bug 127580 has been marked as a duplicate of this bug. ***
> 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?
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.
This works for me with the 3/20 Win2000 trunk build.
Status: NEW → RESOLVED
Closed: 22 years ago
QA Contact: alam → junruh
Resolution: --- → WORKSFORME
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 → ---
Attached patch Updated patchSplinter Review
This patch prevents that self's certificate is added, if self was already on
the recipient list.
Attachment #69438 - Attachment is obsolete: true
David, can you please review?
Keywords: patch, review
Comment on attachment 75963 [details] [diff] [review]
Updated patch

r=ddrinan
Attachment #75963 - Flags: review+
Alec, can you please review?
Thanks.
Comment on attachment 75963 [details] [diff] [review]
Updated patch

sr=alecf
Attachment #75963 - Flags: superreview+
patch checked in, fixed.
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
Verified.
Status: RESOLVED → VERIFIED
*** Bug 135848 has been marked as a duplicate of this bug. ***
remove blocking reference.
No longer blocks: 106724
Product: PSM → Core
Version: psm2.1 → 1.0 Branch
Product: Core → MailNews Core
QA Contact: junruh → s.mime
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: