THe new account wizard simply stops and suggest that the email address be chacked is the domain contains on ascii Characters.

The example offered in the support topic was träibatn.se I tried to set up an account only to find I was given what looked like a warning and then nothing but the cancel button appeared to do anything.

There is nothing in the error console, so there is no feedback to the user of what is wrong, except a bland message that a valid and recently registered address needs to be checked.

As support for internationalised domains was included in 2003 into Mozilla suite, I must assume this is some sort of error. But at the very minimum, it is not informative in the least.

Ben, have I missed something important here like a log I can access and view?

If we want to fix this, we would need to adapt the email syntax regexp. However, we cannot just allow all characters. We need to exclude special characters, all punctuation apart from "-" and ".", and take care not to otherwise regress the regexp. But that's too short-sighted:

When used as From: in mail, IDN can cause serious problems. In contrast, in the browser, the IDN affects only your browser. The browser translates it into an x--- punycode and resolves that, so no other software needs to be compatible. If we allow such email addresses with non-ASCII characters in the From: field of outgoing emails, then all email clients of that do not support IDN in email addresses will fail.

The end user will not get responses to his emails.

So, if we support this, when we would need to convert this into a punycode and send punycode as From: address, to ensure that replies arrive.

Similar bugs:

• Bug 1570263
• Bug 1563891
• Bug 1504526

Workaround: Enter the punycode.

Matt, as member of the community, you're expected to look for DUPs before you file a new bug.

I thought I did, I searched IDN, I searched l18n and I found nothing. But that is the biggest issue with Bugzilla. Lots of old bug with poor or esoteric descriptions where the user can spend a very long time finding anything. Then I read about puny code and then looked at a few likely bugs and those linked to them.

Given that some of Thunderbird strongholds are in nations where this is apparent in the language, I would have expected it fixed about a decade ago. I had also thought I would stumble upon a meta bug for such an important topic (IDN). Nope, we don't track that.

That does not negate that the error did not give the user a clue it is fatal. It is a poor user interface. I would have expected a red stop sign, but perhaps that is because I have been using windows for so long.

An information icon suggestion appears requesting the user check the email address. They did, it was correct.

Where is the explanation that Thunderbird does not think this is a valid email address and will not proceed with the setup.
For extra points where is the why it is not valid. Particularly relevant in the case of the guy that has a valid address, owns the domain and can send and receive email for outlook.com with it. In his case this is a valid email address. Validation of email addresses via regex has been fraught with issues for as long as there have been email addresses. If we are going to reduce the available addresses artificially because of some personal decisions, that has to be made crystal clear to the user.

I thought I did, I searched IDN, I searched l18n and I found nothing.

Thank you for checking.

Where is the explanation that Thunderbird does not think this is a valid email address and will not proceed with the setup.

It is the message that you see on the screenshot. I originally made it say "invalid email address" or something like that, and some UX guy changed it to "double-check the address" years ago. I didn't like that, but he thought that was more user-friendly. shrug

Something that's superficially nicer (like @müller.de), but harms interoperability and prevents receiving mail, is not necessarily "user-friendly".

If we are going to reduce the available addresses artificially because of some personal decisions, that has to be made crystal clear to the user.

Slow down with the "personal" and "artifical". IDNs violate the email standards as they were originally defined. We're just avoiding to send out things that are not widely supported, break other email clients, and are therefore dangerous to interoperability. See comment 1. Whereas the punycode works universally.