rfc2822 requires a folding whitespace (FWS).
closing as notabug.

That's true, but RFC 793 advises (and market forces require) that Internet software should be liberal in what it accepts from others. Of all the things "Canonical.com Patch Queue Manager<pqm@pqm.ubuntu.com>" could possibly mean, "Canonical.comP <atch Queue Managerpqm@pqm.ubuntu.com>" is not one of them. :-)

yea, this is just a bug. probably trivial to fix

Still reproducible in 2.22.3.

ok, so part of the problem is the Canonical.com - in fact, that might be sole cause of the problem.

The '.' causes confusion, but Camel's address parser is also quite clearly broken when it stumbles on that - it doesn't make sense that the P from "Patch" is split off and appended to Canonical.com as if it was part of the "com" word token.

as a workaround, you could probably get the sender to quote the name string.

(In reply to comment #5)
> [..] it doesn't make sense that the P from "Patch"
> is split off and appended to Canonical.com as if it was part of the "com" word
> token.

And also puzzling is the less symbol that got moved to a strange location. It might be what the parser thinks to be the location after the first (and only) non e-mail address token. (Using the parsing terminology loosely here.)

Altered the summary to make it reflect comment #5 and to make it slightly more general.

*** Bug 553004 has been marked as a duplicate of this bug. ***

*** Bug 547969 has been marked as a duplicate of this bug. ***

Created attachment 127800 [details] [review]
patch to generate silly standalone test app from camel-mime-utils.c

This patch generates a silly standalone test app I used to search for a solution. Compile with:
     gcc `pkg-config --cflags --libs glib-2.0 camel-1.2` 347520.c -o 347520

Example output:
./347520 "Canonical.com Patch Queue Manager <pqm@pqm.ubuntu.com>"

** (process:26838): WARNING **: We didn't get an '@' where we expected in 'Canonical.com Patch Queue Manager <pqm@pqm.ubuntu.com>', trying again

** (process:26838): WARNING **: Name is '<UNSET>', Addr is 'Canonical.com' we're at 'Patch Queue Manager <pqm@pqm.ubuntu.com>'


** (process:26838): WARNING **: We didn't get an '@' where we expected in 'Canonical.com Patch Queue Manager <pqm@pqm.ubuntu.com>', trying again

** (process:26838): WARNING **: Name is 'Canonical.comP', Addr is 'atch' we're at ' Queue Manager <pqm@pqm.ubuntu.com>'


** (process:26838): WARNING **: We didn't get an '@' where we expected in 'Canonical.com Patch Queue Manager <pqm@pqm.ubuntu.com>', trying again

** (process:26838): WARNING **: Name is 'Canonical.comP', Addr is 'atch Queue' we're at ' Manager <pqm@pqm.ubuntu.com>'


** (process:26838): WARNING **: We didn't get an '@' where we expected in 'Canonical.com Patch Queue Manager <pqm@pqm.ubuntu.com>', trying again

** (process:26838): WARNING **: Name is 'Canonical.comP', Addr is 'atch Queue Manager' we're at ' <pqm@pqm.ubuntu.com>'


** (process:26838): WARNING **: No local-part for email address: Canonical.com Patch Queue Manager <pqm@pqm.ubuntu.com>

** (process:26838): WARNING **: We didn't get an '@' where we expected in 'Canonical.com Patch Queue Manager <pqm@pqm.ubuntu.com>', trying again

** (process:26838): WARNING **: Name is 'Canonical.comP', Addr is 'atch Queue Manager ' we're at '<pqm@pqm.ubuntu.com>'

name: Canonical.comP
addr: atch Queue Manager pqm@pqm.ubuntu.com

Note that this doesn't hit the "Working around stupid mailer bug #5: unescaped characters in names" warning.

Created attachment 127802 [details] [review]
solution?

This could be a solution to this bug.

Example output:
./347520 "Canonical.com Patch Queue Manager <pqm@pqm.ubuntu.com>"

** (process:26941): WARNING **: Working around stupid mailer bug #5: unescaped characters in names
name: Canonical.com Patch Queue Manager
addr: pqm@pqm.ubuntu.com

I cannot say that I really understand the decoder (parser, whatever) that I am patching here. (The code is, well, not so easily grasped.)

Can anybody think of a regression that would be caused by this patch?

I see one little strangness, when you've a mail address like:
Mr. John D. Oe <john@nowhere.zz>
then the parser removes spaces after those dots. When you've this quoted it is shown as expected (which doesn't surprise).

Would you mind to extend your fix even for this?

(In reply to comment #13)
> I see one little strangeness, when you've a mail address like:
> Mr. John D. Oe <john@nowhere.zz>
> then the parser removes spaces after those dots.

Good catch.
 
> Would you mind to extend your fix even for this?

No, I wouldn't mind. We have to be careful here, since this will be a workaround for a workaround, won't it? We have to draw the line somewhere...

For example, the related bug #547969 - see comment #10 - might be a nice example of something we shouldn't try to fix. Superfluous dots in the address proper feel like something too broken to bother, doesn't it?

Paul, how is it going?

*** Bug 558477 has been marked as a duplicate of this bug. ***

*** Bug 503362 has been marked as a duplicate of this bug. ***

(In reply to comment #15)
> Paul, how is it going?

I seem to remember having poked at a solution (but having trouble to decide where to stop worrying about corner cases). Anyway, I hope to get back to this one of these days, as it would be a shame to go through all this trouble to make this parser easier to debug/understand/etc. without actually fixing this.

Please prod me again if this takes too long. 

Of course, I have little to complain about if someone fixes this while still I'm working on it ...

If it helps anyone, here's my personal test case I use to generate a good and a bad email for this bug. Run it from the command line, need to have command-line PHP installed, should all be on one line (bugzilla may mangle this), and obviously update the $my_email variable:

php -r '$my_email="nickpj@gmail.com"; mail($my_email, "test subject - broken", "message body", "From: y.our Webmaster <webmaster@whatever.com>"); mail($my_email, "test subject - works", "message body", "From: your Webmaster <webmaster@whatever.com>");'

*** Bug 343344 has been marked as a duplicate of this bug. ***

Happens to me with 2.26.2 also.

(In reply to comment #18)
> Please prod me again if this takes too long. 

Second attempt. :)

(In reply to comment #22)
> Second attempt. :)

0) Just played with my silly test program again. (The patch still applies to camel-mime-utils.c as shipped with evolution-data-server 2.29.2)

1) I was adding some horrific hack to keep all spaces before and after "unquoted" dots. Then I decided to test an address starting with a "unquoted" dot.
Current parser:
    ./347520 ".com Patch Queue Manager <pqm@pqm.ubuntu.com>"
    [...]
    name: .
    addr: com Patch Queue Manager pqm@pqm.ubuntu.com
Parser patched with the trivial patch of comment #12: 
    ./347520 ".com Patch Queue Manager <pqm@pqm.ubuntu.com>"
    [...]
    name: 
    addr: .com Patch Queue Manager pqm@pqm.ubuntu.com

So I don't think the patch of comment #12 helps much.

2) I think the trivial fix of comment #3 has still not been found.

3) If it turns out a trivial fix is not actually possible, it would probably be beneficial to have lists of:
- valid addresses;
- common invalid addresses;
all with their desired parsing into a "name" and an "addr" part (or something equivalent).

(And for myself, a better understanding of rfc2822 and the current parser would also be nice).

4) Related issue: how should evolution handle invalid addresses that cannot be sanitized? Should those invalid addresses be displayed "as is" in the header area but not be used at all in editors for replies?

*** Bug 617609 has been marked as a duplicate of this bug. ***

Created attachment 171944 [details] [review]
eds patch

for evolution-data-server;

Maybe not so smart, but it works. The tests seems to pass as well, and I added some for this thing too, thus the distcheck should spot any issue before release.
Feel free to add more formats/addresses to the test.

Created commit a27b2b0 in eds master (2.91.1+)
Created commit 92610ee in eds gnome-2-32 (2.32.1+)

I still reproduce the issue. Full name-> H. İbrahim Güngör  (attention to the "İ" character which is Turkish specific.)

You can read the test case here: bug #617609

evolution-data-server: 2.32.1
evolution: 2.32.1

(In reply to comment #27)
> evolution-data-server: 2.32.1
> evolution: 2.32.1

Please see the version information in comment 26 again.

(In reply to comment #28)
> (In reply to comment #27)
> > evolution-data-server: 2.32.1
> > evolution: 2.32.1
> 
> Please see the version information in comment 26 again.

Ah, sorry. Thanks

*** Bug 550787 has been marked as a duplicate of this bug. ***

*** Bug 559087 has been marked as a duplicate of this bug. ***