381659 - "Multipart/Encrypted" not supported, only "multipart/encrypted"

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Danai Sae-Han]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; nl; rv:1.8.1.3) Gecko/20070310 Iceweasel/2.0.0.3 (Debian-2.0.0.3-2)
Build Identifier: Mozilla-Thunderbird 1.5.0.10

Hi!

When I send encrypted emails from Mew (Messaging in the Emacs World; http://www.mew.org/), I can't open them in TB+Enigmail.

Problem is that TB doesn't understand "Multipart/Encrypted".  But when I manually edit the outgoing email from Mew, and replace it with the lowercase "multipart/encrypted", TB will recognize my email and Enigmail will do its work just fine.

I hope you can fix this problem.

Thanks


/Danai

Reproducible: Always

Steps to Reproduce:
1. Send an encrypted email from Mew
2. Open TB and receive the email
3. Open the email
Actual Results:  
Blank message window, with "Part 1.1" and "Part 1.2" as attachments, the first containing the Mime version "1.0", the latter the raw encrypted message.

Expected Results:  
Popup window asking me for a password, and decrypting the email.

http://mozdev.org/bugs/show_bug.cgi?id=7269 shows that this bug has been reported two and a half years ago against Enigmail, but the author wrote this needed to be fixed in TB to get an elegant solution.

Comment 1

[Tuukka Tolvanen (sp3000)]

for reference, http://www.faqs.org/rfcs/rfc2045.html (mime)
5.1.  Syntax of the Content-Type Header Field
     content := "Content-Type" ":" type "/" subtype
                *(";" parameter)
                ; Matching of media type and subtype
                ; is ALWAYS case-insensitive.
   The type, subtype, and parameter names are not case sensitive.  For
   example, TEXT, Text, and TeXt are all equivalent top-level media
   types.

Comment 2

[Danai Sae-Han]

Indeed.  I reported this bug, because apparently bug #59619, "MIME types should not be case sensitive" (https://bugzilla.mozilla.org/show_bug.cgi?id=59619), is not the same as this one.

Comment 3

[Danai Sae-Han]

I just installed Mozilla-Thunderbird 2.0.0.0, and it has the same problem: the encrypted email appears as "Part 1.1" and "Part 1.2".

Comment 4

[u63580]

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; nl; rv:1.8.1.3)
> Gecko/20070310 Iceweasel/2.0.0.3 (Debian-2.0.0.3-2)
> Build Identifier: Mozilla-Thunderbird 1.5.0.10
> 
> Hi!
> 
> When I send encrypted emails from Mew (Messaging in the Emacs World;
> http://www.mew.org/), I can't open them in TB+Enigmail.
> 
> Problem is that TB doesn't understand "Multipart/Encrypted".  But when I
> manually edit the outgoing email from Mew, and replace it with the lowercase
> "multipart/encrypted", TB will recognize my email and Enigmail will do its work
> just fine.
> 
> I hope you can fix this problem.
> 
> Thanks
> 
> 
> /Danai
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1. Send an encrypted email from Mew
> 2. Open TB and receive the email
> 3. Open the email
> Actual Results:  
> Blank message window, with "Part 1.1" and "Part 1.2" as attachments, the first
> containing the Mime version "1.0", the latter the raw encrypted message.
> 
> Expected Results:  
> Popup window asking me for a password, and decrypting the email.
> 
> http://mozdev.org/bugs/show_bug.cgi?id=7269 shows that this bug has been
> reported two and a half years ago against Enigmail, but the author wrote this
> needed to be fixed in TB to get an elegant solution.
> 

That said, I'm not sure this is a bug in TB per se.  I suspect WONTFIX, but hat is a developer decision.

Comment 5

[Patrick Brunschwig]

I almost forgot about this bug. Scott, maybe you have any idea? For some strange reason, none of the Enigmail code is called if the content-type of an email ("mutlipart/encrypted") is not 100% in small letters. 

Here is how I register the content-type handler in Mozilla:
  static const nsModuleComponentInfo info =
  { "Enigmail Content Handler",
    NS_ENIGCONTENTHANDLER_CID /* some UUID */,
    ""@mozilla.org/mimecth;1?type=multipart/encrypted",
    nsEnigContentHandlerConstructor,
  };

  // Create a generic factory for the content handler
  nsCOMPtr<nsIGenericFactory> factory;
  rv = NS_NewGenericFactory(getter_AddRefs(factory), &info);
  if (NS_FAILED(rv)) return rv;

  nsCOMPtr<nsIComponentRegistrar> registrar;
  rv = NS_GetComponentRegistrar(getter_AddRefs(registrar));
  if (NS_FAILED(rv)) return rv;

  // Register factory
  rv = registrar->RegisterFactory(info.mCID, info.mDescription,
                                           info.mContractID, factory);

  if (NS_FAILED(rv)) return rv;

Comment 6

[Magnus Melin [:mkmelin]]

I wonder if this still exists on trunk? Might have been fixed by the changes in bug 409962.

Comment 7

[Patrick Brunschwig]

Unfortunately the bug is still not fixed, I checked with the latest nightly build (20080831030154): .

Comment 8

[Magnus Melin [:mkmelin]]

Attachment: proposed fix

Patrick: are you able to try and see if this patch fixes it for you?

Comment 9

[Patrick Brunschwig]

Magnus, I tried the patch: yes it fixes the bug -- I'd say commit it :-)

Comment 10

[David :Bienvenu]

Comment on attachment 342796 [details] [diff] [review]
proposed fix

this would leak memory, since ToNewCString allocates. You should just be able to use lowerCaseContentType.get().

While we're here, and testing this code, we should rewrite it to use an nsCString for lookupID. Then, I think we can just init it with "@mozilla.org/mimecth;1?type=", and append the lower case content type, or append the content_type and lower case the whole string...

Comment 11

[Magnus Melin [:mkmelin]]

Attachment: proposed fix, v2

Hopefully this is better:)

Comment 12

[David :Bienvenu]

Comment on attachment 343068 [details] [diff] [review]
proposed fix, v2

yes, thanks!

Comment 13

[Magnus Melin [:mkmelin]]

changeset:   610:0e2ef43af74d
http://hg.mozilla.org/comm-central/rev/0e2ef43af74d

->FIXED