Really the entire idea of client/server-side email "validation" kind of seems like an ancient, cockroach-like anti-pattern that is impossible to stamp out. Like, what is the problem they're even solving? One validates email addresses by sending an email with a token the user then acts on. There are useful things to do with emails, like checking against already registered ones (including any blacklists), but I can't think of any that would result in any in-page user feedback since that would generally be a dumb information leak. Like if someone tries to register an already registered email, send an email about it don't leak that it's registered.
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.
> Even on the left side of the @ a surprising number of scripts seem to fail on things that are perfectly acceptable characters.
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.
>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.
Lots of these kinds of things—at least for companies that aren't just copying others' patterns blindly—are the result of multiple support calls/emails/tickets. The tickets, in this case, would be users complaining about your service being broken when in fact they messed up their email address and don't realize it. There are also some cases in which you want to use the address immediately to reduce friction (as with sending receipts or shipping data for an order by a "guest" user without an account) without first sending a verify-address email.
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.
This has been common for mailing addresses: with a parsing and validation system, the site will tell the user "We think you entered ... as your address; we think your address should be this: ...", along with options to keep the original entry or use the suggestion. This has the advantage of catching mistakes, not making unusual addresses unusual, and letting the user know if the site is interpreting what they entered in a way that won't actually work (eg, leaving off something important, or ordering components badly).
Steam does emails correctly when it comes to login/registration; your email address is just a contact method for your account, and you can have multiple accounts with the same email address.
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.
I'd prefer to just have it. Seems decently important for me privacy wise. I as a customer don't want others to be able to test whether I have signed up somewhere and also it is much better security wise and not leaking business data.
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.”</>
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?
> like an ancient, cockroach-like anti-pattern that is impossible to stamp out.
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?
>I feel like you just described email (or rather, "the" email spec, as if there was a single one) in general.
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.
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.