Last Comment Bug 517593 - enigmail ends up adding funny mail headers to Tb3 header pane
: enigmail ends up adding funny mail headers to Tb3 header pane
Status: NEW
Product: Thunderbird
Classification: Client Software
Component: Message Reader UI (show other bugs)
: 3.0
: x86 Windows Vista
-- normal with 3 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: 523536 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2009-09-18 15:55 PDT by John Beranek
Modified: 2015-09-26 22:02 PDT (History)
7 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---


Description User image John Beranek 2009-09-18 15:55:00 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv: Gecko/20090824 Firefox/3.5.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20090917 Lightning/1.0pre Shredder/3.0pre

As discussed on

If you have a Tb2 profile where you've installed Enigmail and you upgrade to Tb3, you get the header pane showing funny headers for some messages. It turns out that this is because Enigmail has set the preference 'mailnews.headers.extraExpandedHeaders' to 'x-enigmail-version content-transfer-encoding openpgp x-mimeole x-bugzilla-reason x-php-bug'.

dmose has said:

It's consistent with my theory that Enigmail is adding them to the pref you mentioned because it needs them for a side-effect, and then doing something special to keep the headers from appearing.  If true, that implies that the hook that core is offering extension authors is indeed sub-optimal.

Reproducible: Always

Steps to Reproduce:
1.Make a clean profile
2.In Thunderbird 2, add Enigmail 0.96.0
3.Restart Tb2 to finish installation
4.Close Tb2
5.Start Tb3
6.Go to any message that has any of the headers shown in the details of this bug
Actual Results:  
The mail header pane shows what most users consider to be utterly pointless headers, like 'content-encoding' and 'x-bugzilla-cc'.

Expected Results:  
The mail header pane should not show pointless headers.
Comment 1 User image Andrew Sutherland [:asuth] 2009-09-18 16:36:37 PDT
Yes, the hook is dumb.  The C++ header sink's attempt to save the UI from seeing headers that don't need to be displayed and the UI's dependence on this should be rectified.
Comment 2 User image Dan Mosedale (:dmose) 2009-09-18 17:04:06 PDT
While I agree that the libmime code is rotten for extensions, at the time it was done, it apparently won a non-trivial amount of performance back (it wasn't always that way).  Adding bienvenu, as perhaps he has thoughts here.

Really, though, we probably just need to re-profile, as the header has changed quite a bit since those days.
Comment 3 User image Andrew Sutherland [:asuth] 2009-09-18 17:12:10 PDT
I think the more important thing is just stopping the UI from assuming that every header it is told about it wants to display.  Because I have a filter on a custom header, x-bugzilla-reason, every message I look at that includes that header displays it to me, even though I don't really want to see it.

In terms of performance, I think we already have the answer.  Gloda indexing on a box that was top-of-the-line-ish 2 years ago is able to stream and index 15 - 25 messages per second.  That includes both the mime emitter stuff and all of the indexing processing and a non-trivial amount of work involving pseudo-asynchronous database work.

Now, if the message header is doing anything that touches layout every time it sees a header, I could see how the performance would be disastrous.  But I trust we no longer do that if we ever did that.
Comment 4 User image Maurits 2009-09-29 16:07:30 PDT
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/20090915 Thunderbird/3.0b4
this behaviour is also seen on a mac (so Not X86 vista specific)
with Enigmail 0.96.0 and also the nightly version of enigmail 0.97a 20090930

It is as describe in comment 1:)
mailnews.headers.extraExpandedHeaders  'x-enigmail-version
content-transfer-encoding openpgp x-mimeole x-bugzilla-reason x-php-bug'.
And the doing something special part: extensions.enigmail.hideHeaders  'x-enigmail-version openpgp content-transfer-encoding x-mimeole x-bugzilla-reason x-php-bug' not being honored.
I removed 'x-enigmail-version content-transfer-encoding' from the 1st string. and that seems to fix the most frequent occurences. (enigmail is still working)
Comment 5 User image Patrick Brunschwig 2009-09-29 22:55:56 PDT
I can assure you that the content-transfer-encoding is required for Enigmail to work properly. It may not be needed for the messages you have decrypted, but this does not apply to all messages there are in the world.
Comment 6 User image [:Aureliano Buendía] 2009-10-21 00:36:44 PDT
*** Bug 523536 has been marked as a duplicate of this bug. ***
Comment 7 User image Jan Beyer 2011-04-06 07:38:16 PDT
On Debian GNU/Linux using Thunderbird (Icedove) 3.0.11, the problem persisted. Without having enigmail installed - probably it got lost during transition from TB2 to TB3 some time ago. But installing enigmail 1.0.1 now solved the problem - the spurious header line disappeared.
Comment 8 User image Ludovic Hirlimann [:Usul] 2011-04-13 05:35:47 PDT
Why do we keep this bug open ?

Note You need to log in before you can comment on or make changes to this bug.