Discover.com, for example, rejected it when I did a card application, but disabling JavaScript let it go through on the server-side validation. Bloody weird.
And as well as being useless most such scripts seem to date back a long ways and have very lazy and fixed assumptions about what constitutes a valid address. I mean, I've never been a fan of the explosion of TLDs, but it's also a reality and they're all valid. Even on the left side of the @ a surprising number of scripts seem to fail on things that are perfectly acceptable characters.
Strikes me as one of the many little minor GUI traps where new designers get carried away with the power of scripts and do without asking if they should, then further get too clever by half.
I've had an input require a minimum of 3 characters on the left side of the @ to register. My email was just "me@example.com" using my own domain name. A perfectly valid email address. I am also unable to sign up for Id.me for the IRS because it rejects both of my personal email addresses. I cannot register to create NPM packages for the same reason. I also cannot sign up for Vercel either. I cannot sign up to Vercel via Github and when I try to sign up by email it says the account already exists. When I attempt to do a password recovery for the email it says "Sorry, we are unable to validate that email." So the original error of "account already exists" is actually wrong - the account doesn't exist and can't exist because they aren't able to validate the email for it.
My personal emails aren't even "weird" ones like ones with an emoji or punycode domain or non-Latin character sets.
I hate with a fiery, burning passion every site that attempts to do any kind of email validation beyond simply sending me an email and letting me click a link to verify my email exists.
Yet at the same time, that's the one important validation that infuriatingly many sites don't do.
I once lost a protracted argument with the US Department of Education who absolutely refused to stop sending me private personal financial aid and academic details of a complete stranger who mistakenly gave them a common outlook.com email address that I have. As far as I can tell, in their view, since the user had put in a valid email address, that was their email address, and just because it was my email address didn't mean I was authorized to have it removed from the account. I continue to receive the person's private information from the state, colleges, and predatory businesses.
In fact, the number of mistaken accounts that get linked with that email address is fascinating. Paypal UK apparently does not send email validation requests before associating email addresses with accounts. Nordstrom does not. Internal divisions of the North Carolina Department of Insurance does not. UK Revenue and Customs apparently does not. Many of the larger organizations that, even more infuriatingly, always send emails from noreply addresses, and give no other way of contacting them other than logging into your account.
My personal preference is to let the user know why you think the email address looks wrong and give them some way to override your judgement and submit anyway. It's more work, but it gives you all the benefits of rejecting "bad" addresses while minimizing the harm of false-positives from your bad-address-spotting code (it's very slightly annoying to people with odd-looking addresses, but not that big a deal). This also lets you go beyond validating the form of the email address, to alert on common typos that might be legitimate (and which can sneak in even if you make the user type the address twice). "gmial.com looks like it might be a mistake; are you sure you got that right?" Or "yaho.com". Or even just Levenshtein-distance check a bunch of common email domains and alert any that are close, but not exact. You annoy whoever has an actual address at those domains, but save a bunch more people who screwed up.
IMO, the only client-side validation that would be done on email addresses is to ensure it doesn't have a space in it and it has an @ in it, and maybe make sure someone isn't doing funny things without a hostname (disallow IP-based hosts).
The problem they're solving is that a lot of people just enter their email wrong and then wonder why they didn't get the signup email.
> Like if someone tries to register an already registered email, send an email about it don't leak that it's registered.
This is something that's cargo-culted far too often. Maybe for some services it's worth keeping secret which emails are signed up, but for most it isn't.
And most times, it is standard practice to hide sign ups, luckily.
<orange>“This doesn’t look like a correct email address that our clients usually use. Please re-check it again and proceed if you’re sure.”</>
for most it isn't
It depends more on an email address, than on a service type, because it’s a part of a personal information that a person owns.
And what proportion - especially what proportion of people who make mistakes when entering their email address - do you think will pay any attention to that?
I feel like you just described email (or rather, "the" email spec, as if there was a single one) in general.
Yes it obviously still serves its purpose but what consists a valid email-address (let alone email) is specified in such a godawful way that every application that I've seen in the wild trying to address this problem somehow fails at it (sometimes in negligible, often in very gross ways).
If devs all over the world manage to screw it up over and over again, maybe it's just time to call it quits and acknowledge that the spec is broken?
But the concept of email is extremely useful, valuable, understandable, and it's standardized and out of the centralized control so common for anything developed these days. I'd be happy to see some sort of email 2.0, cleaned up, with modern encryption by default and so on that served as a replacement. But I don't know of anybody even proposing such a thing. Instead the rage is to create yet another fucking instant messenger or slack thing or whatever.
Everyone knows the spec is ancient and has had a lot grafted onto it. But it's not going anywhere without a good replacement and even with that the transition would take a very, very long time. So as is so very, very often the case in computing we just have to deal with that.
bell-atl.com is one of the oldest domains still in use, registered in 1986.