No reason to disable if it's allowed.

Maybe in some country it's used, or in some company .

Who know ?

A plugin can be great !

I have never seen this kind on internationalized email in use. And what's worse, it seems to break some MS email servers badly.

break some MS email

:D \o/ ;)

True, I would blame MS too. But in reality we just can't ignore MS, as it is currently so widely used.

PHPMailer supports IDN but not EAI, so we might want to at least force the local part to be ASCII only

PR: https://github.com/LimeSurvey/LimeSurvey/pull/2193

When loading a token by the add participant option, the HTML5 validation is run and doesn't allow to add emails with "non-ascii characters". That's Chrome.

Still, going further, the previous code uses the idna_convert class to convert from unicode to punycode during validation. That created two problems:

• Conversion was applied to the entire address, not just the domain. That is why unicode characters were being accepted on the local part of the address, which is not supposed to be accepted.
  -The idna_convert class does the conversion always, while PHPMailer requires the intl extension to be installed to support IDN addresses. Therefore, some addresses could be accepted which later PHPMailer was not going to be able to handle.

This fix leaves out the idna_convert class (does it have to be removed?) And uses PHPMailer's punyencodeAddress () method, for better consistency.

asapstory published best ideas and top success stories. This is the first online blog that's a collection of all failure to success stories from world wide
https://www.asapstory.com

Fix committed to master branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=33127

Fixed in Release 5.2.12+220131