9 ms·

Why don’t we do email verification in reverse?

• bergenty 4y ago
  This 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.
• type0 4y ago
  > Is it a good idea? No, because email forwarding is a thing and many people use it
• artur_makly 4y ago
  Has anyone simply tried NOT using any email verification? Sure there will be a Low % of mis-keyed or fake emails.. but it does remove a HUGE wall and reduces TimeToFirstAppExperience.
• mchesler 4y ago
  The proposed solution breaks down when you're trying to register with an alias that you can't send from. For example, I share an alias with my wife that we use for shared logins, shared notifications, etc. The burden of helping her be able to send from that address is sufficiently high that I would likely pass on any service that transitioned to this mode of operation.
• propter_hoc 4y ago
  "fewer opportunities for the user to make mistakes" Really?
  • djbusby 4y ago
    Yes. Please, learn from my fail.
  • ilikehurdles 4y ago
    Fewer users, fewer opportunities.
• neximo64 4y ago
  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 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.
  • simonw 4y ago
    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.
    • yunohn 4y ago
      It’s actually quite easy to set this up, if you missed doing so when it asks: https://support.google.com/a/users/answer/9308783?hl=en https://support.google.com/a/users/answer/9308783?hl=en
      • cdmoyer 4y ago
        If you use chrome and only chrome.
        • Boltgolt 4y ago
          Firefox also opens a gmail tab for me when I click on a mailto: link actually
      • gist 4y ago
        Thanks for that. I've been dealing with this issue forever (but never even thought to RTFM on the issue).
  • 4y ago
• simonw 4y ago
  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 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.
  • djbusby 4y ago
    Haha, the mistake I've helped implement thrice. Two forms, always.
  • melvinmelih 4y ago
    When I started on my first project as a junior engineer I thought I was being clever to build an app without any passwords: every time you wanted to login you received a new email with a link to log you in. Technically, this worked great but after a while I received many complaints from frustrated users who kept looking for the “signup form”…
    • smt88 4y ago
      You can solve this problem without a signup form. Just give the user two links: sign up and log in. Both ask for email address first. The next screen tells them to check their email. You can use unusual flows without confusing users as long as you give them cues about how to do what they're trying to do.
      • 4y ago
• jimmckin1 4y ago
  Brilliant.
• texasbigdata 4y ago
  Spoofing?
  • m00x 4y ago
    Did you read the article? He wrote a paragraph on exactly this.
    • texasbigdata 4y ago
      My bad. Thx.
• IncRnd 4y ago
  This 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.
  • mgarciaisaia 4y ago
    I'd argue the crux is about proving that Me The Service can send You The User whatever info is needed (password reset, notification of planned downtimes, pricing changes, warnings about service abuse) to this address - and you'll get it. I don't care about you "controlling" an email address - you can easily get fake ones for free. It's about both parties having agreed _at least once_ on a way for the service to communicate important stuff to you.
    • dcow 4y ago
      Ownership over the email shortname is exactly what is being proven. It’s your identity as far as the service is concerned. I can block emails from a service right after verifying so verifying does not guarantee that I will receive emails from the service at any point in the future.
      • withinboredom 4y ago
        If you do block it, your access to the account you’ve created might be in jeopardy. At least it depends on how you “block” it. If the service receives an error on future emails, the user’s account can be disabled, as usually described in the TOS.
    • weird-eye-issue 4y ago
      What's a "fake" email address? If you can get emails to an email address then it isn't fake and you are in control of it, at least for the time being
• travisgriggs 4y ago
  I personally like the scheme. But I think it caters to the technologically capable, in particular the “compose an email with this bit of magically secure content” skill. However, these services have to accommodate the technologically less capable. So the degenerate reduction to basically “ok, we’re going to do this the hard/easy way. You just have to click where we tell you to. It’s kinda tedious, but just push the singular buttons we tell you to.”
• alex_young 4y ago
  How many users will abandon at the first mailto link? My guess: 95%
• pvtmert 4y ago
  Because most people have aliases to signup Either mail+alias@gmail.com or mail-list@company.com. For instance, I used admin@, devops@, invoice@, etc. in the places I worked. Each of them includes multiple users (leadership chain and the team)
  • NicoJuicy 4y ago
    Most??? I use that, but I'm 100% sure a minority. You're generalizing HN crowd, but you didn't.
    • pvtmert 4y ago
      Well, it's way to circumvent extra costs created by individual e-mail accounts.
• elptacek 4y ago
  What’s doing the verification of the email on the server side? How does this service associate the email with the account? Specifically, what could be put in the email header or body by the MUA that is equivalent to a single use auth token?
• throwaway892238 4y ago
  1. Attacker goes to website, initiates signup up for an account 2. Website generates mail link for attacker to send 3. Attacker uses mail link to spoof email 4. Account is opened for the attacker using email address This spoof attack works for both account creation and password reset (account takeover). This attack is impossible if the website sends a verification email to the user's inbox which only the person who controls the inbox has access to. Hence, while the proposed method is interesting, it exposes the user to an unnecessary attack vector.
  • dcow 4y ago
    Can you explain (3)?
    • throwaway892238 4y ago
      The attacker just sends an email that they got from the target server's "mailto" link. They just have to use a spoofing method when they do. Such as: 1. If the target website doesn't validate DKIM/SPF/DMARC, the spoof works. 2. If the target website (or source domain) has a flaw in its DKIM/SPF/DMARC configuration, the spoof works. 3. If the attacker can use a DNS or BGP attack on A) the nameserver of the source, B) the resolver of the target, C) any intermediary, etc, then the spoof works. 4. If the attacker develops a novel spoofing attack, the spoof works. It's less a question of "how" than "when". A defender has to be successful every time in a myriad different ways; an attacker only has to be successful once. Removing an attack vector is always better than having to defend against it.
  • 9935c101ab17a66 4y ago
    The article has a section on security where they address the problem you describe and several others. Do you find their reasoning unsound?
    • throwaway892238 4y ago
      Yes. 1) DKIM, SPF and DMARC do not prevent spoofing, they simply make it less easy. A compromise of those methods, or an attack on DNS or BGP, or any other novel spoofing attack, gives the attacker a successful attack vector that would not exist if the website simply sent the user an email to verify. 2) The unique token and timeout is simply given to the attacker when the attacker initiates the new account/password reset form, it has no bearing whatsoever on security.
• LudwigNagasena 4y ago
  >…and here it is in neomutt, which helpfully “renders” the HTML with lynx: >… >But that’s a solution born from practice: the fact remains that HTML email doesn’t generally degrade gracefully in clients that don’t support images or CSS. I hope that companies don’t waste their time at such edge cases that are irrelevant for 99.9% of users such as Lynx graceful degradation. It reminds me of the stories about clients that want their website to look nice in IE6.
  • r_hoods_ghost 4y ago
    Yep. I read this and thought PEBKAC. Optimise for the base case, be inclusive of those using screen readers, ignore the masochists who insist on making life difficult for themselves by refusing to use technologies that have been around for decades. The author's other issue - multiple browser sessions open and logged in to different accounts and tabs opening in the last active one - this is a more common annoyance. But easily solved by the user making sure they are in the right browser session by focussing it. So PEBKAC again.
    • woodruffw 4y ago
      I'll say as the PEBKAC'd author: I try to remember to focus the right browser session! But I still load the wrong one about once a week, and whether it works with a particular site is a crapshoot.
  • gregmac 4y ago
    Without weighing in on this, I think this entire section is a distraction in this post. The author's point in this article would be better served by moving the HTML rant to its own blog post.
  • weird-eye-issue 4y ago
    Well there was a time when IE6 compatibility did matter
  • hericium 4y ago
    Multi-part MIME emails with both plain text and HTML content used to be a standard[1] or at least a good and common practice. Not including plain text version or making it "can't see newsletter? click here for web article" is an ongoing process of moving users from unsnoopable email to invigilated web. It's invisible to dumbed-down users, possibly saves corpos some money: devs can learn something that benefits business more and, depending on email volume, business may decrease spending a bit by removing few kilobytes of text from each message sent. Imo a standard of sorts, being removed due to lack of knowledge or for money (savings on data transfer or profit from data gained from users reading "web version of email" and email clients loading remote content) doesn't make it an "edge case". The edge case here (necessity to parse and read HTML in pure email client) is an effect of businesses and developers not following standards in the first place. Also, IE6 overstayed its welcome not due to edge user cases but due to corporate savings as well. [1] https://www.rfc-editor.org/rfc/rfc2046.html#section-5.1 https://www.rfc-editor.org/rfc/rfc2046.html#section-5.1
• sowbug 4y ago
  I've had family members fall prey to phishing scams. I would be concerned if legitimate sites trained their users to send odd content to odd addresses as part of normal net usage. How can an ordinary person understand the difference between sending a token to real.com and sending a threat to another user on behalf of fake.com?
  • antioppressor 4y ago
    • woodruffw 4y ago
      I wasn’t aware that my random blog post thoughts were that influential!
• franky47 4y ago
  I've had situations where some email clients (including Outlook) would visit URLs in emails, for "link protection" purposes. Coupled with the magic-link approach (including a token in the URL that authenticates the user), this can cause a lot of problems.
  • withinboredom 4y ago
    Apple Mail does this by default now too.
• gingerlime 4y ago
  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 email. I suspect it's less likely to land as a promotion email in Gmail, because of the code/semantics. It's quite a fun experience as well in my opinion. It seems like more work, but entering 4 digits on the same open tab is easier and nicer experience than clicking on an email link. There are some security considerations. A short code can be brute-forced, so you need to rate-limit the number of guesses.
  • simlan 4y ago
    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.
  • ozim 4y ago
    Not having a link in email is important. I believe most of the times email from my systems go to spam because there is a link in it. I don't have any hard data but I can imagine that if email contains link it will be checked by more rules in heuristic checks. If there are no links - most likely it is not spam.
    • gingerlime 4y ago
      in our case we included both a link and the code and saw an increase in confirmation rates. If I recall we reached over 90% conversion rates. For a B2C niche service, I think that’s pretty high. I somehow doubt removing the link will improve things further, but it might be interesting to test in future.
    • indymike 4y ago
      > email from my systems go to spam because there is a link in it. This spam filter is broken. A personal email with a signature that contains a blog would be a false positive.
• irjustin 4y ago
  This doesn't work for creation because it's too easy to spoof where the email came from. In the OP's diagram this really hinges on the Mail Transfer Agent (MTA) needs the ability to verify that Mail User Agent (MUA) is legit, and that is quite hard. Realistically MTA would need to go to a known MUA address to verify do you actually own this account? But not all is lost! This does work great for 2FA. Where the contents itself is is the only requirement of trust. Just make the contents unrealistic to copy/spoof and then it doesn't matter who sent it.
• deleted 4y ago
  [deleted]
• peterkelly 4y ago
  The whole point of email verification is to verify that the user is able to receive email at the given address. Aside from the other issues mentioned here, the proposed solution does not achieve this.
  • OJFord 4y ago
    I can't think of anything I've signed up for that would care about the distinction personally, any examples?
    • kayodelycaon 4y ago
      I have *@kayode.co forwarded to kayode@kayode.co. I can only send from kayode@kayode.co and only if I configured my mail client properly because my account is actually a fastmail.com address. Unconfigured, the mail client will send as the fastmail account.
    • remram 4y ago
      I use email aliases that I can't send email from. It's also possible that email from your domain is blocked by mine, and I would never receive that invoice or password reset link. In reverse, there are addresses on my company's domain I can send from but not receive at, and I shouldn't be allowed to sign up with those.
• stormbrew 4y ago
  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.
  • cuteboy19 4y ago
    $Work does not allow outgoing (out of domain) emails but *Requires* signup to a bunch of websites for stuff like provident fund management and stock compensation. This kind of workflow is not possible for those cases They are exchanging inconvenience for lack of functionality
• bornfreddy 4y ago
  A bit off-topic: kudos to OP for clearly explaining DKIM, SPF and DMARC. Awesome short summary!
• withinboredom 4y ago
  And hope there is a human for anything that doesn’t match. People will remember that email and use that to contact support.
• derobert 4y ago
  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.
• systoll 4y ago
  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.
• welder 4y ago
  Email verification is more than just verifying the user owns an email, it also improves the chances future emails will be received successfully.
• gregmac 4y ago
  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=email&user=52942875&uid=6945601f-ce6e-468d-85c9-99b232b0fed3&utm_medium=email&utm_source=email&utm_campaign=verify2208 https://auth1.web04.example.org/app/1042/verify.php?action=e... Good: https://example.org/verify/BC44-5204 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 https://spf-all.com/by-tld.html [1] https://news.ycombinator.com/item?id=19333901 https://news.ycombinator.com/item?id=19333901 [2] https://en.wikipedia.org/wiki/Email_address#Subaddressing https://en.wikipedia.org/wiki/Email_address#Subaddressing
• bennysomething 4y ago
  That whole article could have have been two sentences. Also the problem with it is obvious: not all users have a email client configured. Back in 98 I used to get confused when I clicked an email link and windows would spend ages trying to open up some program called Outlook up!
• jpswade 4y ago
  The obvious reason might be that email verification might be done on a different device.
• ravivyas 4y ago
  Most users have more than 1 email id, some may multiple email apps, in those cases, more work for the user, else it is a 2 click process, 1 for clicking the notification and another for the link.
• gnicholas 4y ago
  On a related note, when users want to connect with me I use a mailto link instead of a web form. This is because after someone fills out a webform, I have to email them, and my email is not-infrequently marked as spam (even though we send <1 email/year to our email list, and are not remotely spammy in general). When the user clicks the mailto link, he starts a message chain and my reply almost always goes through appropriately. As others have pointed out, there are some downsides to mailto links. But I find them to be outweighed by the deliverability benefit that I've seen.
  • nicbou 4y ago
    Email links also lets the person choose the client they prefer, instead of a box in a browser tab. My e-mail client saves my message as a draft as I type, so I can finish my message slowly without fear of losing my progress. I also know that my email client works. Many web forms are broken and only reveal that once you hit submit, if at all.
• unlog 4y ago
  This is actually a very good idea. I'm gonna start implementing it on my sites. If you want your account verified, just email the site with anything or nothing at all. Thanks for the idea! Email verification is a nightmare.
• radu_floricica 4y ago
  I... don't particularly get it. He mentions spoofing, he writes a page about how spoofing works... but says a lot less about how it actually impacts his solution or how to fix it. Besides the fact that implementing a new security scheme means you have to think through every possible path and can be sure you're still missing a few, there are two major issues: - not everybody has SPF or DKIM, and definitely not everybody has DKIM. - both of those authenticate the domain, not the username. Within the local org network I can probably spoof email usernames without much effort. Plus... I don't think mailto links really work universally. I remember the last time I clicked one it opened an unconfigured Outlook, even though I use gmail.
  • cwilkes 4y ago
    Yeah I don’t get it. Is this the reasoning? Email is slow to get to me I use neomutt (there are dozens of us, dozens!) and so links sometimes are wonky. So let’s use SPF and DMARC, something totally outside of a regular email user’s control, to do this task. And hope that it works.
    • woodruffw 4y ago
      > I use neomutt (there are dozens of us, dozens!) and so links sometimes are wonky. I used neomutt for that one example, but the other error modes happen to me regularly on macOS with the system mail client. For example, I regularly (~1/week) run into services that expect the verification email to be opened in the same browsing session, but Chrome "helpfully" picks a different profile. (The point about neomutt was not that services should support my particular pathological case, but that graceful degradation is important everywhere. It used to be common to send multipart emails for exactly this case, but I've seen more and more services choose not to.)
      • ac50hz 4y ago
        In my experience, many developers are unaware of multipart email. Most are unaware of MIME or dismiss it as obvious, old and unnecessary.
  • 4y ago
• donkyhonky 4y ago
  Seems to me like a made up problem. Are there issues with transactional e-mail delivery, just change your provider.
• chunkyguy 4y ago
  I like the idea but instead of mailto which I find annoying why not simply ask the user to send us an email with a hello message? The email address we provide can be unique per sign up if required. So no copy pasting of codes, or having a specific format of the email. We just need to check the sender and recipient.
  • perlgeek 4y ago
    Without a code, there is a pretty high risk of an attacker social engineering an account holder into sending an email. I haven't really thought this through (what an attacker would gain), just want to point out the general risk.
    • chunkyguy 4y ago
      But the code is already part of generated email, the one that the user needs to send hello to.
      • perlgeek 4y ago
        Ah, I think I misunderstood your proposal. Do you want to put the code into the recipient email address?
• renewiltord 4y ago
  I go to website, get mailto link for my work email and send it from my personal email. Then I sit there and wait because there are lots of indeterminate third parties on the way sending my mail on.
• cuteboy19 4y ago
  Getting Gmail to support "verify" in the same way as it supports unsubscribe will make 99% of these problems go away
• edmundsauto 4y ago
  So instead of an HTTP syncronous POST request, you want to trade it for a brittle implementation of a to-be-implemented-standard that requires the sending email client to be on point? And that I will wait while my outgoing email server isn't delayed? And what if I use my ISP provided email, and move? Am I just locked out of accounts? I appreciate the thought process of rethinking our assumptions. But this is not fruitful - the tradeoffs are trivially obvious and unacceptable failure modes.
• grose 4y ago
  Before smartphones in Japan, this is how mobile websites did signups. Every phone had an email address and you verified it by sending a blank email via a mailto link. Restaurants and Karaoke places had QR codes on their menus for this. Seems like this practice died out when messaging apps (LINE) displaced mobile email. I thought it was kind of cool but managing spam filters was a pain.
  • fomine3 4y ago
    Why this methods was popular is because it's hard for user to input their own (and correct!) email address. Mailto link is far easier way to tell the valid email address to a service. Perhaps now is OAuth/OIDC era.
• relix 4y ago
  This ignores many of the main reasons why an application does email verification - to improve chances that the user is not a robot, that the stack is setup correctly, that the user actually can receive and open email, and that the user is who they claim they are. It's not "just" to verify that this user controls the email address.
• perlgeek 4y ago
  Some potential problems: * not everybody has an email client set up that works with mailto: links * sending from an address and receiving emails for an address are very different, and they don't map 1:1 * If you rely on users sending mail to you, the user doesn't know if / when their email is received and processed. They send the mail, try to login, it doesn't work. They have to wait until it's processed, and then forget about your service. OTOH if they receive a mail from you, the mail in their inbox reminds them that they signed up, and as soon they receive it they can use their account. * I doubt that DMARC/DKIM/SPF are actually deployed as widely as OP thinks, and excluding users based on some (to them) obscure/unknown feature of their email provider is bound to generate frustration. If they self-host their email, your support might end up debugging / having to help them with their email setup. * There are some subtleties you have to get right, like verify the MAIL FROM, not the From: header, etc. Email is actually a mine field when it comes to security (it's not specified what should happen if a header is sent twice, so some attackers try to fool virus scanners by finding combinations that the scanner interprets one way, but the recipient interprets another way, etc.) Worse, if a verification fails, it's your responsibility to debug it, and you might have to explain the subtleties to a non-technical user.
  • indymike 4y ago
    > not everybody has an email client set up that works with mailto: links Mostly bad chrome configs where you need to browser plugin to lauch chrome. >I doubt that DMARC/DKIM/SPF are actually deployed as widely as OP thinks, and excluding users based on some (to them) obscure/unknown feature of their email provider is bound to generate frustration. We're at about 30% with DMARC and SPF being deployed in about 65% of email servers. That said, a lot of the really big ones (google, MS, etc...) are in the 30% so are a lot of control panel hosts. Where the slow uptake is, as always is corporate IT departments. Doing the whole DMARC/DKIM/SPF dance isn't hard to do and really puts the clamps on spoofing.
• OJFord 4y ago
  It's a nice idea, and I don't think it needs DKIM either, just SPF? (If the token in the body was maliciously changed to the correct value.. they're too short? All that matters is whether it's correct or not?) But I suppose there'd be many legitimate SPF fails - I see them on email from companies all the time, like they followed half the instructions to bring their own domain to MS/Gmail, and stopped when it 'worked'. OP sounds like the mailto link is going to somehow include SPF & DKIM configuration to solve that? I don't get that bit.
  • woodruffw 4y ago
    OP here. I think you're right that SPF is all that's strictly required; DKIM is technically just "nice to have," since all we need is envelope authenticity + the shared secret. You're also right about SPF (and DKIM) fails, which is why this really isn't all that practical -- it's too easy to misconfigure both and both "fail open," meaning that any service that actually does email verification this way would either need to accept the risk of spoofing from non-major email providers or perform strict SPF/DKIM enforcement (e.g. rejecting email from domains with open IP ranges, even if the domain says it's okay). And that's very hard to do in the general case.
  • remram 4y ago
    My domain's SPF says "email from sendgrid is allowed", which allows anyone with a sendgrid account to spoof me. I didn't set up DKIM because I don't particularly care about the security of that particular domain. But the point is that you can't know how secure the domain is just because it has some security feature present like SPF.
• mdmglr 4y ago
  > Plaintext alternatives are the solution, but support is spotty. Very few people use plaintext email clients. According to campaign monitor [1] 67% of users are using graphical email clients. > Takeaway: Inbox delivery can be fickle, unreliable, or outright impossible. The proposed solution to use `mailto:` is also fickle. Users may not have their email client setup or the right client configured in the browser. Also what about users with multiple email accounts setup on the email client. Those users will need to remember to select the desired from email. [1] https://www.campaignmonitor.com/resources/guides/most-popular-email-clients/ https://www.campaignmonitor.com/resources/guides/most-popula...
  • autoexec 4y ago
    > According to campaign monitor [1] 67% of users are using graphical email clients. That same site also says: "Create a plain text version of your email."
    • mdmglr 4y ago
      Yes in the context of some people don't want html. I would like to know how big that "some people" population is. I suspect it is high in academic/hacker news populations. But from experience most people outside of IT don't know what "plain text" is. I would like to find a source (preferably from one of the big email marketing service providers) that has a detailed breakdown of the clients used.
  • woodruffw 4y ago
    There are probably two sampling errors here: users with accessibility requirements (such as screen readers) might not represented in the survey, and "graphical email clients" run a wide range of functionality (including very, very broken HTML and CSS rendering). Even if 2/3rds of users run a graphical email client, that's still 1 out of every 3 who don't. That's a lot! I agree about `mailto:` and multiple accounts having poor UX, however. It'd be nice if there was some way to specify the "intended" outgoing email identity via `mailto:`, but I don't know if that's possible.
• x62Bh7948f 4y ago
  a common account registration pattern in Japan involves presenting a QR code containing a mailto link. The user scans it, sends an empty mail (the details for the subject are already in the mailto link) and a reply comes up with a temporary user. The user can then define a username or password. Sometimes this pattern creates the username and password randomly.
• prionic6 4y ago
  So having built a few services that offer a signup, it's typically simple to make the service _send_ emails and receive the token through the browser for validation. It's all synchronous with actions that the user initiates. To build something like this you'd need an email inbox, which services typically don't have.
• CamogliX 4y ago
  Why we do email verification ? Is a burocratic vestige no one need or asked for.
  • moogly 4y ago
    Thanks to a certain person named "Sam" in Florida I know that the following companies do not do email verification (and do not have an automated way to fix it with a "I did not sign up with this address" link): Domino's Pizza; Tinder (they at least sent a verification email, but it was a smokescreen); Match.com; Pinterest; Judicial Watch, Inc.; Straight Talk Wireless; Wayfair; Kellogg's and many many more. People sign up with other people's email addresses all the time. In error, or on purpose.
• DoubleFree 4y ago
  In general, you don't verify am email address to prove that the user owns it, but to verify they can receive mail on it, for password recovery purposes and account information. Reversing the process verifies the user can send from the address, which is orthogonal to the goal
• k_sze 4y ago
  I see two problems with the proposal 1. Part of the reason for doing e-mail verification the old way is to ensure the user can really receive messages at the particular address, for purposes such as password reset or e-mail notifications in the future. The proposed novel verification flow only verifies that the user can *send* e-mails, not receive. 2. My phone is configured with multiple mail accounts. I don’t remember whether you can reliably hint at the mail client to use a particular mail account via a mailto link.
• w4rh4wk5 4y ago
  How about not requiring an email address from the user in the first place? Give them the option to enter an email address with a "test" button next to it.
• edf13 4y ago
  Huh, just like he’s had multiple browser sessions open - I have multiple email accounts and don’t want to send this reverse verification email from my client… I also don’t want my full signature shared. The reverse way is way worse for me.
• avodonosov 4y ago
  Why do we do email verification at all? The only legit and practical reason on most web sites is to be able to restore access if you forgot the password. So just near the password field we can have a "Restore options" section, with email, phone number, etc fields; each having a Test button. If user have entered email address he can use the Test button and receive a confirmation email, with a link. When user clicks the link, we mark the email as confirmed in DB. Also, as long as the user does not have a [tested] restore option, we can show him some indicator, like a small red circle on his profile symbol with a tooltip "no restore option configured". Doing the test email in reverse for me personally would be annoying, because I do not have and do not want to have a configured email client.
  • ac50hz 4y ago
    Many sites I work with use email to communicate information to a user that would otherwise require them to remain on the site to receive such notifications. Email forms an essential part of the workflow so ensuring that process works from first contact is critical.
  • awinder 4y ago
    Most webapps have a need for transactional messaging of some sort. But even putting that aside you’re missing TOS support. Every TOS is going to have conditions that define scenarios where you need to communicate with users. Including changes to the terms of service ;-). Or for breaches of data, you’ll want/contractually need to communicate that to your users. So yeah you could build different options for all of these things, and maybe snailmail users of these TOS occasions. But the system of doing this over email is so standardized that the possible friction of one-time setup pails in comparison to the alternatives.
    • avodonosov 4y ago
      Good point about TOS, that's indeed an important use case. However usually TOS declare that it is a responsibility of the user to keep up with changes. Good service providers also say they will make a reasonable effort to inform the user about the changes. So the TOS update notifications is not a complete blocker for my approach. What do you mean by transactional messaging? Could you give an example?
• ThomasMidgley 4y ago
  Because using one mail adress per service with catch-all would not work.
• ay 4y ago
  …because spoofing the “From:” of an email is an order of magnitude easier than intercepting who it was sent “To:”.
• donmb 4y ago
  We send temporary passwords by email. So we reach two goals: 1. User can Login immediately 2. User email is automatically verified because if the email is invalid, he never receives the temporary password
• lakomen 4y ago
  Or, like I wrote on the Go+ community back in 2014, and what Microsoft does, you don't have to remember a password, but every time you have to log in a "password" mail is sent. So the verification process isn't necessary anymore.
• cromantin 4y ago
  We’re (fx.gl) using it in all our games to create a connection between game account and email. It works great. User click on mail to link. Send email with uniq token. Sever receives email and connection is created. Some caveats: 1. not everyone has email set up on phone. We provide instructions to send email by hand. 2. We emphasize for user to choose correct email if they using work and personal email. No good solution here if user connect game account to work email. Only letter to support
• kahnclusions 4y ago
  The ‘mailto:’ thing is a dealbreaker. A _significant_ amount of users, especially non-technical ones, won’t have a properly configured email client. They’ll click signup, it’ll open Outlook or Apple Mail, and then they’ll give up on your app in frustration because they can’t register. There’s very limited room for shifting the signup paradigm in a way that won’t leave N% of your potential users unable to sign up.
  • clarle 4y ago
    I think this is the big one. On iOS, I don’t think most non-technical users know how to switch their default mobile Mail client if they use another alternative like Gmail or Outlook.
• fefe23 4y ago
  This suggestion makes things worse. If you make a service and ask for email validation, you want validation that the user has that email address. Since anyone can spoof e-mails from any address, getting an email from the address is not validation for anything. You need to send an email to the account and get a response to validate the email address is real. Otherwise it's trivial for me to go to any web site and pose as you. All I would need to do is spoof your email address. Edit: I agree that the current state of affairs is unsatisfactory :-)
• nickjj 4y ago
  I like that there's still options out there around authentication that I haven't seen before but this method is hostile towards folks without a dedicated email client. Personally I only ever login through web mail and have no client so `mailto` isn't a shortcut. I still think magic links are a good compromise. With a user / pass you still need to verify your email as a separate step. A magic link sends you an email and you're technically verifying your email every time you use it, so it removes an extra step. It's also really useful for being able to login from multiple devices without needing to keep your password synced with a multi-device password manager. That's especially handy on mobile because even if you're around your desktop with your password manager who the heck wants to manually type `pm'TWZS"$G39c(Es:k@v3-*IhP#DUbows:=='"Z],Ud"R8XO` as a password into your mobile phone? Lastly, it lets you put the burden of MFA on your email account. If your email account is protected by MFA then your app using magic links is protected by MFA. It means users don't need to give out their phone number or hook up another site to their authenticator app. I really don't understand why so many folks hate magic links. They solve a number of problems in a pretty reasonable way at the cost of having to wait 5 seconds for 1 email to verify your email at which point the site can set a cookie for a year and you don't have to deal with logging in by email for another year. You can also protect sensitive actions by requiring folks to verify their email to replicate how a site might ask for your password to do something like change billing details or whatever makes sense for your app.
  • scrollaway 4y ago
    Magic Links mean that if there is any issue with any of the email servers in the chain (which there often are), my ability to log in to the website may be delayed by 10, 20, maybe even 30 minutes. It’s unacceptable and everyone I know who uses magic link has eventually given up on them due to user unfamiliarity and a variety of issues such as this one.
    • nickjj 4y ago
      > Magic Links mean that if there is any issue with any of the email servers in the chain (which there often are), my ability to log in to the website may be delayed by 10, 20, maybe even 30 minutes. This same exact thing happens with a username and password driven site because almost all sites (rightfully) require you to confirm your account after sign up by clicking a link in your email.
• croes 4y ago
  I use email addresses that only forward mails to my real address, so I can't use them as a sender email address
• sagebird 4y ago
  Another way to authenticate email is to provide your email address and password. This has the advantage that you do not need to receive or send an email. There may be downsides as well, but I cannot think of any ;-)
  • remram 4y ago
    Or use OpenID Connect.
    • dane-pgp 4y ago
      That also has the problem of making your identity dependent on a third party, unless the site accepts Self-Issued identities, which is an interesting extension to OIDC: https://openid.net/specs/openid-connect-self-issued-v2-1_0.html https://openid.net/specs/openid-connect-self-issued-v2-1_0.h...
      • deleted 4y ago
        [deleted]
• shp0ngle 4y ago
  Ugh. For me, mailto link will open… some old forgotten mail application, that will start downloading… 5000 e-mails from my gmail account? or something? and mark them as read? maybe? I don’t really know, honestly. I always copy-paste mailto links to Gmail.
• ique 4y ago
  There are essentially no applications that require email. We should just stop doing email verification altogether. If you need to have a separate communication channel with your user just establish that separately after signup.
  • remram 4y ago
    Password resets. People forget their passwords all the time, and you don't want to deal with support emails and explain that they should have set an email in their security settings, so now they can't get back their their Twitter/Discord/Facebook account and there's nothing you can do (or will do).
• longrod 4y ago
  I think this is a good idea ONLY as a fallback. Email deliverability is a very real problem even if it happens to only 1% out of 99% of your users. What happens when a customer emails saying they can't verify their account because they didn't receive any email? It'd be quite seamless to offer this as a secondary option.
  • remram 4y ago
    When you get an email without DKIM or SPF, how do you explain to them that they need to change to a supported email provider even though yes you did receive the requested sign-up email?
• jstanley 4y ago
  > I’ve repeatedly dealt with services where the verification email [...] is marked as spam Spam filtering in email is performed on the receiving side. You're the recipient, so if your spam filter is filtering emails you want, it's your spam filter that is defective and you are the only one who can solve that.
  • OJFord 4y ago
    That's at least debatable, I send SPF failures to spam, which obviously catches some legitimate stuff, but at very least that's the sender's problem too.
  • woodruffw 4y ago
    This is simultaneously true and not useful: most people use an email provider, and the provider dictates the spam policy. Aggressive policies are competitive, because spam annoys users more than the occasional missed message.
    • vbezhenar 4y ago
      > spam annoys users more than the occasional missed message. For me it's the other way around. I don't care about occasional spam. But the possibility of missing message means that I'm forced to read ALL spam periodically.
      • woodruffw 4y ago
        I think there's a paradox here: I also don't care about occasional spam, and the possibility of missing messages matters much more to me. But I probably wouldn't select an email provider with no spam protections at all, and Google is optimizing for new user registrations.
• amelius 4y ago
  Why do we even need email verification? I don't want to allow a website to link my identity to my email address or phone number. I don't want the website to push me messages. I am capable of storing passwords, so no need to send me password recovery emails. Email verification should be optional.
  • Jyaif 4y ago
    Because services don't want to be spammed with fake accounts.
    • amelius 4y ago
      Could you be more precise about what you mean by "fake" accounts?
      • rvba 4y ago
        One person making multiple accounts to abuse the service. For example by spamming it.
        • amelius 4y ago
          Professional spammers probably would know how to set up fake email addresses.
          • rvba 4y ago
            You underestimate the number of people who are bad and technically incompetent. Such basic things can stop a lot of idiots. I guess you still lock your house even if proffessioanal thieves can pick your locks. 99% of thieves are not proffessional.
            • amelius 4y ago
              > I guess you still lock your house even if proffessioanal thieves can pick your locks. No. I'm hoping that lock-makers work with professionals who do pentesting on locks.
• folli 4y ago
  Throwing it out there: does anyone know where I can find a copy-pastable template for Spring Boot to integrate a classic sign-up workflow in my web app. I hate to reinvent the wheel here...
• rvba 4y ago
  Author does not understand how many clueless people are there. Setting up an account is allreqdy a problem for a lot of people (both old and young people can be very non technical). This new system will often not work on a personal computer - those often dont have a configured mail client. All is done via web. Also I can easily see this abused by tons of spamers, where every spam website will have a mailto: popup trying to catch inexperienced users - to reveal their emails.
• clement_b 4y ago
  Guy calls current flow clumsy. Comes up with alternative reliant on mailto :)
  • woodruffw 4y ago
    One man’s hack is another man’s bodge!
• antioppressor 4y ago
  Oh, the "curse" got this individual too. "Is it a good idea? I have no idea;" Great, why the article then?
• Laarlf 4y ago
  I have a catchall. Sending mails is a bit annoying... I like not having to send a mail because I can easily avoid spam if someone misuses or sells my information because GDPR only hits small people and not the corps that deserve it. While yes, it may be slightly more annoying to create accounts, maybe that is a good thing. Because then you don't create an account at every possible site.
• somehnacct3757 4y ago
  I don't know what mailto links would open on my computer but it's not my web-based email client. I think it opens a local executable that came installed by the OS? I don't even know what email address that thing is tied to. DKIM et. al. security concerns aside, I don't think a mailto link will be easier to use because the web server doesn't control the user's configured handler for mailto links and there's a lot of ways for that link to go unhappy.
• SergeAx 4y ago
  I will rant here a bit. I say: let them experiment. Let this guy implement his clever scheme and see how spam bots population increases several folds and conversion drops 10-15%. If he knows what conversion is and have a metrics for it. And knows what metrics are, also. And if spammers are interested at all in his product. Or whatever. Also let the legion of newbies and dilettantes vote articles like this to the moon and higher. Let it sit in top 1 HN for weeks. At the end, isn't it a creativity and smartness we should praise and encourage? This is Hacker News, home of brightest startup ideas. After all, it is good for us, old and inert creeps. Ones who knows what metrics are, how to collect, store and analyse them, how to implement A/B test, and what "statistical significance" means. We still will have several open offers even when all the code would be written by GitHub Copilot, all the texts by GPT3 and all the art by DALL-E. Forget about retirement, folks, there are interesting times ahead.
  • Banana699 4y ago
    Why so extremely aggressive?
    • SergeAx 4y ago
      Because I used to reap HNs first page rich of great content, but lately it becomes more and more lame, like this one, or repeating same old stories. It is disappointing and annoying. I have no explanation other than upvoting crowd became meh.
• kretaceous 4y ago
  For all my service sign-ups, I use [service-name]@[mydomain] as my email which redirects to my GMail inbox. My sending address is still my GMail. How will this solution tackle the given situation?
• _8j50 4y ago
  Guys,it's 2022! You shouldn't be requires to give out your email right along for verifying anything. Please allow the old dog to die. Site generated communication should be entirely optional, and even then why not support signal,whatsapp, slack,discord,etc... (as a library of course). Fight spam? Use captchas. What I found out is email registration is very difficult without a phone number which in turn requires a government ID in most places. So email verification has become a lazy way to require govenment IDs for even the most basic sites. It is all built around user hostility. I have added items to a cart,tried to check out and then decided to cancel the whole thing because they have no guest(no-email) check out and require email registration several times this year. Why would they not just take my money? My payment itself is verficiation of anything email can verify? It is so stupid! Imagine being asked for your phone number and then they call your phone to verify it at every store or business you went to in person. I challenge any commercial site owner to prove that email registration improves their botrom line. For non-commercial sites, please understand that you are being needlessly hostile to your visitors, use federated authentication and provide a no-email registration path. Personally, I think registration itself is outdated. You want users to buy something or generate content on your site. You can still call it registration if you want but you don't need to do more than the bare minimum of authentication which when federated can mean not storing anything new or special about the user other than their login session and associate their content with the identities associated with that session. For example, if HN with github federated, this post and my submissions would be under my GH identity in HN's db, if I want to setup a HN profile, that too would be under that identity. Unless you have a specific need for it, there wouldn't be a table of users with my identity in it. Lastly, for those that use email as part of an authentication workflow: understand that the use's email security is now your responsibility, because even though you transfered risk lack of options means you are responsible for mandating email as point of failure. So if a user gets phished and damage is done on your site, your site is liable unless you are also providing email security training. There is a reason secret questions exist (although I don't like them), you are not suppose to allow control over an email account as the only factor of authentication requires to reset login credentials. The whole 2FA setup is meaningless if you do that.
  • remram 4y ago
    People forget their passwords. If you do more than sell stuff one time and the user really need to get their account back, you need a way to send them a reset link or code. No way around it.
• anothernewdude 4y ago
  > opens up your email client What the fuck?
• ukdevguy 4y ago
  I like this idea of reverse email verification. I have a gmail account that I have long since abandoned due to other people signing up for accounts and using my address. If they actually had to send an email from the address to sign up then I probably wouldn't have abandoned my address as quickly.
• alkonaut 4y ago
  mailto:links for most people just open up some associated email client which they never used before and which isn’t associated with their email account (which they check via a web page like gmail). So mailto: is a non starter. A standard that just doesn’t do what a developer might think it does.
• xkcd1963 4y ago
  I'm late to the party but I think we cannot let the client know the secret token
• bob1029 4y ago
  I think that complexity is the #1 problem here. This is a clever way to confirm user emails, but it's also inviting additional universes of bugs and confusion to the party. For me the answer is a simple question: Would the author (or anyone here) be happy to support the proposed reverse email verification process in a production environment which interfaces with the general public? For the sake of forcing the argument, assume the service being accessed is Really Important and failure is generally unacceptable.
• adrr 4y ago
  This would cause so many issues in a time when most users use webmail. The magic link in email works, why change it for 0.001% of you users who happen to use a command based email program.
• cassepipe 4y ago
  I don't understand why people complain about the mailto: option. Whichever after or before, people will need to open up their mailbox to have access to their newly created account, no matter what, so it does not change anything. The account creation page could easily provide a plain text email as an option, copy/paste the address, copy paste the code you've been given to send and off you go. Or it could provide both options. Link clicking and mailto. Not great but else you can configure mailto:handling on any browser/OS
• remram 4y ago
  At a high level, you have to validate what you need. If you don't need the user's email address, don't validate it. If you need an address the user can send from, validate that they can send from it. If you need an address they can receive at, validate that they can receive on it. Beyond security problems, there can be all kinds of other failure modes. Maybe my domain is blocking email from you. Maybe the address I want to use can't send. If you need the address because you'll be sending password resets and invoices to it, you want to validate that they can receive there. It was never about whether they "own an email account", whatever that means.
• joegahona 4y ago
  I A/B tested this exact flow at my last employer, and it lost. I didn’t follow up with user interviews or surveys, but my guess is people were creeped out by their email client opening out of nowhere.
  • woodruffw 4y ago
    This is something I hadn’t considered! I could definitely see that spooking less technical users.
• Ayesh 4y ago
  The massive inconveniences others have pointed aside, it will be a technical nightmare to implement too. Incoming email takes a _lot_ of moving parts to process. What could have been a simple http get/post/redirect forms now need a process to accept and parse incoming emails, and someone inform the page about verification status. There are plenty of existing libraries and software to do it, but it's really difficult to get right. Incoming emails in qprint, plain and html emails with boundaries, spoofed emails, separating verification emails from regular emails, etc there are so many complexities involved. In addition, it is difficult to write unit tests for them, and integration tests wouldn't be solid either. All of these technical complexities to beat a paradigm that billions of users are used to, with no obvious improvement.
• deleted 4y ago
  [deleted]
• wootest 4y ago
  Ignoring every other benefit and concern, verification in the way proposed is a bad idea because part of the verification process in most cases is verifying that the service can send messages to you that actually get delivered. If you do this and then send the first "log in link" email which gets held up as spam or putatively malicious since some server has the temerity to not be located inside the US, doesn't have a DKIM signature, etc, you haven't really verified everything that you need to know. Of course, those things can change at the drop of a hat anyway, but I'd rather have verified that 1 time than 0 times. If all you do is use it for login and will never need to send a message, then fair enough, the email is just essentially a random string you can prove ownership of, and your ability to send messages that will be delivered to the corresponding mailbox is incidental. But that's not a general enough conclusion to hold for why "we" (all cases) should do it that way.
  • throwoutway 4y ago
    In most cases, I don’t want the service to send me emails (spam)
    • wootest 4y ago
      That's fair but in a lot of cases you verify the email for your account and there is activity associated with that account. There are many reasons other than to send unwanted marketing emails for the service to need to get in touch with you, including the many cases where you're entering the email address because you want to be notified of something.
• maxerickson 4y ago
  The flow diagrams leave out the "treat the account as verified and start sending messages anyway" that lots of companies do. Then you ask them to remove your email address from some other persons account and instead they delete the account. Fun times.
• awinter-py 4y ago
  I run a product using email verification that's currently failing in all the ways on the list I chose it because it's less complex than oauth, and (slightly, in theory) more convenient than user-password. My wishlist version of oauth is for a slightly different protocol that 1) doesn't require the product to create an account with the id provider, 2) doesn't allow the id provider to block sites, 3) doesn't let the id provider see where the user is logging in
• zajio1am 4y ago
  The scheme supposes mailto: scheme works (by web browser starting MUA after click to mailto: scheme link). I cannot imagine that is true for majority of people. Perhaps it worked in the past where people used real MUA application, and such MUA is configured as default handled for mailto: in their OS, but today when people mostly use web-based MUA and browser/OS has no idea about it, i would expect it mostly does not work.
  • sp332 4y ago
    It does work. Gmail has been popular enough for long enough that everyone makes sure this works.
• brightball 4y ago
  I actually tried something similar to this on a small social networking service about 5 years ago. There was a requirement for people to interact with their groups via email by replying to other emails or by sending a message to an email address for the group. For both of these, I made the case that we should require the incoming emails to pass either a domain aligned SPF or domain aligned DKIM check (essentially what DMARC would do). Since most people are going to be using a 3rd party email service, this just works by default. If they aren't, we shouldn't have any issue with forcing this requirement as it meets absolute basic email standards. The higher ups let me do it and we ended up creating an instructional email that would bounce back to failed messages with the reason why, an explanation that we couldn't risk someone being impersonated on the platform and a suggestion that they use the app or website to interact until the issue could be resolved. In the short time that I was there after that feature launched, we never ran into a problem.
• holyknight 4y ago
  Sounds like a good idea to explore. Glad to hear some new ideas on these kind of flows that usually never get any improvement.
• kazinator 4y ago
  This is quite wrong. The purpose of e-mail verification is to validate that the user creating the account controls the specified e-mail; that he or she can receive at that address. This author has created a silly flow whereby the user proves that they are somehow able to use e-mail to reflect back some authorization cookie to the server. You can do that without even having an e-mail address; any Internet-connected host can send e-mail, using any sending identity it wishes. The fact that you can contact my server via HTTPS and via SMTP, and relay some information between the two, means absolutely fiddlesticks. > The “reverse” flow should make intuitive sense: we’re proving that the user controls the specified email address by challenging them to send us an email from it. Right; here is the core misconception on the part of the author: that receiving an e-mail from someone proves that they control a certain e-mail address. (Imagine the flow being used for password recovery, yikes! Anyone forging an e-mail from you gets your account?) The second problem with this idea is that it increases the server complexity. Now it has to process e-mail. Conventional e-mail validation doesn't have to receive e-mail; all it does is send confirmation mails. Which, I repeat, any Internet-connected host can do; and it can do so without becoming a mail server. A third problem is user experience. It complicates things for the user. The handling of mailto: URLs is tenuous. Not everyone has it set up correctly. Many users have some webmail account like Gmail, but when they click on some mailto: URL, some default application comes up that doesn't use their Gmail account. They don't use that application and are prompted to set up that application.
• kasajian 4y ago
  This argument is silly. How many people are using text-based e-mail clients who are also using etsy? And the article also ignores the problems with the mailto:// link. cmon. The solution likely has more issues than the problem it solves.
• joelthelion 4y ago
  Side question: how do you deal with authentication/registration for small projects? Doing it myself sounds like a lot of work. But alternative services are either expensive or don't give users good privacy. What do you guys use?
• Merovius 4y ago
  > In both cases, the proof is the same: “email verification” means “the user controls an email address.” No. In one case the proof is "the user receives E-Mails under this address" and in the other it is "the user can send E-Mails under this address". The service is generally interested in proving the first. For recovery, service-related notifications and for unsolicited marketing. So all the things mentioned in making the "normal" flow undesirable, are actually exactly what the service owner wants to protect against. If their E-Mails don't get to you because they end up in spam or just get dropped by a misconfigured Mailserver, they can't spam you and you won't be able to use this account for recovery. I agree that the reverse flow is easier (though TBF, mailto links also require the user to have set them up to work, which not all users have on all their devices). But I don't think that's where the incentives align.
• somenewaccount1 4y ago
  For all the reasons mentioned here, and some the author wavy-hands away, this is a bad idea. None the less, I learned more about email spoofing from this article then from any other, so it's a nice read.
• groby_b 4y ago
  We don't do it in reverse because sender addresses are fairly trivial to spoof? What email verification proves is your ability to read email (which means password possession), which is much harder to fake.
• paxys 4y ago
  Seems like a bizarrely convoluted solution in search of a problem. Sending a verification email and clicking on a link in it works perfectly well for 99.99% of users. This new method increases friction by several orders of magnitude.
• subless 4y ago
  I’ve had similar issues of not receiving emails before and it’s annoying especially if you’re trying to do password resets. I like the idea the author is taking about although I’m not too techie with all the details. If I tried this “reverse” approach I would do it this way, After the user creates their account, simply generate a unique token and tell the user to simply copy the token and send it back to a specific email address controlled by me with the token as the subject line and the body is ignored. This way the user sends the unique code from the email address they want to use so we know it’s them cause how else would they get the unique token. Is it 100% fool-proof? No. But most things humans touch is not secured 100% anyways but I’d like to think it’s a start.
• cx42net 4y ago
  I think @simonw clearly explained the problem around the login flow: "resist the temptation to innovate around login!". But I'd like to add more from this. First, this will always depend on the product you offer. If you target highly specialized tech people, why not, they are most often open to changes. For the rest, it won't never be a good idea. We tried implemeting a "one time login link" at ImprovMX, like a few others commented here. One drawback we saw was a surge in support requests from people having issues receiving the email, or not understanding how to connect. We could debate on this but definitely, doing something "original" was not a great idea. But regarding the suggestions made by the original post, I can clearly see a lot (A LOT) of issues: 1. Changing the flow from what the users are used to: Clearly, once you have entered your email and password, you are expecting to receive an email. It's probable that a small percentage of users will close the window once they see the next page asking to send an email, without even reading it, loosing the "mailto:" link with the special token. They will also be lost on what to do; They'll expect an email, and won't understand the need to send one. In a more broader sense, changing the flow will require the users to think harder than usual on what to do, causing more users to leave and never finish the registration form 2. Matching the proper email If they happen to click on that mailto, they will have to remember which email they entered in the form, and will have to keep that in mind when sending the email. For me, if I click on a mailto, I'll have a GMail tab open to send that email, and I have 5 aliases registered. It will require an extra caution to select the appropriate one. 3. Having that email available If the user registers via his phone using an email not configured on that phone, he won't be able to send an email on that "mailto". This will require to copy/paste the link (and copying a mailto on a browser results in A LOT of changes on what is copied), find a way to share that copied data onto a device that has the appropriate email configured. 4. Custom emails Some users enter their email using the specialty of Gmail, such as user+label@gmail.com. When they'll send an email, they won't be able to add that "+label", causing the account creaton to fail 5. SPF/DKIM/DMARC, seriously? Wrapping your head around how these 3 standards works requires significat efforts. And yes, without them, you can not guarantee that the email is truly send by that domain. But still, many custom domains doesn't have a proper DMARC implemented and they can still spoof your account creation. In order to avoid this issue, the only best way is to keep the original flow : the services sends an email to the one the user gave. Definitely, this is not a good idea to implement for so many reasons, but I agree on the original thought: The current flow has its own issues that needs to be resolved. One flow I prefer, that doesn't fix everything but still remove a lot of headaches, is to send a code by email when the user has hit "Create my account". The next pages shows that the service expects the code sent by email. Once the user receives the code by email (ideally, having the code in the subject), they can enter it in order to validate their account and they are then automatically logged in a fully activated service. This removes a few issues, such as: Not having the email account configured on the same device Ending in a splash page right after creating an account Ending in a splash page when clicking on the link in the email Havign to connect to the service even though you did all the proper validation (I hate that) The only issue remaining is to ensure the email arrives quite fast. But as long as we need email verification, we will have a hard time fixing this, as it is outside of both the service, and the user hand.