Hacker News Reader

Comment by robinhouston | Hacker News Reader

I think there is a sequence of reasonable thoughts that would justify this design.

Anyone who has ever run a website with a signup form will know that a surprisingly large number of people are unable to type their own email address correctly. If the email address is wrong, there is no way to contact the user nor to verify their account. So there is some sense in forcing people to at least type the same thing twice, annoying though it is to the majority of us who have no trouble typing our email address.

If you don’t know your password, that is recoverable as long as your email address is correct in the system, because you can get a password reset link emailed to you.

So it is not entirely unreasonable to conclude that it is more important for the email address to be typed correctly than the password.

View on HN

This is a genuine excerpt from the users table on a site I run, but with $$$ to obfuscate part of the address:

Mr Crosby (crosby$$$@btinternet.co)

MR Crosby (crosby$$$@btintenet.com)

Mr Crosby (crosby$$$@btinternet.compost)

MR Crosby (crosby$$$@btinternet.com)

I have this exact issue as well.

We have just today changed our site to use this https://github.com/Kicksend/mailcheck , It will be interesting to see how well it works.

so do validation that the domain exists. Don't make the user solve a technical problem.

As others have said, there are better ways to ensure you get a valid email address other than making the user type it twice.

In real life, there will ALWAYS be people who manage to typo the same thing twice, there will always be mailservers who respond with "250 Recipient Ok" for bad emails, there will always be domains with MX records but without a mailserver.

The difference with each of these validations is who performs the validations, keeping the validation automated and between YOU and the destination mail server administrators is a much better choice IMO.

> there will always be domains with MX records but without a mailserver.

Ouch, that sounds like a pain to deal with. But I will mention that MX records are not required, so don't forget about the opposite situation where they have a mailserver and no MX.

If there are no MX records for a domain the mail should be delivered to the A-record.

If there are MX records for the domain, but mail delivery to it fails, it should not try to deliver to the A-record.

http://tools.ietf.org/html/rfc2821#section-5

There's really only one good way to validate email addresses: send a mail to it, and let the user respond to something in that mail. If you don't do that, it could still be someone else's email address, or an address nobody reads.

If it's really that important, use it to check that it works.

Yesterday I started getting someone else's K-Mart and Sears receipts.

Today I discovered I have an account on Roblox.com.

I'm going to guess that in both cases someone managed to enter not-their-email-address twice, correctly.

"Valid address" really means "the person who in fact gets mail at that address asked to get that mail."

How about a website registration that looks like this:

"Send an email to register@example.com with the following code: ABC123"

Your registration process gets the email, you can deduce the person's name and email address without typos, and you can then reply with an activation link allowing a password to be set (that page could also allow verifying/editing their "real name").

This lets users register without typing anything except their password on the activation page.

A drawback of this is that it breaks the "flow" of your site by having the user switch over to their email app. But most sites send an "activation" email anyway, so I'm not sure it's a net negative.

Edit: you probably don't even need to ask them to copy/paste the code. The code could be embedded in the address (e.g. register+ABC123@example.com) or in the subject attribute of the mailto link) or you might not even need a "code" at all.

I like the idea, but you can't deduce name from email address, or at least not often enough to use it even to prefill the field in the form.

I believe the suggestion is to use the "From:" field of the email, which for a significant fraction (perhaps even majority) of people includes their name. I think it's an interesting idea.

FWIW, curecos.com, IIRC has a signup process that goes like:

* enter password * get confirmation email with link to signup

The activation comes _before_ the signup, as in your example, minus the email reply.

Yep, rather straight forward thought there.

If you are outside, it's late, you maybe had a drink and it's even raining this can happen. You can also accidentally cause a submit while entering your email address.

Of course when you autofill forms that's not a problem, but thinking that people don't mistype, which can be hard to see, depending on the mistake you made is kinda stupid and there is nothing more annoying then realizing your favorite login name is used in unaccessible just because the person programming the system thought it was impossible to ever enter your email address incorrectly.

You could also just ask the mail server directly like this: https://gist.github.com/poizan42/2731787

Sure this won't work for every SMTP server as some will just "OK" the mail first and send a bounce back later, but neither will the "ask for email twice" approach work every time, and at least it guarantees that the domain exists and has a functioning SMTP server.

A better alternative is to send an email for verification. If the email bounces, you can mark the account as unverified and ask them to verify their email again.

Thats what I do. But it might take time (graylisting for example). So instant feedback is not possible.

Reply on news.ycombinator.com