hello@visit.melbourne.
Yes, that's a valid TLD now. hello@visit.melbourne.
Yes, that's a valid TLD now.If you are referring to {2,6}, then it's easy to adjust once longer domains are put to actual use. If you are referring to the trailing dot, then that's exactly what I was saying - practically, email formats that are used by real people is a much simpler subset of what's permitted by the spec.
http://newgtlds.icann.org/sites/default/files/ier/hu62oef5uc...
gTLD can also contain punnycode/unicode now, which additionally breaks your regex in another way.
--
But more generally, you just don't want to hear what I'm saying.Right now, people do NOT use email addresses with internationalized domains, they do NOT put trailing periods in domain names, etc. Once they start doing that, the regex can be adjusted to accommodate for that on first false rejection. As it exists now, the regex is tailored exactly to how emails are used now, by real humans. A negative is an indication of a bot activity or some other oddity that needs attention. Feel free to support that transparently, but the question is why would you want to do that.
This assumes that you manually verify every rejection, or that they contact you. In other words: Either you're not using this anywhere with volume that matters, or you don't know that it hasn't caught false negatives.
> A negative is an indication of a bot activity or some other oddity that needs attention
High volume of negatives is an indication of bot activity or some other oddity. A single or handful of negatives is just humans going about their business as horrible typists.
If your volume is small enough that you can treat every negative as something to investigate, you really have no basis for saying anything about how well your regex works.
Why?:
It's very bad UX to say to a human "we don't support you because we think you just might be a bot".
You should better lean on the permissive side; that would be one less thing to think about.
That kind of "validation" does not check for existing email addresses anyway, so there is not much value in trying to be strict in this area.