243258 - Show email address in message list

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, enhancement, P1)

Description

[Steve Meyers]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040124
Build Identifier: version 0.6 (20040502)

There should be an option to show the email address along side the display name
in the sender column of the mail list.  This would make it easier to identify
spam without having to open it.

Reproducible: Always
Steps to Reproduce:
1. Run thunderbird
2. Look at the message list

Actual Results:  
Only the "display name" is shown

Expected Results:  
The sender column should show the display name followed by the email address
enclosed in angled brackets <>.  A tooltip should show the entire display name
plus email address if it is too long.

Comment 1

[deleteaccount]

Somewhat related request, I would like the message panes to show real name
<email address>.  It seems somewhat erratic now, my guess is the To and CC
fields are always just real name.  At least this could be an option.

Comment 2

[Jared Buck]

I am having this problem too - TB shows the email addresses only in the message 
view pane, but i want to see the display name.  OE, Eudora, and other email 
clients i have used have this option by default.

It's something that needs to be addressed, because i'm sure there are other 
users like me that want to see display names in the message view pane.

Comment 3

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 4

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.

Comment 5

[Ben]

I would like this reopened for Thunderbird (now at v17).
This feature request is more than eye candy.  It can / will add to the SECURITY & PRIVACY by users not accidentally clicking on spam that got by filters, or verifying if "good" mail (or expected mail) was accidentally marked spam.  

For years I've asked / searched about way to show the actual email address in Thunderbird message (list) pane, rather than JUST the name of a person.  I've seen many requests on forums - Mozillazine, getsatisfaction.com/mozilla_messaging - for same option.  

I believe there are addons to do this, but that's one more addon to do something that should be an included option in Tbird.

Most likely, this feature would be enabled by adding another option in the existing drop box of "columns to display" in the message list pane - such as "show sender email address," as a separate column in message pane list (AND / OR in a tool tip pop up, hovering over From: name).  The former is a VERY simple addition for Tbird devs.

JUSTIFICATION / USEFULNESS

In full header, the From shows: From: "Web Hosting Unleashed" <[e-mail]>
Add a method / column option to display the actual email address part:  <[e-mail]>

1) If the sender included NO name in front of the email address - header has only an address like:  <[e-mail]>, then From: column in message list will be BLANK.  This happens quite often.

2) If my friend, "John" (whether in my address book or not) uses an address & name: "John <[e-mail]>" then Thunderbird only shows "John" in From: column of message list.

If I receive spam or just mail from unknown person / source, ALSO using the name "John," I can't tell if it's from my friend or unknown / unwanted source.

3) If I receive spam:
a) That's IS marked as spam:
but the "name" of sender displayed in From: column is the same as a friend, I can't tell by looking if a friend's email unintentionally got marked as junk.  There's no email address to immediately confirm that.  If a friend's email is marked junk, but I can see the address (& name) is:
"John <[e-mail]>" there's a excellent chance it's from a friend.

b) That's NOT marked as spam:
But has a name in From: column that could be from a friend, if the full email address is shown as an optional column (or in a tool tip pop up, hovering over From: name), then I immediately know w/ 99% confidence it's from my friend.

*OR* it's an address I never heard of (VERY likely spam) as:  John <2#1$!@fake.mail.ru.com>
where, in last example, Thunderbird will currently STILL only display "John" in From column, in message list pane.

Sure, email addresses CAN be spoofed.  But if an email slips past spam filters that has address: "John <2#1$!@fake.mail.ru.com>" - I KNOW it's junk & can delete it w/o EVER opening it.

If "good" email got marked as junk, users always have the option to view in plain text.  (That SHOULD be default behavior of Tbird for junk mail, as in many web mail viewers, but that's another request).

Comment 6

[Blake Winton (:bwinton) (:☕️)]

Yeah, I'ld be up for re-opening this.

I would be happy with either or both of
1) adding a "From Email Address" column to the list (not selected by default), and
2) adding a tooltip to the From column which showed the email address.

Thanks for the comment, and if you'ld like to try fixing the bug, please email me and I'll do what I can to help you get started!  :)

Comment 7

[Ed]

See also 1660429.

Comment 8

[franz.heinz]

Problem still exists. With version 115 the add-on used as workaround doesn't work any more, either.

Comment 9

[Joe]

This issue still persists. The information from Steve Meyers from 20 years ago is still valid. This is a security issue. I would highly appreciate it if it would get fixed. Thank you.

Comment 10

[adir]

Please make neccessary changes to Thunderbird 115 for supporting add-on "Full address column"
https://addons.thunderbird.net/de/thunderbird/addon/full-address-column/
Its important to see real sender's email-adress!
Thank you!

Comment 11

[Johny Bugs]

Please reinstall BASIC SECURITY feature to be able to see real sender's email-address BEFORE opening an email. In other words adjust privileges to make it possible again to manipulate columns from an add-on like full-address-column.
Thank you!
Should be standard feature.

Comment 12

[blackwolf]

Its a shame that Thunderbird has since 20 years not the option to show only the real mail-Adresss. And now its blocks the add-on "full-address-column". Its very important to see real sender's email-adress! Whatsever as option or addon.

Comment 13

[lynnel02]

Since upgrading to TB 115 the plugin I used to display the sender's actual email address in the inbox list no longer works. Please fix this bug.

Comment 14

[John Bieling (:TbSync)]

Please try to not mix bugs. The bug regarding the add-on issue is Bug 1817682. And we are working on it.

Comment 15

[gjdultz01]

There needs to be an option or add-on to show the full email address along side the display name in the sender column of the mail list. This will make it easier to identify unwanted & spam email without having to open it.
The old add-on "Full Address column" did exactly what needs to be added back into Thunderbird.

Comment 16

[nanami-n]

The latest version of Thunderbird, 115.4.1, does not display the sender's email address in the list of received emails.

It would be very convenient if the sender's email address was displayed in the list of received emails, allowing you to distinguish between spam and phishing emails.

I use Thunderbird 102.15.1 and the add-on "Full Address column", and it's very helpful in avoiding spam and phishing emails.

I have Thunderbird updates disabled because it's very convenient.

It's hard for me to understand why this feature was discontinued.

I believe that disabling this feature will only encourage the spread of spam and phishing emails.

Please bring back this feature.

Comment 17

[[e-mail]]

I consider this missing feature a security necessity. Previously we were able to use an add-on for what I think should be included in the base program by default. However, the recent code rewrite has made this impossible. In order to get this back we will need to add this into Thunderbird, itself. Let me stress that this feature is the main reason why I use Thunderbird, and will likely no longer do so should you refuse to add it back. Again, this is a deal-breaker feature, and I will withhold all donations and support until it's implimented. I can't live without it.

Comment 18

[M. Rosenbach]

I strongly agree with the forementioned arguments concerning security - the functionality is mandatory!

Comment 19

[JRV]

I agree with all the prior commenters. An option or add-on to show the full email address along side the display name in the sender column of the mail list is direly needed. Even being able to "hover over" the display name and show the full address would be beneficial. Any method to show the full email address would make it easier to identify unwanted & spam email without having to open the actual email or inspect the headers.

Comment 20

[ghmendel]

I agree with the strong necessity to be able to see the actual email address of the "From:" since it is my most common way of determining spam/junk. I used to log in to my ISP web-mail to check on suspected spam until I realized they (unchangeably) deleted "spam" after 7-days; they also had about 50% false positive AND 50% false negative with spam detection AND no way to control spam rules. Now I'm teaching TB by marking everything new junk/not junk but have to risk opening emails to determine actual from address. Please, please fix.

Comment 21

[John Bieling (:TbSync)]

I understand your frustration, and I do see the need to see the real address of the sender.

Most of the recent commenters are here, because the add-on "Full Address Column" no longer works in TB115. I am responsible for the add-on component and I already mentioned in Comment 14, that we do intend to allow add-ons to add columns again. But I also have to prioritize the stack of bugs I work on, and I was simply busy doing other work. I just raised the priority of bug 1817682 to P1.

I am not in a position to deal with adding the column with the real sender as a core function, which this bug is about. This bug does not need further comments regarding the missing column support for add-ons in TB115, because these should go in bug 1817682.

Comment 22

[[e-mail]]

I reiterate the general interest in being able to monitor the sending address directly and natively in Thunderbird's mail overview in order to avoid fraud and to respectfully distinguish in which function a sender sends an email.

Comment 23

[rthx]

@John Bieling (:TbSync)
Why an add-on for this functionality?

Why not simply implement it in Thunderbird!

The e-mail address not only in the message view pane, but also in the message list, as suggested 20 years ago by Steve Meyers.

So the same display in the "from" column in the message list as in the message view pane.

What's wrong with that, it can't be that difficult.

Comment 24

[John Bieling (:TbSync)]

(In reply to rthx from comment #23)

@John Bieling (:TbSync)
Why an add-on for this functionality?

Why not simply implement it in Thunderbird!

It is not my area of expertise. I am only here because this bug was flooded with remarks concerning the add-on, which should not at all be posted here, but in bug 1817682.

Comment 25

[rthx]

And who is responsible from Mozilla for this functionality that was claimed 20 years ago?

It looks like nobody at Mozilla feels responsible for it.

To set the record straight - this functionality should be implemented directly in Thunderbird and not via an add-on. So the reference to bug 1817682 is not appropriate for this functionality in my opinion.

I fully agree with the first post.

I don't understand why this still hasn't been implemented.

As I said, it works in the message view pane - why not in the message list as well?

Comment 26

[Robert]

For me, the display of the original email address was a reason to switch to Thunderbird. Currently I have to open the files in the editor again to see who it came from.
It's a serious mistake for me, precisely because it was integrated. A special feature compared to other providers. I'm wondering why it's not an integral part of Thunderbird, but only provided as an add-on.
I ask for correction.
Otherwise, I'll ask the question about an alternative product here.

Comment 27

[:filigrana]

I'm not a big supporter of extensions, I only use confirmbeforedelete and when it will be deactivated I will use plain TB...
I don't use TB's anti-spam filters to avoid having false positives and I manage, among others, 3 mailboxes without anti-spam...
after using forte agent for several years, I switched to TB and I always wondered why (unlike agent) you couldn't view the sender's mailbox in the message list panel...
lately a phishing email made me think, because it was done so well that I almost clicked on the fraudulent box... going to see the sender's mailbox, I noticed that it was a fake mailbox and so I went to the trash can to check the situation. ..
well, I have 1930 messages in there, of which 296 are unopened and 1634 are open; the first message is from July 2022, which means that in 16 months I had to open 1624 emails to understand whether they were spam/phishing or not...
of these 1624 emails, I would say that 99% have a completely fake sender mailbox and, having been able to view it in the message list panel, I would have discarded 99% of those 1624 emails without opening them.
in my opinion, the phenomenon of phishing and spam has reached such levels, including qualitative ones, that (in addition to the anti-spam filters which not everyone uses, as in my case) it is essential to also be able to view the sender's mailbox in the message list and this, unfortunately, it can no longer be delegated to some wonky extensions, no offense, which work today and are deactivated tomorrow...
it is a security and privacy problem that must be addressed within the TB, moreover also with a simple option within the choice of columns viewable in the message list header bar (sender's mailbox or sender email address) which has been waiting to be rightly introduced for 20 years ...

Comment 28

[[:thunderbird64bit]]

I confirm this problem: Only the "display name" is shown

Comment 29

[rthx]

Hello Mozilla, wake up!

This is not a simple enhancement but a security function!

And this must be implemented directly in Thunderbird and not left to some ad-on.
Mozilla has been shirking its responsibility for 20 years!!!

Comment 30

[JohannesS]

I also want to have this feature!!
it should be default behavior for your claim to make internet safer!

Johannes

Comment 31

[JohannesS]

(In reply to JohannesS from comment #30)

I also want to have this feature!!
it should be default behavior for your claim to make internet safer!

Johannes

I also do not understand why

1. there has been a necessity to develop an addon "full address column" at all.
2. why development of TB is made in a way that a crucial and already existing addon is not possible to be made working again
3. again, why is this not a basic intrinsic feature of TB?

Nevertheless: thank you for developing a very important product!

:-)

Comment 32

[John Bieling (:TbSync)]

(In reply to JohannesS from comment #31)

I also do not understand why

1. there has been a necessity to develop an addon "full address column" at all.

Thunderbird is an open source software, those working on it implement the things they think are important. Nobody picked up this bug. After an add-on developer released the mentioned add-on, there was no pressure at all anymore to work on this bug. It sounds strange, but that is how it is.

After the Thunderbird Council increased donation campaigns and was able to collect more finances, MZLA was created, and developers were hired to work on Thunderbird. This team has roadmaps and plans to figure out what should be worked on. This bug was not on the agenda during the planing phase of 115, because there was an add-on.

2. why development of TB is made in a way that a crucial and already existing addon is not possible to be made working again

Legacy-style add-ons do not use the stable WebExtension Interface (which is tested), but hook directly into the source code of Thunderbird. We are working on increasing the available WebExtension APIs. There currently is not yet an API to manipulate the columns.

There are no tests for legacy-styled add-ons, and we missed, that the changes in 115 break the ability of legacy-style add-ons to manipulate the columns. We know that TB updates can break add-ons, and usually add-on developers can work around these changes (and we help them to make these adjustments). Not in this case.

I am confident, that we can provide ways to manipulate columns for add-on developers in 115.6, released before the end of the year.

I will try to raise awareness of this bug in the current team, to implement a native solution.

Comment 33

[:filigrana]

(In reply to John Bieling (:TbSync) from comment #32)

I will try to raise awareness of this bug in the current team, to implement a native solution.

well done, try to do a small awareness campaign within the team to bring the display of the sender email in the columns of the message list within the TB source code, because it solves a security and privacy vulnerability, which in the my opinion is critical...
20 years ago OP had seen far ahead and had already noticed the vulnerability, but today (unlike then) we all have all the online services, practically our whole life is online...we also have the washing machine, the shutter, the light bulb and the toaster online...
20 years ago emails arrived about penis enlargement and about some exotic slut who wanted friendship (you remember, right?), now you get emails from all your 150 online services dealing with login problems, password renewal, fraudulent use etc... clicking on a wrong email can cause serious damage...
Furthermore, I'm not a programmer, but adding one more column to the list of available columns seems like a pretty simple job to me, correct me if I'm wrong...

Comment 34

[lsr1]

Disclaimer: I have not read the whole thread (also first time poster).

Apologies if this is against the etiquette, but I just wanted to also bump this bug. This has infuriated me ever since - the fact that an EMAIL program does not natively display an EMAIL address of a sender is beyond comprehensible (I would really like to know what "arguments" were used when removing this feature in the first place; which made an addon necessary). I'm not talking about the addon thing (that in itself is infuriating too), but again - an EMAIL program needs to display the freaking EMAIL address for heavens sake.

Many thanks for fixing this - it is very much appreciated.

Comment 35

[Bianca Rodel]

I understand the history of how this topic developed and how we landed here. I would prefer a solution that implements a "show real email address" column as a default to Thudnerbird from now and foreever rather than to need an addon. But for me as a user at the end I need this safety feature regardless of how it is installed. So whatever you do please enable me to get columnds that show both, the sender address and the recepient address.

Comment 36

[jan]

(In reply to John Bieling (:TbSync) from comment #32)
Thank you for this explanation, it makes things much clearer and takes away quite a bit of the annoyances. I'm looking forward to version 115.6. Please keep us posted!

Comment 37

[JohannesS]

(In reply to John Bieling (:TbSync) from comment #32)

(In reply to JohannesS from comment #31)

I also do not understand why

<snip>

thank you John for shedding light on this topic. Hopefully this feature can be implemented quickly. TB can use (and definitely should do so) this feature as a USP then and thus keep the pressure up on other mailing programs to do the same....

Jo

Comment 38

[Simon Wilks]

(In reply to filigrana from comment #33)

Furthermore, I'm not a programmer, but adding one more column to the list of available columns seems like a pretty simple job to me, correct me if I'm wrong...

It's not even one more column that's required. All that's needed is an option/default that displays the senders address in the "From" column, as was once traditional and remains intuitive, rather than whatever alias the sender (or their email client) would prefer you to see. That wouldn't just be useful for spotting spam, but also for distinguishing all those who seem to think they're the only John Smith in the world.

I'd like the "To" column to behave similarly, too, but I guess that will count as a separate issue.

Comment 39

[:filigrana]

don't ask too much...it took them 20 years (maybe) to put the mailbox in the From: field, if they decide to merge the To: field too it will take them another 20 years to complete both haha...

Comment 40

[richardandrewkean2008]

Inbox display of the Sender's email domain name would help us quickly determine whether to Open or Trash.
It might help remind us of the From name's Email Domain.
We also wouldn't have to Open an email From a sender that we didn't recognise in order to check the Email address before trashing.
20 years without the option says a lot I guess.
Seems like a very advantageous display option.

Comment 41

[Johny Bugs]

(In reply to John Bieling (:TbSync) from comment #32)

I am confident, that we can provide ways to manipulate columns for add-on developers in 115.6, released before the end of the year.

I will try to raise awareness of this bug in the current team, to implement a native solution.

Thank you for your effort. In the meantime 115.6 was released . Unfortunately no column header fix is mentioned in the release notes https://www.thunderbird.net/en-US/thunderbird/115.6.0/releasenotes/. Any update? Like a lot of people we're all looking forward anxiously.

Comment 42

[M]

Request for actual email address to be a field option for columns to display.

I used to use an add-on that allowed that, but it no longer works. When I'm trying to determine whether an email came from the marketing arm of a company vs a legit email from them, this is crucial. Please push up higher on to-do list if possible.

Thank you!

Comment 43

[bugzilla.domain.gauner]

I agree, to not have this feature is total no-go, and absolutely disappoints me from mozilla!
I also ask: What sense does it make, to NOT enable the user so see the sender's adresses in the list?

Comment 44

[JohannesS]

is there anyone here to tell us the actual status of this feature? As it didn't make it into 115.6 - what are current plans so far? It would be nice to know - and -again- I would use the existing of this feature as a very heavy marketing USP item and prepare not only the feature itself but also the adjacent advertisement campaign to tell everyone that there is something unique available in TB.
Also raising money should be easier with such a point in communication! I definitely will make an additional donation once this is available ;-)
These two points should rise the priority of developing that feature alone!

So in my eyes: all set - go!

Thank you for your work!!

Jo

Comment 45

[JohannesS]

BTW:
How many cases from TB starting times 2003 are still open or reopened again?
Also another point to realize this feature: Finally especially for the 20th anniversary we proudly present a long-awaited feature.....

:-)

jo

Comment 46

[JohannesS]

(In reply to Simon Wilks from comment #38)

(In reply to filigrana from comment #33)

Furthermore, I'm not a programmer, but adding one more column to the list of available columns seems like a pretty simple job to me, correct me if I'm wrong...

It's not even one more column that's required. All that's needed is an option/default that displays the senders address in the "From" column, as was once traditional and remains intuitive, rather than whatever alias the sender (or their email client) would prefer you to see. That wouldn't just be useful for spotting spam, but also for distinguishing all those who seem to think they're the only John Smith in the world.

I'd like the "To" column to behave similarly, too, but I guess that will count as a separate issue.

I think this is a important post here in this discussion! this could make the implementation somewhat easier and lead to the same result!

Thank you Simon for mentioning the obvious...

Jo

Comment 47

[M]

(In reply to JohannesS from comment #44)

is there anyone here to tell us the actual status of this feature? As it didn't make it into 115.6 - what are current plans so far? It would be nice to know - and -again- I would use the existing of this feature as a very heavy marketing USP item and prepare not only the feature itself but also the adjacent advertisement campaign to tell everyone that there is something unique available in TB.
Also raising money should be easier with such a point in communication! I definitely will make an additional donation once this is available ;-)
These two points should rise the priority of developing that feature alone!

So in my eyes: all set - go!

Thank you for your work!!

Jo

I will make a donation in advance if they'll promise to add the feature soon!

Comment 48

[Ed]

(In reply to JohannesS from comment #44)

is there anyone here to tell us the actual status of this feature? As it didn't make it into 115.6 - what are current plans so far? It would be nice to know - and -again- I would use the existing of this feature as a very heavy marketing USP item and prepare not only the feature itself but also the adjacent advertisement campaign to tell everyone that there is something unique available in TB.
Also raising money should be easier with such a point in communication! I definitely will make an additional donation once this is available ;-)
These two points should rise the priority of developing that feature alone!

So in my eyes: all set - go!

Thank you for your work!!

Jo

If you had read the whole thread, you'd have seen https://bugzilla.mozilla.org/show_bug.cgi?id=243258#c32.

Comment 49

[JohannesS]

(In reply to Ed from comment #48)

(In reply to JohannesS from comment #44)

is there anyone here to tell us the actual status of this feature? As it didn't make it into 115.6 - what are current plans so far? It would be nice to <snip>

If you had read the whole thread, you'd have seen https://bugzilla.mozilla.org/show_bug.cgi?id=243258#c32.

I do have read this comment (as you could see from my comment #37 ;-) ) but i lack knowledge about the organizations behind the development and their connection to this conversation. And this orga is not explained here. So i do not know if the developers read this or how our input here gets back to the developers. So in my eyes my quest is legitimate and does not require a kind of rebuke.
Thank you Ed

Comment 50

[ncv34869]

20 Years. 20 years later, a basic security function to efficiently counter phishing or dangerous mails still not native implanted.
How many people victim of these since. And the last major version even killed the only extension addon able to do it.

"As part of the Mozilla family you can be confident we always put your privacy and security first."
What a way to be a paragon of security.

Comment 51

[Ed]

(In reply to JohannesS from comment #49)
So in my eyes my quest is legitimate and does not require a kind of rebuke.

You are right; I was out of line. I apologize.

Comment 52

[Robert]

I think everything has already been said here about this bug. Unfortunately the bug has not yet been corrected. Therefore, I have now downgraded to Thunderbird 102.15.1 and disabled the update. And now I hope.

Comment 53

[Matthew Stapleton]

Attachment: thunderbird_show_email_addresses_in_email_columns.patch

I'm not a Mozilla developer , but here is an early patch I've written which I think adds support for this feature. It still needs some tuning in the Settings, General section and updating the columns when the setting is enabled/disabled, but when enabled it looks like it is displaying the email addresses in the From, Recipient, and Correspondents. If mail.showCondensedAddresses is set to true, that will still override this setting for email addresses in your Address Book.

Comment 54

[Matthew Stapleton]

Attachment: thunderbird_show_email_addresses_in_email_columns_rev_2.patch

Here is revision 2 of the patch. It fixes the Settings section, but updating the columns when the showEmailAddresses setting is changed still isn't working.

Comment 55

[Matthew Stapleton]

Attachment: thunderbird_show_email_addresses_in_email_columns_rev_3.patch

Here is revision 3 of the patch which fixes updating the columns when the showEmailAddresses setting is changed.

Comment 56

[:filigrana]

thank you for your job...
sorry for the stupid question but..........how do we apply the patch?

Comment 57

[Matthew Stapleton]

I'm using Gentoo Linux where most packages are compiled from source and they make it fairly straight forward to modify packages to apply custom patches. Hopefully the Mozilla devs will be able to apply a form of this patch to the main Thunderbird code so then it can be picked up by all Linux distros and other operating systems as well.

I also found this, https://developer.thunderbird.net/thunderbird-development/getting-started , but so far I've only created the patch based on a release version of Thunderbird and not on the Mercurial code repository.

Comment 58

[Matthew Stapleton]

(In reply to filigrana from comment #56)

thank you for your job...
sorry for the stupid question but..........how do we apply the patch?

Oh here is a basic example using the source code release although I'm not familiar with compiling and installing Thunderbird direct from source as I used the Gentoo package to compile:
Download and extract https://archive.mozilla.org/pub/thunderbird/releases/115.6.0/source/thunderbird-115.6.0.source.tar.xz
Download thunderbird_show_email_addresses_in_email_columns_rev_3.patch
cd thunderbird-115.6.0
patch -p1 < ../thunderbird_show_email_addresses_in_email_columns_rev_3.patch

Then hopefully following the build instructions at https://developer.thunderbird.net/thunderbird-development/getting-started will result in a patched build. On deb or rpm based Linux systems , modifying the source versions of those packages and then rebuilding should be fairly straight forward as well.

Comment 59

[:filigrana]

thanks for the explanation, I am truly moved by your dedication during the holidays and if this patch is implemented you will have the thanks of millions of TB users...
unfortunately I and many other users who have written are on windows and we will have to wait for the implementation of the patch on the next versions of TB, hopefully soon...

Comment 60

[foxbird]

(In reply to Matthew Stapleton from comment #55)

Created attachment 9370250 [details] [diff] [review]
thunderbird_show_email_addresses_in_email_columns_rev_3.patch

Here is revision 3 of the patch which fixes updating the columns when the showEmailAddresses setting is changed.

Thank you so much for your work! I really hope TB developers will implement it with version 116, it is such an essential feature!
(Then I would update my TB102 with which I stay for the zime being.)

Comment 61

[foxbird]

(In reply to rthx from comment #29)

Hello Mozilla, wake up!

This is not a simple enhancement but a security function!

And this must be implemented directly in Thunderbird and not left to some ad-on.
Mozilla has been shirking its responsibility for 20 years!!!

I agree!

Comment 62

[Mista]

Please fix that immediately!

Comment 63

[Claudia]

I am not sure if there will be a senders adress column soon - but please hurry - for safetyness it is really importend to have this back :)

As you can read here - many users are annoyed that the extension doesn't work anymore, because you forbid custom columns?
This should be a default in-build feature for all users, secure us the better way!
https://connect.mozilla.org/t5/ideas/new-column-for-e-mail-address-of-sender/idc-p/48037#M27988

Comment 64

[Claudia]

PS - I forgot to mention -> FOR WINDOWS Please!!!

Comment 65

[Trini Trit]

(In reply to Claudia from comment #64)

PS - I forgot to mention -> FOR WINDOWS Please!!!

YES! Full support.
FOR WINDOWS, please!

And all reasons above and in the discussion for >> https://connect.mozilla.org/t5/ideas/new-column-for-e-mail-address-of-sender/idc-p/48037#M27988.

It would be great if this could be addressed with some form of immediacy, since it is a security gap.

Many thanks!

Comment 66

[Trini Trit]

(In reply to John Bieling (:TbSync) from comment #14)

Please try to not mix bugs. The bug regarding the add-on issue is Bug 1817682. And we are working on it.

Thank you. That's awesome.

Comment 67

[Ralf]

Based on the actual behavior (Release Version 115) Thunderbird is designed as unsecure and not save for production! (Windows)

It's now a mailclient for the SPAM and VIRUS Industry, think about it!

Comment 68

[Johny Bugs]

(In reply to John Bieling (:TbSync) from comment #32)

I am confident, that we can provide ways to manipulate columns for add-on developers in 115.6, released before the end of the year.

I will try to raise awareness of this bug in the current team, to implement a native solution.

Thank you for your effort. In the meantime not only 115.6 was released, but 115.7 as well. Unfortunately in the release notes https://www.thunderbird.net/en-US/thunderbird/115.7.0/releasenotes/, nothing is mentioned about manipulating columns for add-ons (Bug 1817682), although there seems to be a work around for Linux (by Mathew Stapleton). Nor is there mention of implementing a native solution column header fix is mentioned (this bug).

Any update?
PLEASE inform us.
Like a lot of people we're all looking forward anxiously.

Comment 69

[John Bieling (:TbSync)]

The patch for Bug 1817682 was still in review till yesterday: https://phabricator.services.mozilla.com/D179632 and now can move forward.

That patch and therefore its status is linked in Bug 1817682.

I hope to get it to land soon.

Comment 70

[foxbird]

Thank you so much for your work. I'm eagerly looking forward to your addon to be functional again.
Though, actually, it should not be neccessary to have an addon for that, the feature should rather be inbuilt. But, sadly, I lost my hope for that to happen...

Comment 71

[Jordan]

Thank you, John Bieling!

Comment 72

[Johny Bugs]

(In reply to John Bieling (:TbSync) from comment #69)
Thank you for the update and the great work!
Hope 'soon' will be next month for Bug 1817682 en in 122 to be native (comment #32)

Comment 73

[:filigrana]

(In reply to John Bieling (:TbSync) from comment #69)

The patch for Bug 1817682 was still in review till yesterday: https://phabricator.services.mozilla.com/D179632 and now can move forward.

I see that the work around bug 1817682 regarding addons is progressing well, well done!
here we are stuck, despite 72 rather harsh comments and 20 years of waiting, the bug hasn't even been assigned.
there are reasons that even a one year old child would understand are essential to insert the display of the mail address in the message list natively within the TB, regardless of any addon even if it had been programmed by the Pope in person...
among other things, in the Thunderbird Beta Notes of 122 which we can read here https://www.thunderbird.net/en-US/thunderbird/122.0beta/releasenotes/?utm_content=header&utm_source=thunderbird.net&utm_medium=fru&utm_campaign=donation_2023 there is no reference to fixing bug 243258, should we wait for version 581?
I am very disappointed...

Comment 74

[bugzillanov]

Bug 1817682 relates to other addons creating own columns as well (e.g. XNOTE), so there's a chance this bug will be delivered in a short time (I hope...).

Implementing new functions in native TB seems to be a longer process - even then, no one knows if such enhancements may be removed in a future release, so better a (Thunder-)bird in the hand as two in the bush ;-)

Comment 75

[bugzilla.domain.gauner]

(In reply to bugzillanov from comment #74)

no one knows if such enhancements may be removed in a future release

...which is sadly even more valid for addon compatibility... :-(
So, I'd consider an implemented feature more future proof that an addon, which depends on the good will of the thunderbird developers too and on the good will of the addon programmer.

Comment 76

[:filigrana]

(In reply to bugzilla.domain.gauner from comment #75)

...which is sadly even more valid for addon compatibility... :-(

your words are holy...
I no longer rely on TB addons.
every time I used one, it was deactivated after a few TB upgrades, the programmers took months and months to restore it and often abandoned the project...

Comment 77

[Ralf]

(In reply to :filigrana from comment #76)

(In reply to bugzilla.domain.gauner from comment #75)

...which is sadly even more valid for addon compatibility... :-(

your words are holy...
I no longer rely on TB addons.
every time I used one, it was deactivated after a few TB upgrades, the programmers took months and months to restore it and often abandoned the project...

That's the point why i stop updating any[!] Mozilla Software (firefox+thunderbird).
I can't invest days after days, just to find out, that someone is generating (NEW) security bugs or is blocking my workflow with a new GUI idea.
Acutally no virus or zero-day-problem can make me more problems than the "optimizations" in the past.

Comment 78

[Mista]

Next update is there, but still no fix!
Ridiculous!

Comment 79

[bugzillanov]

Thought about buying Outlook as the real sender's address can be made visible (did it in Outlook at work).
Now I changed to Betterbird and got it out of the box.

TB was an option when there were many working addons replenishing missing functions in the base.
It seems, these days are gone.

Comment 80

[github-ha-reporting2023]

I came here again, because 2 of my users got bitten in a phishing attempt.

As it stands TB is no better than the build-in Apple Mail client on a IOS devices that also insists on hiding the real email address.

The functionality of showing the full email address should not even be transferred to an Add-on.
This is basic functionality of an email client, much more than anything else added to TB in recent times.

Comment 81

[:filigrana]

some of you Americans who are near mountain view CA please chain yourself to the gates of the headquarters for a couple of hours so maybe we can make them understand haha...

Comment 82

[:filigrana]

any news from the supreme minds?

Comment 83

[[e-mail]]

Did our unkindness provoke a childish defiance? I actually assume that the concern expressed here should be an absolute data protection matter of course and that it would be easy to present genuine technical information such as an email sender as such. I do not understand Thunderbird's inaction and have stopped all donations to Mozilla. I currently no longer recommend Mozilla products to anyone other than my family.

Comment 84

[rthx]

I also absolutely cannot understand why this is not being implemented.
This is about data protection and not about some cosmetic problem!
It really can't be that difficult to implement.

Maybe it's childish defiance like the previous poster said?

Comment 85

[Carabaot]

Sorry to say that but I agree regarding the not understanding why this gets not implemented.
I asked again and again since months why not or when it will be implemented. But nothing happens until now.
I just can't understand that.
And yes - From my point of view this is also a security issue. And security should be one of the most important things to take care of.

Comment 86

[Wayne Mery (:wsmwk)]

The tone, substance and disregard for the bugzilla etiquette guidelines of recent comments here is unacceptable for a professional working environment, which include but are not limited to https://bugzilla.mozilla.org/page.cgi?id=etiquette.html. (And if you comment similarly in other bugs there will be consequences.) And they are not offering to contribute to resolving this issue, which is ultimately what bugzilla is about. So I reluctantly take the step of restricting further comments. Alternatively, you can submit and vote for issues at https://connect.mozilla.org/, subject to the similar guidelines.

Sorry to impact those of you who have behaved well.

Comment 87

[Alessandro Castellani [:aleca]]

Attachment: Bug 243258 - Add a preference to always show the full name and email address for recipients in the message list. r=BenC,mkmelin,leftmostcat,ikey

Comment 88

[Alessandro Castellani [:aleca]]

Time to fix this! 🚀

Comment 89

[Alessandro Castellani [:aleca]]

Increasing the Priority so this will land and be available for next ESR.

Comment 90

[Magnus Melin [:mkmelin]]

Bug 697031 seems like a duplicate.

Comment 92

[Wayne Mery (:wsmwk)]

Broader technical discussion in progress at https://thunderbird.topicbox.com/groups/planning/T0693b2fe630fea8e-M97606b1f6866e19c69ff4994

Comment 93

[Richard Leger]

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

Broader technical discussion in progress at https://thunderbird.topicbox.com/groups/planning/T0693b2fe630fea8e-M97606b1f6866e19c69ff4994

As suggested in the group... https://thunderbird.topicbox.com/groups/planning/T0693b2fe630fea8e-Mc995a512502183158bff408c/20-years-old-bug-show-expanded-address-vs-condensed

If default become: Full Name <email>

• In the UI the Full Name could also be emphasize and email address made more discreet to focus attention on the Full Name (primary info) rather than email address (secondary info). This may allow for a less "heavy" UI perhaps.

• the Full Name + Email address may be less intrusive in the UI if it was placed under the message Subject rather than above, in the Message List in a similar way Topixbox does with the discussion lists. This may help distinguish multiple messages received from the same Sender as what differs between messages would then appear first.

Subject
Full Name <email> <-- Full Name could be in a different color...

...instead of currently...

Full Name <email>
Subject

Comment 94

[Ben Bucksch (:BenB)]

For senders that are in the user's address books (including Collected Addresses), show only the full name, as set in the address book. For unknown senders, show the email address. What's most important is the second-level domain of the email address, because that's the security anchor.

There is a very important security reason for this: Phishing is one of the biggest security threats today. Phishing is based entirely on the reader (our user) being confused about the origin/sender of the email. If anything, the sender domain needs to be more prominent than it is now, not less. Many of the most famous and disastrous hacks have started with email phishing: The hack of Bundestag, the German parliament, which effectively destroyed their entire IT infrastructure, after having been spied upon. IIRC even the most recent hack of Microsoft where hackers could read the US government emails, started with hacking one Microsoft employee, IIRC by email phishing, and then elevated from there. Email phishing is one of the biggest security threats that companies face today.

And they are all based on this simple confusion of who sent the message. All email clients should rather make the second-level domain of the sender much stronger than the real name, because the domain is the only bit of information that can not be forged (if DKIM/SPF is in place).

Maybe the idea to make the second level domain more prominent might allow to hide the other email address parts and might make it look nicer and more secure.

Comment 95

[Alessandro Castellani [:aleca]]

(In reply to Richard Leger from comment #93)

• In the UI the Full Name could also be emphasize and email address made more discreet to focus attention on the Full Name (primary info) rather than email address (secondary info). This may allow for a less "heavy" UI perhaps.

I wouldn't do that as doing so kinda goes against the security reasons for implementing this feature.
The email address + domain is what distinguish a good/real sender from a bad one, so ed-emphasizing that visually would make it stand out less.

I'm okay with exploring other UI improvements but not in this bug, better to keep this narrow and focused on this pref and default implementation.

(In reply to Ben Bucksch (:BenB) from comment #94)

For senders that are in the user's address books (including Collected Addresses), show only the full name, as set in the address book. For unknown senders, show the email address. What's most important is the second-level domain of the email address, because that's the security anchor.

Yes, that's exactly what my patch is doing and I thin kit defines a clear visual separation between known and unknown senders.

In the future, we want to explore a more "clear" way to show an address saved in address book against one that it's known but it was dynamically collected. But this is all future exploration to improve UI.

Anyone had the chance to try the patch I attached?

Comment 96

[Yury]

A few drive-by comments:

As Magnus pointed out, this is primarily not about the recipient address display, but about the sender address display. Would you consider changing the pref to mail.addressDisplayFormat?

In this case the variable names in this code should be changed accordingly:

static nsString GetSenderFullAddress(const nsString& name,
                                     const nsACString& emailAddress) {
  int32_t recipientsDisplayFormat = 0;
  nsCOMPtr<nsIPrefBranch> prefs(do_GetService(NS_PREFSERVICE_CONTRACTID));
  prefs->GetIntPref("mail.recipientsDisplayFormat", &recipientsDisplayFormat);

You can use mozilla::Preferences::GetInt() to get the preference value, see examples here:
https://searchfox.org/comm-central/search?q=mozilla%3A%3APreferences%3A%3AGetInt&path=&case=false&regexp=false

If you change the pref name, please consider also changing the string names in the Fluent files: address-display-legend, address-display-description, etc.

Comment 97

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/567573fb06ab
Add a preference to always show the full name and email address for recipients in the message list. r=BenC,mkmelin,leftmostcat,ikey

Comment 98

[Andrei Hajdukewycz [:sancus]]

Based on the previous comments, the old behaviour should still(by default, if the checkbox is checked) function for "Collected Addresses" but it definitely does not. It only functions for emails in "Personal Address Book". Assuming I only have those two address books and no others.

Comment 99

[Andrei Hajdukewycz [:sancus]]

On further investigation, the issue is the "Prefer display name over message header" preference for each contact. Testing on a new contact, it is defaulted to OFF when added to Collected Addresses, even in current Daily.

I guess this patch now respects that pref properly when the code did not before, however due to the above behaviour many profiles are going to have an address book full of improperly configured contacts that will change the observed behaviour.

Comment 100

[chrizilla]

(In reply to Alessandro Castellani [:aleca] from comment #95)

a clear visual separation between known and unknown senders. In the future, we want to explore a more "clear" way to show an address saved in address book against one that it's known but it was dynamically collected.

I am offering an enhancement idea in bug 1899005 : add the existing gray/blue/(yellow) status icon to message list

Comment 101

[chrizilla]

Removed.
My apologies, I thought this would fit here.

Comment 102

[Alessandro Castellani [:aleca]]

Thanks for your participation and passion, but please remember that bugzilla is not a mailing list and these kind of discussion should happen in those specific channels.
Bugzilla is only for bug and code discussion.