Bug 134395 - Only first recipient is shown when I recieved a message with several "To:" in its header
Summary: Only first recipient is shown when I recieved a message with several "To:" in...
Status: RESOLVED FIXED
Alias: None
Product: kmail
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-20 15:12 UTC by MartinG
Modified: 2009-12-29 23:01 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description MartinG 2006-09-20 15:12:37 UTC 
Version:           unknown (using KDE 3.5.4-5.0.fc5.kde, Fedora Core release 5 (Bordeaux))
Compiler:          Target: i386-redhat-linux
OS:                Linux (i686) release 2.6.17-1.2187_FC5

I sometimes recieve messages that have several "To:" fields in it. I don't know is this is even valid, but it is little I can do about that. KMail will not show all "To:" addresses, but I wish it could.

Example header (excerpt):

From: Someone <someone@online.no>
To: <a@hotmail.com>
To: <b@hotmail.com>
To: <c@hotmail.com>
Subject: subject
Mime-Version: 1.0
Content-Type: multipart/mixed;
  boundary="----=_Part_7939_26721506.1158753662063"
X-Priority: 3 (Normal)
X-Mailer: Mobile Office v1.0 (Telenor Business Solutions)
Comment 1 Thomas McGuire 2009-05-12 01:14:46 UTC 
According to RFC 2822, section 3.6., "Field definitions", only 0 or 1 "To" header fields are allowed, not more.
Comment 2 MartinG 2009-05-12 09:27:33 UTC 
Ok, thanks. That means that the bug is in the "Mobile Office v1.0 (Telenor Business Solutions)", and I'm not surprised. So, I guess this can ble closed as INVALID.

(Although I am the reporter of this bug, I only have UNCONFIRMED, RESOLVED and NEEDINFO in my list of possible statuses, and RESOLVED is obviously not the correct resolution.)
Comment 3 Jonathan Marten 2009-05-12 10:26:54 UTC 
Wasn't this resolved a long time ago (in 3.5 branch and trunk), bug 80747?