Bug 320968

Summary:	Unknown shown in Sender TO and CC fields instead of names
Product:	[Applications] kmail2	Reporter:	Emre <erenoglu>
Component:	message list	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED UNMAINTAINED
Severity:	major	CC:	montel
Priority:	NOR
Version:	4.10.3
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Emre 2013-06-09 19:27:54 UTC

I'm using kmail2 with local IMAP server which has my archives (Dovecot). 
I can see that some of the "sent messages" are not showing headers correctly. There are no names or addresses listed in the TO, FROM and CC fields in the message preview pane.
When I look into the message source, I can properly see those fields and the names. 
Note that the server is Exchange. Therefore, not all recepient/sender names have "email addresses" appended to them. Sometimes, there's only names. 
For example, in an email that I see with "Unknown" as sender name and no names shown in headers in preview pane, if I look at the source of the message, I can see:

Status: RO
From: "ERENOGLU, EMRE (EMRE)" <MAILER-DAEMON>
Subject: About our meeting
To: SURNAME, NAME (NAME)
Date: Sun, 30 Dec 2012 20:12:11 +0000

or another one:
Status: RO
From: "ERENOGLU, EMRE (EMRE)" <MAILER-DAEMON>
Subject: RE: Other topic
To: Surname1, Name1 (Name1); Surname2, Name2 (Name2)
Cc: Surname4, Name4 (Name4); Surname3, Name3 (Name3)

Reproducible: Always

Actual Results:  
Unknown is shown although the headers seen in message source contain names.

Expected Results:  
Show correct names in the headers

Not all messages are like this. For example, this one (message source) shows correctly:

From: Emre Erenoglu <emre.e@mycompany.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
To: "Surname1, Name1 (Name1)" <name1.surname1@company.com>
CC: "Surname2, Name2 (Name2)" <name2.surname2@company.com>

Note that there are no local or LDAP addressbooks configured in this system.

Comment 1 Emre 2013-06-09 19:29:46 UTC

I've also checked the inbox folders now. It seems all messages actually contain an email address (someone@something.com etc.) along with their names. Outbox mails don't always contain these, but still contain the names.

Comment 2 Laurent Montel 2013-06-11 05:58:44 UTC

We expect parsing real email not just name in CC/To/ etc.

Comment 3 Emre 2013-06-11 08:05:04 UTC

I checked from Thunderbird and Evolution EWS. Indeed the message source shows the same information, no email address, only name for those messages. However, both of them show the name as is so no problem.

Comment 4 Emre 2013-06-11 08:27:33 UTC

(In reply to comment #3)
> I checked from Thunderbird and Evolution EWS. Indeed the message source
> shows the same information, no email address, only name for those messages.
> However, both of them show the name as is so no problem.

OK, I analysed the situation a bit more. 
First of all, all mails sent from Android Activesync, from Exchange EWS, Exchange MAPI, or Exchange SMTP properly show the email mail address in the headers. 

so it seems the issue surfaced when I imported my outlook PST's into my IMAP server, through Thunderbird's "ImportExportPlugin" add-on and using readpst to extract Outlook PST files into importable format (maildir I think). Somehow, the imported Sent items do not contain the mail address of the sender in the Sent mailbox. I will dig into this with the importexportplugin add-on and readpst.

So as a conclusion, we can mark this bug as a "feature request", where Kmail can show the sender name even if there's no email address in the From: field in the headers. This is the behavior equal to what Thunderbird & Evolution does. (so that it does not at least show "Unknown")

Comment 5 Denis Kurz 2016-09-24 17:56:21 UTC

This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present?

If noone confirms this bug for a Framework-based version of kmail2 (version 5.0 or later, as part of KDE Applications 15.12 or later), it gets closed in about three months.

Comment 6 Denis Kurz 2017-01-07 21:37:36 UTC

Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.