Changes between Version 36 and Version 42 of Ticket #27029

Timestamp:

Sep 14, 2026, 11:37:03 AM (6 days ago)

Author:

Mike Edmunds

Comment:

Now that the EmailValidator refactoring in 850e026 is merged, I think the best way to move this forward is to:

• Add an accept_eai EmailValidator option (somewhat similar to DomainNameValidator's accept_idna option), which would default to False.
• Make EmailValidator.validate_username() switch to a regular expression allowing EAI usernames when that option is set. Specifically, it would use a new eai_user_regex created by copying the existing user_regex and extending it to allow UTF8-non-ascii as specified in ​RFC 6532 §§3.1–3.2).
• Document that projects wanting to allow EAI (Unicode local-parts) should use EmailValidator(accept_eai=True).

Because the default EmailValidator behavior will not change, this is not a breaking change and does not require deprecation. (A later ticket or new feature request could propose changing to accept EAI addresses by default, through a deprecation process, but I'm not suggesting that now.)

This addresses the original ticket concern within the existing EmailValidator by strictly following the applicable standards.

While I still believe a ​simplified EmailValidator could be useful and would ease long-term maintenance, I think that's better handled as a new feature request at this point. (Also, note that previous discussion in #26423 looked at the idea of adopting HTML5 email validation instead.)