1670243 - Thunderbird message display keeps showing stale `Sender: ...` header if an S/MIME email with `Sender: ...` header was viewed before, and mailnews.headers.showSender = false

Status: RESOLVED DUPLICATE of bug 1680843

(Thunderbird :: Security, defect, P1)

Description

[Michael Nüsken]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0

Steps to reproduce:

Display an email in classical layout with message area.

Actual results:

Message is displayed with some headers.
Among them "Sender XXX"
with XXX unrelated to the given message (actually for me it is an email address that only rarely occurs and is not in my address book).

Expected results:

Correct sender displayed or none.
The fields From, To, Subject, Cc are actually correctly translated into the display.

Comment 1

[Thomas D. (:thomas8)]

(In reply to Michael Nüsken from comment #0)

Hi Michael, unfortunately your report will not be actionable in any way without a lot more detail... denn hellsehen können wir leider nicht ;-)

• Does this "bug" still occur after using Help > Restart with addons disabled (TB safe mode)?
• If yes, I think we need the message source.

Please do this:

• select and save the offending message as testcase.eml on your desktop (Ctrl+S).
• Edit testcase.eml with a text editor and replace(!) any private data with structurally similar anonymous data. E.g., replace Michael Hausname <[e-mail]> with John Doe <[e-mail]>, and replace message text with "Hello world".
• Attach the message as an attachment to this bug using [Attach New File].

Among them "Sender XXX"

So you mean it shows From: XXX (Von: XXX), right? And how does XXX look like, structurally? Name? Email? Both?

with XXX unrelated to the given message (actually for me it is an email address that only rarely occurs and is not in my address book).

It's the sender's address, so it doesn't have to be in your AB...

• What makes you think it is the wrong address or unrelated to the message?
• Have you checked the source with Ctrl+U (Strg+U) to verify that the address (or at least the email part) which you are seeing is not in the message source? You can use Ctrl+F to search the source
• Have you used address book search to search for the email address?

The fields From, To, Subject, Cc are actually correctly translated into the display.

You mean, in the message header of the message preview pane, you're correctly seeing the header labels Von, An, Betreff, Kopie (CC)?

Comment 2

[Thomas D. (:thomas8)]

Also, what's your setting for "Bei bekannten Namen nur den Anzeigenamen anzeigen"? (show only display name for people in my AB)
≡ > Einstellungen > In Einstellungen suchen > Anzeigename (als Suchphrase eingeben)

Comment 3

[Michael Nüsken]

Ok, let me see.
(0)
Setting "Bei bekannten..." is active.
(1)
It affects any message, those in my inbox and even those in news feeds. [Image 0001.PNG]
The displayed sender address is completely unrelated to the messages and the same for all of them.
(2)
Another problem jumped up: I have sent a test mail "Test Sender" (actually twice, first without disabling "Attach public key"). In the moment the first arrived, the next earlier message subject changed in the display. (I know that I can "repair" but it's inconvenient if I have to do that very often.) [Image 0002.PNG]
(3)
After starting with addons disabled, the "Sender XXX" is gone. :)
But the wrongly displayed subject of the next earlier message is still wrong.
(4)
Restarting normally, the "Sender XXX" is still gone. [Whaaa!????]
That resolves the problem but makes the phenomenon even weirder.
Actually, I have recently updated from tb 68 to tb 78 and used the enigmail Goodbye procedure.
(5)
For refererence, my remaining active addons are:
"Open Google Calendar"
"Quick Folder Key Navigation"
and the Theme
"Walnut light"

Comment 4

[Michael Nüsken]

Attachment: 0001.PNG

Comment 5

[Michael Nüsken]

Attachment: 0002.PNG

Comment 6

[Michael Nüsken]

Attachment: test-email.eml

Comment 7

[Michael Nüsken]

Well, I do not know whether this can now be sorted out, as the problem completely disappeared after having used tb in safe mode once.

Comment 8

[Alfred Peters [:infofrommozilla]]

(In reply to Michael Nüsken from comment #7)

Well, I do not know whether this can now be sorted out, as the problem completely disappeared after having used tb in safe mode once.

Does the bug reappear when you first view that mail from this "ub-newsletter" witch has a real SENDER-header?

And is it fixed if you set the pref: "mailnews.headers.showSender" to true?

(Menu: Tools -> Options -> "General" -> [Config Editor]
Search for the pref and toggle the state.)

Comment 9

[Michael Nüsken]

Yes, it does reappear!
mailnews.headers.showSender was false.
Now it is true and... it still shows "Sender ub-newsletter <...>".
Turning it off again and... No change, it still shows the additional sender.
Restarting tb (normally) and... the "Sender ..." display is gone.

Comment 10

[Michael Nüsken]

Attachment: [ub-newsletter] Newsletter Nr. 16_2020.eml

Comment 11

[Michael Nüsken]

That's the ub-newsletter which makes "Sender ..." appear.

Comment 12

[Alfred Peters [:infofrommozilla]]

(In reply to Michael Nüsken from comment #9)

Yes, it does reappear!
mailnews.headers.showSender was false.
Now it is true and... it still shows "Sender ub-newsletter <...>".

This pref switches on the display of the sender header. The header is to be expected in the UB mail.
But for other emails it should disappear again with TRUE. right?

Comment 13

[Alfred Peters [:infofrommozilla]]

(In reply to Michael Nüsken from comment #10)

Attachment 9180834 [details]

Yes, with that mail I can confirm this bug.
It has to do with:

Content-Type: multipart/signed; protocol="application/pkcs7-signature";

When I change the Content-Type to normal text/plain, it doesn't occur.

Comment 14

[Michael Nüsken]

(In reply to Alfred Peters from comment #12)

(In reply to Michael Nüsken from comment #9)

Yes, it does reappear!
mailnews.headers.showSender was false.
Now it is true and... it still shows "Sender ub-newsletter <...>".

This pref switches on the display of the sender header. The header is to be expected in the UB mail.
But for other emails it should disappear again with TRUE. right?

No. The Sender ub-newsletter <...> is displayed all the time, regardless of the flag value.

Comment 15

[jouvin]

Hi,
Joining this thread as I experience exactly the same problem with a Sender line displayed for every message after the upgrade to TB 78. The sender displayed is not in the message source and is the same for every message. It comes clearly from a message where the Sender line is defined (a message sent by a list service, LISTSERV).
Reading through this thread, I desactivated the only extension I had, the Google Calendar provider and the problem disappeared. I hardly think it is coming from the extension that doesn't deal with emails but calendars... And I have the feeling that in Michael's case, it was not the same extension that was involved...

Comment 17

[Andreas Abel]

Me too, after upgrade to TB 78.
My only extension is "Mail Merge", my only addons are a Swedish and a German dictionary. (Can't blame it on the others, haha!)
All my emails display the same bogus "Sender" [e-mail].

Comment 19

[Andreas Schamanek]

A comment by Edward in a related bug suggested that mailnews.headers.showSender might have an effect. My tests using TB 78.6.0 on a Ubuntu 18.04 are positive: Setting mailnews.headers.showSender to "true" works around this bug. (Thanks Edward!)

Comment 21

[emmy.graugans]

(In reply to Andreas Schamanek from comment #19)

A comment by Edward in a related bug suggested that mailnews.headers.showSender might have an effect. My tests using TB 78.6.0 on a Ubuntu 18.04 are positive: Setting mailnews.headers.showSender to "true" works around this bug. (Thanks Edward!)

I can confirm that in Thunderbird 78.6.1 on macOS. In more details:

Setting that flag to true makes at first no difference at all, if the Sender-field was already displayed (wrongly and on all messages). Restarting Thunderbird with the flag set: Sender-field is shown (correctly) on the message where it's supposed to, Sender-field is not shown where none is set.

Setting the flag to false again (even without restart of Thunderbird): The Sender-Field is shown as soon as I look at a message with Sender-field and S/Mime signature – and never vanishes afterwards. Even worse, even emails with different Sender-Field (with or without S/Mime) show the OLD Sender-Field of the first S/Mime-Message with Sender-field in that session, and not that of the current message!

Setting the flag to true again requires a restart of Thunderbird to restore correct behaviour.

I hope that analysis helps somewhat in pinning down the bug.

Comment 24

[Gerald Vogt]

I have started a question on the support pages here: https://support.mozilla.org/en-US/questions/1323257

After some analysis I have found that the Sender header is shown for SMIME mails if the signer doesn't match the from address. This happens with some of my mailing lists which replace the from address with the list address.

I have mailnews.headers.showSender set to false, i.e. under normal circumstances it will show no sender header. When a Sender header is shown due to a SMIME mail this header isn't removed from the header pane after you move to the next mail. I guess because showSender is set to false noone thought that the Sender header may appear anyway. Therefore, the Sender header sticks to the pane until you open the next SMIME mail for which it shows a different Sender header.

From my debug runs of thunderbird it seems to me the problem is line 317 in msgHdrViewSMIMEOverlay.js

https://searchfox.org/comm-central/source/mail/extensions/smime/content/msgHdrViewSMIMEOverlay.js#317

Instead of set the header line to hidden it deletes the entry from gExpandedHeaderView which, however, doesn't mean it gets actually removed from the actual view.

Comment 29

[Wayne Mery (:wsmwk)]

Is this now actionable?

Comment 30

[Thomas D. (:thomas8)]

(In reply to Wayne Mery (:wsmwk) from comment #29)

Is this now actionable?

Yes, I've made it 150% actionable with a clean start in bug 1680843, where we'll try to fix it asap.
Thanks for the ping Wayne! Much appreciated.

Thanks everyone for reporting, testing and investigating! Your worthwhile input will enable us to work on this.
I think we now have a pretty clear picture of the exact circumstances when this occurs (see my new description/STR in Bug 1680843 Comment 5).
Gerald's comment 24 provides a promising starting point in code, thanks for that (carried over to Bug 1680843 Comment 7)!
There's gExpandedHeaderView.sender.enclosingRow.collapsed = true; which does look appropriate to hide the header, but for some reason does not (or perhaps the whole function is not always called).

Moving over to bug 1680843.
Technical comments towards fixing this will be welcome.