User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729) Build Identifier: 184.108.40.206 (20090302) Communicating signed and encrypted e-mail between Eudora 220.127.116.11 and Thunderbird exhibits interoperability problems. In particular, the headers that Thunderbird emit are: signed e-mail (signature part): Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Enveloped e-mail: Content-Type: application/x-pkcs7-mime; name="smime.p7m" Content-Disposition: attachment; filename="smime.p7m" Although close, these are not actually valid per S/MIME v3 (RFC 2633). As a result, Eudora does not recognize the message as valid S/MIME. S/MIME v3 in RFC 2633 defines the content-types application/pkcs7-mime application/pkcs7-signature (without the x- part) Furthermore S/MIME v3 specifies the optional smime-type parameter for application/pkcs7-mime, which is set to enveloped-data or signed-data as the case may be. Although optional, this parameter is useful because some mail clients (e.g., Outlook) will interpret it before reading the contents. Therefore, the smime-type parameter should be added as well. Reproducible: Always Steps to Reproduce: 1. Send a message to a Eudora user in Thunderbird with S/MIME signature or encryption services applied. Actual Results: 1. Recipient cannot use the S/MIME features in Eudora with the message. Expected Results: Recipient should be able to While some blame can be placed at Eudora's feet for not interpreting "application/x-pkcs7-mime" and "application/x-pkcs7-signature" "properly", in fact application/x-pkcs7-mime was never standardized in any S/MIME RFC. These types appeared in the first pre-release draft of S/MIME v2 (RFC 2311), but were quickly moved to an appendix (C.1).
Removing the x- is a duplicate of bug 436869, fixed long ago. Could you please try a 3.0 beta or nightly, see whether there's anything left you still want, and morph to be about that? (I see there's code that sticks smime-type params on, but I don't personally know whether/where it's actually used.)
Thanks. I have tested with Thunderbird 3.0 nightly (20090621 3.0b3pre). The types are properly serialized out as application/pkcs7-mime and application/pkcs7-signature. Thanks. Nevertheless, the smime-type parameter is not added. I therefore request that this bug be morphed to add the appropriate smime-type parameter. Although I have not fully groked the source code, it looks like the only change required is on line 587 of nsMsgComposeSecure.cpp: add "; smime-type=enveloped-data" prior to the CRLF. (Or if you want, add a CRLF SPACE between ; and smime-type or whatever so it is not on one giant line.) I am not sure if it is possible to emit opaque-signed data in Thunderbird, but it looks like not. The rest of the code that mentions "smime-type" is either NSS test code, or is code for the (list) view of messages. Therefore, at least in theory Thunderbird should be able to use that information appropriately when reading its own messages. Can this bug also be morphed to deal with the Eudora problem in the Eudora codebase, as Eudora only recognizes the MIME types without the "x-"? Has change control for Eudora been ceded to Mozilla?
Kai, do you know enough to judge the suggestion in comment #2? Denying blocking until we have more info from someone familiar w/ SMIME and the TB codebase =).
Sean, could you please give us a little bit background? Is this the first time someone attempts to make Eudora and Thunderbird interoperable on the S/Mime level? Or did this work in the past and this bug is a regression report?
If this is not a regression, I would suggest that Eudora attempts to understand what classic versions of Thunderbird sent, in order to achieve greater compatibility with installed software base.
(In reply to comment #2) > Although I have not fully groked the source code, it looks like the only change > required is on line 587 of nsMsgComposeSecure.cpp: > add "; smime-type=enveloped-data" prior to the CRLF. (Or if you want, add a > CRLF SPACE between ; and smime-type or whatever so it is not on one giant > line.) Sean, the source code changes over time, lines get moved. When you write statements like this, please always include some context or at least the exact line you want to change. When I look at this file, line 587 is the blank line before function nsresult nsMsgComposeSecure::MimeInitEncryption(PRBool aSign, nsIMsgSendReport *sendReport) I would like to propose, please give complete examples. Please attach a message as it is being sent today (wrong in your opinion), then manually alter that message to look according to your proposal and attach it, too. This will make it easier for others to understand your proposed change. Thanks
When you describe your change, please also describe why you believe your change is safe and remains compatible with other versions of Thunderbird. Thanks.
Sorry about dropping the ball here--it looks like this never got confirmed. I am now looking at the latest source code, namely, at: http://mxr.mozilla.org/comm-central/source/mailnews/extensions/smime/src/nsMsgComposeSecure.cpp The revision is f9d76929e7a4. To give context: initially this bug was mainly about "application/x-pkcs7-mime" versus "application/pkcs7-mime". Eudora was not interpreting the x- variant. That problem, however, appears to have been fixed awhile ago. The other part of this bug was to emit the "smime-type" parameter in the MIME headers. This parameter helps a decoder identify what kind of CMS entity it is, EnvelopedData or SignedData, without needing to invoke an ASN.1 parser to start to parse the inner contents. We are now looking at nsresult nsMsgComposeSecure::MimeInitEncryption(PRBool aSign, nsIMsgSendReport *sendReport) specifically, at the lines after: PR_smprintf("Content-Type: " APPLICATION_PKCS7_MIME (which in this revision, is line 567, about 20 lines down) The point is to add between lines 567 (see above) and line 568, the following line: "; smime-type=enveloped-data" That's it. No need for more CRLF line breaks. Compare with section 3.3 of RFC 2633. Again, sorry for the long hiatus.
(In reply to comment #8) > Sorry about dropping the ball here--it looks like this never got confirmed. > > I am now looking at the latest source code, namely, at: > http://mxr.mozilla.org/comm-central/source/mailnews/extensions/smime/src/nsMsgComposeSecure.cpp > > The revision is f9d76929e7a4. > > To give context: initially this bug was mainly about "application/x-pkcs7-mime" > versus "application/pkcs7-mime". Eudora was not interpreting the x- variant. > That problem, however, appears to have been fixed awhile ago. > > The other part of this bug was to emit the "smime-type" parameter in the MIME > headers. This parameter helps a decoder identify what kind of CMS entity it is, > EnvelopedData or SignedData, without needing to invoke an ASN.1 parser to start > to parse the inner contents. > > We are now looking at > nsresult nsMsgComposeSecure::MimeInitEncryption(PRBool aSign, nsIMsgSendReport > *sendReport) > > specifically, at the lines after: > PR_smprintf("Content-Type: " APPLICATION_PKCS7_MIME > > (which in this revision, is line 567, about 20 lines down) > > The point is to add between lines 567 (see above) and line 568, the following > line: > "; smime-type=enveloped-data" Can you provide a patch to do that ?
The "missing smime-type" issue has not changed with TB 5.0. Though this is not a MUST in S/MIME v3.2 the following is stated at the end of section 3.2 of RFC 5751: "Because there are several types of application/pkcs7-mime objects, a sending agent SHOULD do as much as possible to help a receiving agent know about the contents of the object without forcing the receiving agent to decode the ASN.1 for the object. The Content-Type header field of all application/pkcs7-mime objects SHOULD include the optional "smime-type" parameter, as described in the following sections." Without such a proper smime-type parameter one has to dive into the content to find the proper type, which is everything else than convenient.
PS: It's still the same with TB 8.0.
Created attachment 581756 [details] [diff] [review] Added smime-type=enveloped-data This patch fixes the smime-type=enveloped-data absence. Let's get it in.
Comment on attachment 581756 [details] [diff] [review] Added smime-type=enveloped-data All patches require review before they can be landed. See these pages for more details: https://developer.mozilla.org/en/Code_Review_FAQ https://developer.mozilla.org/en/Mailnews_and_Mail_code_review_requirements I'll request review from Kai as I think that's most appropriate here.
I'd like to support Comment #10 and mention the bug is still present in TB 9.0.1. The issue isn't a matter of Eudora-TB compatability but rather of the possibility to send S/MIME secured mail using TB. For instance, I've found the problem trying to send S/MIME mail to the user of the newest Horde/Imp MUA. Horde S/MIME code expects "smime-type=enveloped-data" parameter presence and in case of it's absence simply doesn't decrypt the message. In my opinion the patch is needed ASAP.
So Kai argued that others should get compatible with Thunderbird. Well mutt tries that: /* Netscape 4.7 uses * Content-Description: S/MIME Encrypted Message * instead of Content-Type parameter */ if (!ascii_strcasecmp (m->description, "S/MIME Encrypted Message")) return SMIMEENCRYPT; The thing is: Thunderbird translates that string. So first of all it doesn't send the smime-type which is specified in the RFC, but secondly it breaks others who go the extra step to detect Netscape proprietary S/MIME handling and then the string's translated: Content-Description: S/MIME Verschlüsselte Nachricht The umlaut ü is not even properly encoded, so it does send 8bit characters in the header. I realize that this may be considered a different bug, but adding smime-type support would of course solve those issues once and for all. Please tell me if I need to file a different bug to at least get the Content-Description translation issue fixed in time. (The sender uses TB 10.0 with lang=de.)
Comment on attachment 581756 [details] [diff] [review] Added smime-type=enveloped-data sorry, I don't have time to focus on this.
Comment on attachment 581756 [details] [diff] [review] Added smime-type=enveloped-data I'm no expert to S/MIME unfortunately, however the change looks good to me. Rather delegating to David Bienvenu.
Comment on attachment 581756 [details] [diff] [review] Added smime-type=enveloped-data seems reasonable to me - we should just be looking out for any interoperability regressions.
https://hg.mozilla.org/comm-central/rev/bed310fd6408 Thanks for the patch, Sean! Sorry for the horrible lag in getting it checked in :(
Any way to add this patch in the next version? Do we have to wait thunderbird 19? As for now, I can't send encrypted email to another trusted company, because of the smime-type=enveloped-data field missing (they reject our mails). Regards
Thunderbird 19 is out in beta since a long time. You'l have to wait for 24 to get it on stable ...