The one thing I systematically do in term of email validation is catch the common typos of the main providers. So things like gmail.con, hotmai.com, gmall.com and so on.
In 99% of those cases, it prevents someone from entering a wrong email.
We do not do email activation by forcing people to click a link in their email to validate that they received it since that causes a drop in the funnel and reduces the amount of revenues (non technical users tend to not come back when you ask them to go to their emails to verify it). So, in this case, correcting the typical typoes is very important. In our case though the information is not extremely private so it's less of a problem to do this.
Having people type the email twice doesn't really prevent typoes, people copy and paste. And if you disable paste, then it becomes annoying to users and you don't want to annoy users during the signup process (plus I hate websites that mess up with paste so I won't be hypocritical and do it).
Lastly, I know that having an email with a local domain name with no TLD is valid but it'll never be valid in the context we are sending so supporting them just doesn't make sense.
> The one thing I systematically do in term of email validation is catch the common typos of the main providers. So things like gmail.con, hotmai.com, gmall.com and so on.
That can be helpful, but I assume you suggest the user that they may have made a typo and not flat out reject the input?
> […] having an email with a local domain name with no TLD is valid but it'll never be valid in the context […]
Well, depending on how the fairly recent brand generic top-level domains work out, I would not rule out someone actually using ceo@cocacola at some point (until the CEO of Coca-Cola realises that legacy email validation regexes mean a suspiciously quieter then usual inbox).
Our email provider flat out refuses to send to those domains actually so we actually reject the input for the domains that the email provider blocks.
> I would not rule out someone actually using ceo@cocacola at some point
Of course, this is subject to change if the practice changes. The aim is to make sure that we balance the percentage of emails that are correct versus the number of potential rejections. If 0.00001% of users use a top level domain and 99.9999% of emails without a tld are invalid, then it makes sense to reject it. We're not trying to find the most perfect solution just the most convenient solution for users.
How about rejecting all email addresses that contain the character sequence "jex"? 99.9999% of email addresses with "jex" in it are invalid, so it makes sense to reject it, doesn't it?
2. No, it still wouldn't make sense to reject existing email addresses if there is a method to figure out whether the email address you are being presented with actually exists instead of divining validity using some unreliable proxy. There is just absolutely no reason to ever reject an email address that you can successfully send emails to.
I mean, in this case there are two reasons. They're both bad reasons, but still.
1. "Our email provider won't send to them". That excuses OP's part in the thing, although now we need to ask why the email provider is being stupid.
2. "We don't do validation links, they cause too many lost users". I have serious problems with this, but from a pure-business standpoint they decided that rejecting valid emails loses fewer users than using account confirmation.
Number two is vaguely horrifying to me, but in terms of "new users gained" it probably works out.
Are they being stupid though? For example, hotnail.com is a parked domain. There's virtually no chance that a user actually has an email address there and sending an email to a wrong email address is bad for the email provider reputation...
I mean it's not like they block a huge amount of domain names but with their volumes, it makes sense to avoid sending emails that will never be received by their intended recipients anyway...
Could it inconvenience legitimate users? Yeah, there's a probably of that but it's negligible and so far we've never had a complaint about it... On the other hand, we've had users telling us that it was good that our system caught their typo.
This is a fair point. I guess it's the sort of thing that I'd prefer to see fixed with a double-check prompt instead of a rejection, but I doubt it's causing many problems.
I was primarily thinking of short domains like "gmail" and "aol". For those, I can see a company called, say, "Gail" getting blocked from legitimately using "Gail.com". "Hotnail" seems a lot less risky.
Not a big problem, I just have an aesthetic objection to very high-friction things like blocking possibly-legal domains. As a double-check option I wouldn't object, and in fairness it's possible no one has ever been inconvenienced.
> 1. "Our email provider won't send to them". That excuses OP's part in the thing, although now we need to ask why the email provider is being stupid.
Nope, actually, it doesn't. If your reaction to noticing that some service that you are using is incompetent is to adopt the same incompetence, that doesn't excuse anything.
> 2. "We don't do validation links, they cause too many lost users". I have serious problems with this, but from a pure-business standpoint they decided that rejecting valid emails loses fewer users than using account confirmation.
> Number two is vaguely horrifying to me, but in terms of "new users gained" it probably works out.
Well, sure, it's as much a reason as "I don't like your nose!"
If they don't do verification emails, they might as well just not ask for an email address in the first place (or make it optional). Misguided "validation" doesn't help with most mistyped addresses anyhow.
I oversold 'excuses'. Let's say "means the original error lies elsewhere". I also wonder who the hell they're using - who ever heard of an email service that bans domains for being likely misspellings?
The "it's as much a reason" I disagree with. Validating common typos will catch more errors than false positives, so you do get more users through your funnel than if you abandon it. "I don't like your nose" is a strict loss, this causes corrections to get real emails. So they'll still miss most typos, but it's a net gain compared to not doing it.
Of course, again, I don't endorse any of this. Decide if you're ok with bad emails, follow through on that decision, use verification, and get a not-incompetent email service.
I like them as well, but for a different reason - I have a way to find what email I used for particular website, if I used it, etc. Doesn't have to be the clicky linky mail, just a confirmation mail will do.
But if you include plain text password in it... ugh.
Oh, we do send a welcome email and actually include a link in the email to subscribe to the newsletter but we don't make it necessary to use the website.
In that case, I'd rather not have the site gather my email address at all. Just create an account with an arbitrary name (or no account at all) and let the user use the web site. As soon as an email address is connected to the account (or the user name itself is an email address), I'd rather have it verified.
But I can see how there may be other concerns (commercial or not) that interfere with this.
Users remember their emails, they don't always remember their nicknames especially if they had to select an alternative nickname because the one they usually chose was already used...
Honestly, it's ruthlessly pragmatic business reasons. Is it ideal? No but in the end, it's the most painless for most users...
And, also most users on that particular site have little computer experience, so it does affect how they react and how we work. If it were something targeting the HN crowd, I'd probably have enforced email validation and would see a much lower drop in conversion due to it because people on HN are used to that and do not have a problem with it.
So, validations and UI workflow have to be adapted to your audience and your business and that's the main point really.
In this particular case, we did experiments with enforcing email validation for a subset of new signups or even allowing a small number of signups to signup with a username instead of an email. So we do have data...
Most of the work I do for other customers doesn't touch those areas of their app, so I only have relevant on hand experience on that particular site but I think it's important to mitigate the recommendation of "Always validation emails" or "Always use regexp" and try to think of the best experience for the kind of users you're targeting.
Sometimes in HN, people talk in absolutes when things are instead very context-dependent.
> We do not do email activation by forcing people to click a link in their email to validate that they received it
Have you considered doing email validation without forcing users to comply? It's fairly common to require valid emails after X days, or in order to unlock N features. Gets the advantages of having valid emails without the disadvantages of a drop signups.
In 99% of those cases, it prevents someone from entering a wrong email.
We do not do email activation by forcing people to click a link in their email to validate that they received it since that causes a drop in the funnel and reduces the amount of revenues (non technical users tend to not come back when you ask them to go to their emails to verify it). So, in this case, correcting the typical typoes is very important. In our case though the information is not extremely private so it's less of a problem to do this.
Having people type the email twice doesn't really prevent typoes, people copy and paste. And if you disable paste, then it becomes annoying to users and you don't want to annoy users during the signup process (plus I hate websites that mess up with paste so I won't be hypocritical and do it).
Lastly, I know that having an email with a local domain name with no TLD is valid but it'll never be valid in the context we are sending so supporting them just doesn't make sense.