Opened 12 years ago

Closed 12 years ago

#17404 closed Bug (wontfix)

Email validator does not accept numeric TLD

Reported by: progval@… Owned by: nobody
Component: Core (Other) Version: 1.3
Severity: Normal Keywords: email validator validation
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

The email validator does not accepte numeric TLDs, while they are valid.

An example : https://www.42registry.org/

Change History (4)

comment:1 by Ramiro Morales, 12 years ago

Resolution: worksforme
Status: newclosed

https://www.42registry.org/ isn't a valid email addres at all. And adding a test to validate the 'something@42registry.org' address shows that our email validator doesn't reject it (tested with 1,3., 1.3.1, 1.3.X and trunk)

comment:2 by anonymous, 12 years ago

Resolution: worksforme
Status: closedreopened

I meant that 42registry.org provides domain name registration for .42 domains. So progval@progval.42 is valid.

comment:3 by Aymeric Augustin, 12 years ago

I don't want to start a policy debate, but I have to point out that .42 only works for people who're using Global Anycast's DNS — in other words, it doesn't work for something like 99.999% of Internet users (take or give one 9).

The home page of Global Anycast (only available in French) says that the next steps to help the project are "contribute to create a working proof of concept" and "help define protocol v1". This indicates that the projects is stil far from mainstream.

Given that this regex is subject to endless debates — see #17405, #17386, #17100, #16310, and that's just from the first of the eleven pages of results for "email validator" — I'm reluctant to accept this ticket.

comment:4 by Gabriel Hurley, 12 years ago

Resolution: wontfix
Status: reopenedclosed

After some discussion between PaulM and myself, given that there are no globally approved TLDs that are only numbers, and given that you can write your own validator if you so desire, and given the difficulty with that regex in general (as already pointed out) I'm gonna make a call on this not being a good candidate for inclusion in Django core at this time since that's three core devs all against it.

If you feel this decision is incorrect/inappropriate, please take it to the Django Dev mailing list and make your case to the community. Thanks for pointing this out, though!

Note: See TracTickets for help on using tickets.
Back to Top