GNOME Bugzilla – Bug 343344
emails from (or to) addresses with periods in display name are incorrectly displayed
Last modified: 2009-04-27 18:43:28 UTC
Please describe the problem: I have an email with this header: From: Mr. Fred Smith <user@mail.com> In evolution, it shows up like this: From: Mr.FredS <mith user@mail.com> There are 2 space characters missing from the display name, 4 letters missing off the end of the display name, and 5 extra characters inside the <...> part. Section 4.1 of RFC 2822 ( http://tools.ietf.org/html/2822 ) says: Note: The "period" (or "full stop") character (".") in obs-phrase is not a form that was allowed in earlier versions of this or any other standard. Period (nor any other character from specials) was not allowed in phrase because it introduced a parsing difficulty distinguishing between phrases and portions of an addr-spec (see section 4.4). It appears here because the period character is currently used in many messages in the display-name portion of addresses, especially for initials in names, and therefore *must be interpreted properly*. In the future, period may appear in the regular syntax of phrase. (emphasis mine). Mr. Fred Smith should get his display name inside double quotes, but I have a lot of emails where display names containing periods are not inside double quotes. It would be good if evolution could make allowances for these questionably formatted emails and display them correctly. Steps to reproduce: Try reading a mail which has source like this: ------ From user@mail.com Fri Aug 20 11:11:11 2004 From: Mr. Fred Smith <user@mail.com> To: user@site.com Date: Fri, 20 Aug 2004 11:11:11 GMT Hello! ------ Notice that the From header is displayed incorrectly. Actual results: Expected results: Does this happen every time? Yes. Other information: It isn't just the "From" header which exhibits this problem. I've seen the same thing happen with "To" headers as well.
http://tools.ietf.org/html/2822#page-30 is a better link to the RFC, avoiding the need to scroll down to find the relevant section.
that's certainly an odd parsing of that address... anyways, confirmed the weird parsing.
*** Bug 354517 has been marked as a duplicate of this bug. ***
also see bug 347520
Might just as well fold this report into bug #347520, which actually was filed later, as that bug seems to describe the same problem. *** This bug has been marked as a duplicate of 347520 ***