Design issue Register with german umlaut in e-mail domain

[rhs]

Hi,

there is no registration possible if the Email adress has a german umlaut in the domain name:




The same Problem is with the IDN from this domain (info@xn--wrth-0ra.de as example).

 

[HWS]

Domains with special characters should generally not be used for e-mail. Most e-mail servers cannot handle such e-mail addresses and therefore many mails won't reach their receipients.

I don't know if this should be considered as a bug in Xenforo.

 

[rhs]

Most e-mail servers cannot handle such e-mail addresses

Then the relevant e-mail server are configured incorrectly ... But that is not the problem, the problem is a bug in XF.

 

[teletubbi]

Most e-mail servers cannot handle such e-mail addresses and therefore many mails won't reach their receipients.

This i don't belive.
Because this is a domain from a big company in germany.
So all their customers and suppliers had problems.

And if this would happen they had changed their domain already.

By the way i got emails from them as well.

 

[Mike]

The umlaut version being rejected is generally expected and not something I expect to change. By definition, it's not a valid domain name so it's not a valid email. That's where the punycode representation comes in.

However, the punycode version being rejected is a bug.

 

[Snog]

https://tools.ietf.org/html/rfc3490

May or may not apply here.

 

[rhs]

[...] and not something I expect to change

Why not? XF is used worldwide, you should not build artificial barriers ... .

However, the punycode version being rejected is a bug.

Ok.

 

[Xon]

https://tools.ietf.org/html/rfc3490

May or may not apply here.

As RFC3490 says:

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

Relevant email IDN RFCs: https://tools.ietf.org/html/rfc6531

It isn't well supported since you need quite recent versions of the email server software.

 

[Mike]

I'm going to confirm this for now, but I'm unsure what the resolution will be. In the email validation library (which is part of Zend Framework), the hostname validation converts the Punycode domain into the UTF-8 version before validating. We have explicitly disabled validation of the UTF-8 version (due to a previous bug report where this didn't work as an email target anyway). Annoyingly, this ends up disabling the Punycode version because of that conversion (and another check that would block it even without the conversion).

The realistic fix is to allow IDN validation, but ensure the email is always coerced to an the Punycode version before use/storage. This may not be something viable in the short term.

It's worth noting that the change that ended up disabling IDNs was made over a year ago. It doesn't seem like there's a huge demand for it.

 

[Mike]

As it stands, this isn't something that is going to be a simple fix with our email validation methods. If you or your users have run into this legitimately, then it would be useful to hear, but as it stands, it has only come up in a couple occasions.

As such, we're tagging this as a design issue. (Worth noting that it's a moot point in XF2 since we are using different email validation code.)

 

[Frank Ulmer]

I guess, we will into the same issues next year. Our global database will allow Umlaute in Mail-addresses within the next two or three month. All our forum members do need a company account. There is a internal script, which handles the registration process "outside" Xenforo by redirecting the registration. When our database accepts Umlaute, we will run into problems.

 

[HWS]

I would never recommend any company to use umlauts or special characters in e-mail addresses within the next years to come. Even if their own server can handle them. Because there are a lot of old e-mail servers out there installed which cannot handle special characters and won't accept and forward such messages. Using such characters in e-mail addresses makes e-mail messaging highly unreliable.