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.
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
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.
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.)
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.
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.