Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Before v4.0.0, we were using
SwiftMailer
, which didn’t allow non-ascii chars in the local part of the email (related issue); now, we’re usingyiisoft/yii2-symfonymailer
which usessymfony/mime
to deal with email addresses: https://github.com/symfony/mime/blob/7.2/Encoder/IdnAddressEncoder.php and it does allow non-ascii chars in the local part of the email address.This PR:
useIdnaNontransitionalToUnicode
general config setting, which isfalse
by default. When set totrue
, it treats a handful of characters (includingß
) in a way compatible with IDNA2003. More info can be found here.Further background:
Currently, non-ASCII characters are allowed in the domain part of the email address. This means that you register a user with an email address of
test@teßt.com
; however, when that email is run via theidn_to_utf8()
method, it’s changed to [email protected]. Since this has been the case for a while, we need to keep this behaviour. That said, it should also be possible to keep the German eszett intact, if that’s what you want, especially since we’re now allowing for such characters in the local part of the email address. The newuseIdnaNontransitionalToUnicode
allows for that behaviour.It also looks like the browser’s email validation doesn’t accept non-ASCII characters, despite the RFC allowing them; so, to accept them, you’ll have to have
novalidate
on your front-end forms.Related issues
#16969