User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 Build Identifier: Version 2.0.0.9 (20071031) Thunderbird accepted umlauts (eg. special characters) as an part of email address localport. They are converted to the appropriate UTF8. RFC 2822 not allow codes greater then 127. Reproducible: Always Steps to Reproduce: 1. type mail address with special characters 2. press send butten 3. no error mail will send

Well, IDN support isn't available yet either - bug 127399. But I think you're correct. RFC 3490: Although IDNA enables the representation of non-ASCII characters in domain names, that does not imply that IDNA enables the representation of non-ASCII characters in other data types that are stored in domain names. For example, an email address local part is sometimes stored in a domain label (hostmaster@example.com would be represented as hostmaster.example.com in the RDATA field of an SOA record). IDNA does not update the existing email standards, which allow only ASCII characters in local parts. Therefore, unless the email standards are revised to invite the use of IDNA for local parts, a domain label that holds the local part of an email address SHOULD NOT begin with the ACE prefix, and even if it does, it is to be interpreted literally as a local part that happens to begin with the ACE prefix. Though if RFC 2822 ever gets updated, I imagine punycode for the local part would become allowed.

would like to see this stay open as a front end bug. please add dependencies as appropriate

I found this old bug while encountering this behaviour after an update of thunderbird to 38.0.1. I did not realize this problem before. I'm not sure if this is linked to the version update. Anyway, this is a real nuisance for German Users, which are working with an external Adressbook, as any Recipient with a normal name with Umlauts will break the sending process. As the mail is stuck in the outbox. Example of an affected email adress entry: Markus Müller <m.mueller@testhausen.de>