User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/600.1.17 (KHTML, like Gecko) Version/7.1 Safari/537.85.10 Steps to reproduce: Send an e-mail to --- example@example.com;<own address> --- Actual results: To: field appears as --- "example"@example.com;<own address> --- (Note double quotation marks.) Expected results: Recipients should be --- example@example.com;<own address> --- (No extra punctuation.) This appears to be new behaviour; I upgraded a week or so ago (to 31.2.0, I think from 31.0.something, although I'm not sure), and the behaviour started then.

That is the message I received when testing for the bug. Notice that I really received it, so that is just a problem of the text being shown, not the headers itselves.

Semicolons are not a proper way to separate email addresses, per RFC 2822. You need to use commas to separate a list of email addresses. (Semicolons are used for groups, but in this case, Thunderbird is interpreting the semicolon as part of the local-part of an email address and wrapping it with quotes to make it syntactically-valid.) If you're not the one sending these messages, I suggest letting that person know that they're doing it wrong.

My experience is different to that of Javi Rueda; my copy of Thunderbird is mangling the address to --- "example"@example.com;myaddress@mydomain.com --- , not to --- "example@example.com;myaddress"@mydomain.com --- . Anyway, I understand now why I should not be writing semicolon-separated lists, but it's an ingrained habit, especially since Thunderbird did not always behave this way. (For example, I just tested, and 24.8.1 didn't.) Is there any setting somewhere in about:config that will stop it from doing this, or at least have it ask for confirmation when it is about to do so?

There are probably improvements that could be made to validate the syntax of an address list before sending, but the main reason this changed is that I believe 31 was the first version to use jcranmer's new JS MIME code (which should fix a lot of longstanding issues when it's completely finished) for headers. Joshua: Any ideas on things we can do here to make users aware when they compose mail with incorrect addressing syntax? Silently converting it to correct syntax probably only makes sense when we know for sure what the intended meaning is...

(In reply to Jim Porter (:squib) from comment #4) > Joshua: Any ideas on things we can do here to make users aware when they > compose mail with incorrect addressing syntax? Silently converting it to > correct syntax probably only makes sense when we know for sure what the > intended meaning is... The best option is to do UI-level validation of email addresses and reject weird ones outright.