[#16637] - refactor: allow utf8 in email local part.

[noone-silent]

Hello!

• Type: bug fix
• Link to issue: [BUG]: Email validation does not allow UTF8SMTP #16637

In raising this pull request, I confirm the following:

• I have read and understood the Contributing Guidelines
• I have checked that another pull request for this purpose does not exist
• I wrote some tests for this PR
• I have updated the relevant CHANGELOG
• I have created a PR for the documentation about this change

Small description of change: Allow UTF8 in local part of the email, if allowUTF8 is true

Thanks

[niden]

Thank you @noone-silent

[s-ohnishi]

It seems that you are focusing on internationalization of the local part, but don't you need to consider internationalizing the domain name?

By the way, RFC5336 has been abolished and the revised version is RFC 6531.

[noone-silent]

It seems that you are focusing on internationalization of the local part, but don't you need to consider internationalizing the domain name?

By the way, RFC5336 has been abolished and the revised version is RFC 6531.

The domain part with umlauts or non ascii chars is normally not valid and needs to be transformed to ascii through punycode. There is a function in the INTL extension. Non ASCII chars in the local part is totally valid and doesn't need any transformation.

[s-ohnishi]

Non-ASCII characters in the local part are still uncommon (which is why they're disabled by default even with this update, perhaps?), so when considering validation of email addresses that contain non-ASCII characters, it seems unfair to not take the domain part into consideration.
Even though it's non-standard, are you validating it by adding a special flag, and then converting the part to the right of the @ character to punycode before validating it?
I think it's only natural that there would be a request to allow non-ASCII characters in the entire email address, rather than just in the local part.
I would simply like to pass it to the validator (even if a flag is specified).

[noone-silent]

Non-ASCII characters in the local part are still uncommon (which is why they're disabled by default even with this update, perhaps?), so when considering validation of email addresses that contain non-ASCII characters, it seems unfair to not take the domain part into consideration. Even though it's non-standard, are you validating it by adding a special flag, and then converting the part to the right of the @ character to punycode before validating it? I think it's only natural that there would be a request to allow non-ASCII characters in the entire email address, rather than just in the local part. I would simply like to pass it to the validator (even if a flag is specified).

We could implement this, but that would need the intl extension and I don't know if this is a requirement for Phalcon or if it is usable in Zephir. So if it is not a requirement, it would be a breaking change.

[s-ohnishi]

I don't know if this is a breaking change or a requirement of some kind.
But I can't imagine that progressive users who want to allow non-ASCII characters in email addresses don't know about IDNs, and would want to use them, right?