Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why don’t we do email verification in reverse?

blog.yossarian.net

Post reply on HN
Print view View original

51–60 of 329 posts

Re: Why don’t we do email verification in reverse?

#51

Post by stormbrew »

I would hate this, and probably instantly bail out of any flow that tried to force it on me.

Being able to receive mail on an address should not necessarily imply a capability to send from it. This scheme rules out many actual or potential schemes for email anonymity, especially in a world where very little email is still transactional relatively speaking.

I do not give (almost) any website an address I send normal email from, nor do I want to. And my default configured client for mailto:, if I even have one on the device I'm using, is not going to be set to the single use mail I want to sign up with.

Re: Why don’t we do email verification in reverse?

#53

Post by derobert »

A lot of email clients support multiple email accounts, or at least sending addresses. Not just desktop ones like Thunderbird, but web ones like Gmail too.

You can additionally set up email to be forwarded (or retrieved). So, for example, you can easily have your me@example.com account forwarded in to Gmail and Gmail set up to send from that address.

That works fine if the site sends a confirmation email, it'll get to Gmail where the user expects to read it. But the other way around will give the user errors about having the wrong email (even if tj user picks the right outgoing address, because you won't be able to verify it), and ultimately cause the user to give up or you're going to have to spend a lot of time supporting all kinds of weird email configs.

Re: Why don’t we do email verification in reverse?

#54

Post by simlan »

gingerlime wrote: post #30

Besides the security and usability problems others mentioned, I also highly doubt it will improve confirmation conversions. One thing that helped us improve confirmations -- we A/B tested it and confirmation rates increased ~8%: send a 4-digit confirmation code rather than just a link. It's easier and more familiar on mobile, especially if you see the code on the push notification, so don't even need to open the emai…

Agreed. Usability on mobile is best with the short codes. Even 2 FA is fairly efficient that way as long as the messages are designed to show the code in the preview.

Re: Why don’t we do email verification in reverse?

#55

Post by systoll »

One decent argument not made: this would avoid “spam” reaching people’s inboxes from people trying to sign up with emails they don’t own.

As the owner of a very common [initial][last name]@gmail.com address, I’d take the trade off, but this might be even more niche than neomutt users.

Re: Why don’t we do email verification in reverse?

#57

Post by throwaway892238 »

frenchman99 wrote: post #44
9935c101ab17a66 wrote: post #35

Earlier quoted context omitted.

The article has a section on security where they address the problem you describe and several others. Do you find their reasoning unsound?

Yes I do find them unsound. Now you need ordinary people to understand the pros and cons of DMARC (SPF + DKIM). Not every one has this configured. In fact it's shocking how many companies don't have DMARC set up given the benefits. If major providers such as Gmail/Microsoft/etc agreed to require DMARC for all incoming email senders, then maybe 5 years later we could speak about this again because then DMARC would be…

As an example: AWS has no DMARC on its SES domain, and its SES domain is what sends SES emails from by default. Anyone who's not using a custom domain with SES, has no way for anyone to validate where that email came from. All CloudWatch alerts come via the generic SES domain, so there is literally no way to tell if a CloudWatch alert is spoofed or not.

I'm really surprised no hackers have started sending out phishes via spoofed CloudWatch alerts yet. I guess it takes a while for them to capitalize on industrial vulnerabilities.

Re: Why don’t we do email verification in reverse?

#58

Post by gregmac »

I'm very skeptical of relying on every random domain on the internet setting up SPF/DKIM properly to the point it's trustworthy in this way. I can't find stats on usage of `~all` (soft fail) but only an abysmal 6.4% of .com domains have `-all` (hardfail) [0].

Another major issue I'd personally run into is usage of catch-all addressing [1] (and same issue with plus-addressing [2]). I use a unique email address for every site I sign up to, but I don't easily have the capability to send "from" those addresses. It's not that it's hard to do, but it's enough effort that I'd not bother signing up at all.

> The user is more active: instead of waiting to receive an email in their inbox, the user is immediately presented with an email to send. They can make progress in the flow themselves [...] Even if the flows take roughly the same amount of wall time, this activity makes the “reverse” flow feel faster and more responsive.

Respectfully disagree with this assertion. Users are used to emails taking some time to arrive. I think delays in this flow will feel like your verification service is broken.

> Completing the flow is equivalent to proving that you control an email address

Not exactly. It proves the IP you send from is authorized to send mail for the domain, according to the SPF record setup by the domain owner. It doesn't prove it's your individual email address, and it doesn't prove you can ever receive mail to it.

> The user has fewer opportunities to make mistakes: Users frequently mis-copy verification links, or use clients that mangle them, &c. These mistakes can’t happen in the “reverse” flow, because there’s no verification link to click. The user only has to remember how to send an email, which is a reasonable expectation in any scheme where the user is expected to have an email address.

Except the mailto: link contains a verification code, and thus is subject to exactly the same problems?

IMHO this is better solved by just not doing bad verification URLs.

Bad: https://auth1.web04.example.org/app/1042/verify.php?action=e...

Good: https://example.org/verify/BC44-5204

> The user’s mistakes are easier to detect

If you send the verification email at the beginning of account creation you can avoid them going too far.

If that's a barrier to your sign-up flow, provide some useful options. Eg: after they still haven't verified, ask "Still haven't got the verification email? It was sent to xxxx@example.org, but you can click here to modify it".

[0] https://spf-all.com/by-tld.html

[1] https://news.ycombinator.com/item?id=19333901

[2] https://en.wikipedia.org/wiki/Email_address#Subaddressing

Re: Why don’t we do email verification in reverse?

#59

Post by 9935c101ab17a66 »

neximo64 wrote: post #2

Some 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…

Well said. Particularly the point around people not having email set up on an “OS” level. There are a lot of people who already struggle to effectively use modern computers and smartphones, and you’ll run into all kinds of weird edge cases. For example, I previously helped a friend who had just been using the gmail website on their smartphone for years because they had forgot their password but Safaris keychain had saved it so they could auto fill the password.

I’ve encountered countless other scenarios where a user is using software in “non-ideal” way because it works for them or they don’t know any better.

Re: Why don’t we do email verification in reverse?

#60

Post by osullip »

HWR_14 wrote: post #45
simonw wrote: post #5

A 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…

For your example, this seems bizarre. Every "sign up" process I can think of ends with you being signed into to your new account. Every "log in" process includes a button or link that says "are you a new user, sign up here". You chose a very streamlined thing to worry about.

I'm not sure. A lot end up sending an email that you need to click on to verify.
Post reply on HN