Why don’t we do email verification in reverse?
blog.yossarian.net
Why don’t we do email verification in reverse?
1–10 of 329 posts
Re: Why don’t we do email verification in reverse?
#2Some reasons:
- Not everyone will have set email up on the phone.
- If a laptop is used it adds more complexity if the email is not set up on the device, (or e.g if Gmail is used via a web browser)
- Not everyone will use the Mail app as default and will need to pick the right app
- There may be multiple emails and additional complexity to pick the right 'from' if there are multiple emails being used.
- It is a test of the SMTP server, not the ability to receive email.
- The email needs to match exactly what is being used to sign up when sending the email. With an email inbox email+label@gmail.com can be used as an example.
Re: Why don’t we do email verification in reverse?
#3Some reasons: - Not everyone will have set email up on the phone. - If a laptop is used it adds more complexity if the email is not set up on the device, (or e.g if Gmail is used via a web browser) - Not everyone will use the Mail app as default and will need to pick the right app - There may be multiple emails and additional complexity to pick the right 'from' if there are multiple emails being used. - It is a test…
Right: this would fail for me on my laptop, because I use gmail for email and don't have anything setup such that a mailto: link would compose a new email from my gmail account.
Re: Why don’t we do email verification in reverse?
#4This isn’t better. I don’t have a default mail client and a lot of people don’t. You could open up the browser page to login but by the time you’re logged in all context is lost and you won’t get the pre setup outgoing mail ready to click send.
Re: Why don’t we do email verification in reverse?
#5A general rule of thumb I've built up over the years: resist the temptation to innovate around login!
Look at the most commonly used flows that are not obviously terrible and try to implement as close a match to them as possible.
When I've tried to innovate around login in the past I've found that any clever ideas I come up with inevitably run into road blocks pretty quickly.
Here's one example: why have a separate login form from a signup form? They both involve asking the user for an email and password, why not have one form that can do either depending on if the user's account already exists?
I quickly learned why: if you don't understand the user's intent when they submitted that form, you can't show them error messages that match their mental model as to what is going on. This makes for an incredibly confusing experience the moment you step off the happy path.
----
That's not to say it's not interesting and valuable to think through new login mechanisms. They're very interesting design challenges! But its good to be prepared to find out that vanishingly few innovative ideas will work out as genuine improvements.
Re: Why don’t we do email verification in reverse?
#6Brilliant.
Re: Why don’t we do email verification in reverse?
#7"fewer opportunities for the user to make mistakes"
Really?
Re: Why don’t we do email verification in reverse?
#8Spoofing?
Re: Why don’t we do email verification in reverse?
#9A general rule of thumb I've built up over the years: resist the temptation to innovate around login! Look at the most commonly used flows that are not obviously terrible and try to implement as close a match to them as possible. When I've tried to innovate around login in the past I've found that any clever ideas I come up with inevitably run into road blocks pretty quickly. Here's one example: why have a separate l…
Haha, the mistake I've helped implement thrice. Two forms, always.
Re: Why don’t we do email verification in reverse?
#10This is not well reasoned. Sending emails can be easily spoofed, because sending doesn't fully check the identity of the sender as being in control of the email account. There is discussion of various technologies like SPF or DKIM, but those are not universally applied. When they are applied, there isn't universal quality in their application.
The crux of verification using an email account is that the person _controls_ the email account. That means the person can receive an email at that account. If the person cannot receive an email at a specific account, that account cannot be used as their identity at the web server.