24 ms·

The Correct Way to Validate Email Addresses

• RomanProofy 10y ago
  what about proofy.io I myself used for verification mails
• amk_ 10y ago
  TL;DR the odds that the user entered an incorrect-but-valid address are way higher than that they entered one which will not actually be able to receive mail. Send a validation email.
  • tempestn 10y ago
    Also relevant was, "If you have a well laid-out form with a label that says “email”, and the user enters an ‘@’ symbol somewhere, then it’s safe to say they understood that they were supposed to be entering an email address." In other words, it does make sense to check that they entered an '@' symbol somewhere, since it shows that they understood it was an email field. Any 'validation' beyond that is useless.
    • danso 10y ago
      How about more than one @ sign? Does the email address spec exclude the possibility of more than one @ symbols?
      • kej 10y ago
        Nope, that's valid if one of them is quoted: "very.unusual.@.unusual.com"@example.com
      • deleted 10y ago
        [deleted]
      • tempestn 10y ago
        It doesn't matter. If they have typed an @, they probably understand that it's an email field. Trying to validate to the spec beyond that is pointless, for reasons thoroughly covered in the article.
      • zeveb 10y ago
        The local-part may contain a quoted @: "@"@example.invalid is a valid email address. @ signs are also permitted in comments: (ted@home)ted@example.invalid is also a valid email address.
      • ediblenergy 10y ago
        It actually used to (maybe still does) signal routing information[1]. An example from the RFC is "@ONE,@TWO:JOE@THREE" [1]: https://tools.ietf.org/html/rfc821 https://tools.ietf.org/html/rfc821
  • pbreit 10y ago
    Address validation by sending an email should only be used if it is required for some reason to verify the user owns the email account. Otherwise, it's not a great UX.
    • gregmac 10y ago
      I honestly can't think of a reason you'd ask a user for their email but not need to validate it. For being able to do password resets later, permission to add to mailing list, avoiding sending private info to the wrong user, avoiding allowing someone to masquerading or impersonate someone they're not.. All should be validated. If you're looking for a username as login identity and nothing more (and you don't have password reset functionality), then ask for a 'username', not email addresses.
      • vacri 10y ago
        email addresses for usernames have the advantage of already being unique. None of this "gregmac already taken, try gregmac23, gregmc_595, or verbingnounXX instead?" nonsense
        • zAy0LfpBZLC8mAC 10y ago
          > email addresses for usernames have the advantage of already being unique Not true. There are people who share an email address.
          • niij 10y ago
            Care to expand? As in having a first.last@example versus firstlast@example
            • mabcat 10y ago
              As in bloggsfamily@localisp.net.au that both parents and all the younger sprogs share. Still common as anything.
  • wyldfire 10y ago
    For flip's sake, yes please! Close the loop, fer crying out loud. I got a popular givenname.familyname@gmail.com address and I frequently get mail that's meant for other people who share my name. The vast majority of the time it's the individual themselves who sign up for a service or offering but there's rarely a validation upfront. The best emails are the ones who extend full trust to the email recipient over some account during that first email. Facebook, shame on you.
    • lucb1e 10y ago
      > The best emails are the ones who extend full trust to the email recipient over some account during that first email. [Random company,] shame on you. Well what else would you have them do? Have people enter their address and send letters there to do a password reset? A confirmation email before full trust is going to do little: a malicious person would just click that link, right?
      • wyldfire 10y ago
        Someone could have just created an account and accidentally put the wrong email address in. Therefore, putting a link that extends full trust in the welcome/confirmation email is a design error. The fix for this error is to require the newly created account holder to put in their password on this first login. While the account's in this state it shouldn't be possible to reset the password.
      • deleted 10y ago
        [deleted]
    • CRConrad 10y ago
      Mine is firstinitialmiddleinitialfamilyname. There are an amazing number of C. R. Conrad's in the world -- mostly the USA -- who seem to think they own that address.
  • CRConrad 10y ago
    Yup,waaay higher. And when they do, it's usually mine.
• KennyCason 10y ago
  Fully knowing where this was going to conclude, I still found myself reading through the "lets build a stats model" part. I just had to check my calendar to confirm it's not April 1st. :)
• deleted 10y ago
  [deleted]
• omarforgotpwd 10y ago
  I first encountered the idea of email validation in Agile Web Development with Ruby on Rails, which I read in middle school. In the book they give an example of validating email addresses to show how you could use regex to validate. I wonder if that contributed to the frustrating problem of developers trying to validate emails and not accepting valid inputs.
• cyberferret 10y ago
  As an aside, I received an email from a government department recently that had an '&' character as part of the email address. I didn't think that was valid, but lo and behold, when I checked the specs, it IS indeed a valid character in an email address. Just goes to show that assumptions are often wrong, and you have to crack open the spec document from time to time... [1] [1] - https://tools.ietf.org/html/rfc2822 https://tools.ietf.org/html/rfc2822
  • lucb1e 10y ago
    I have a feeling somewhere on the Internet is the story of the sysadmin who got the request from that department for an email address with an ampersand. S/he probably stopped themselves from replying "uh, that doesn't work", tried it, and then learned it's valid.
• SamReidHughes 10y ago
  There are other situations where you do have to guess whether a string of data is a "real" email address or if it's some garbage data that turns up in information systems. "Validating" email addresses (without emailing somebody) is a real problem. By the way, maximizing the accuracy of such a guess can require going against the standards.
• tedmiston 10y ago
  From the perspective of a user typing their own email address correctly, I use text substitution on OS X and iOS to never type my full email address. ex fg --> foo@gmail.com
  • homero 10y ago
    fg
• brightball 10y ago
  This is the best comprehensive way that I've found: https://github.com/kdisneur/email_checker https://github.com/kdisneur/email_checker It breaks down into 3 parts that can be used either independently or as a whole: format, MX and SMTP.
  • kej 10y ago
    That one fails " "@example.com and test@example, both of which are legal. Also, since it relies on looking up MX records and then making an SMTP connection to check if the user exists, why not just send the confirmation email? You've already done all of the expensive stuff at that point.
    • brightball 10y ago
      You haven't had to bother the user yet. Also, shouldn't example.com fail?
      • kej 10y ago
        I meant those both fail on the format check, when they are legal formats. You are correct that they should fail the MX portion.
  • zAy0LfpBZLC8mAC 10y ago
    That's just broken, the DNS lookups are wrong, the SMTP implementation is defective, I didn't look any further.
    • brightball 10y ago
      How so? If you could correct it how would you feel about the approach?
      • zAy0LfpBZLC8mAC 10y ago
        The approach of attempting to deliver a test email synchronously and seeing whether that fails? That's fine in principle. After all, it's in principle just what the MTA would do once you actually sent the email, and what would cause the MTA to generate a bounce message in the case of failure. The practical problem is essentially the same as with all the syntax validation out there: It's extremely likely that you are getting it wrong, thus, once again, rejecting valid addresses because your implementation is buggy and behaves differently than an actual MTA. As for the how so: Because somebody obviously, as is so often the case, just made shit up and implemented that instead of reading the relevant standards and implementing what they say. That's how most of the interoperability problems out there start: People have some passing familiarity with some protocol or data format, and then they implement code handling that protocol or format based on their idea of how things work, instead of what the standards actually say. That's just how we end up with people rejecting email addresses that contain "+" characters in the localpart. I mean, RFCs are public, what more do you need? If you want to implement an actual email address validator, you don't have to pay anything, you don't need to sign up anywhere, you just have to read it, and you can actually build a reliable email address validator, and there is nothing wrong with doing so. Yes, that is more work than just implementing your fantasy protocol. But if you can't be bothered with that, then just forget it and use an existing implementation by people who did care--namely, use an MTA to send a verification email.
• jwecker 10y ago
  I always assumed it was more a sanitization issue for security's sake. By allowing only a simple subset ("common") email address type, you can be ambivalent about what email server is running and how it reacts to the wide variety of specially crafted email addresses. With no validation other than sending the email, you have to know, for example, what the server would do with an email address that claims to be @localhost. Now it becomes a problem- or at least a question and concern- for the backend system. Whether the backend interprets root@localhost as valid and does exactly what it's told or rejects it due to some configuration- it has become a backend complication and a DOS attack vector. A simple policy of only handling a subset- the common class of email addresses- is one of the things that allows us to have a simple mental model of what the MTA is supposed to do. The fact that it sometimes caught a type-o, or not, is incidental. "Invalid email" wasn't meant to imply the email address doesn't fit the spec- it was meant to imply that a particular site or service has chosen not to accept email addresses like that. Or at least that's what I assumed :-)
  • kej 10y ago
    And that's a great philosophy until your email gets rejected by some service that picked a different "common class of email addresses" than you did. This is precisely why we have written standards.
    • jwecker 10y ago
      Back when SMTP servers still had remnants of UUCP etc.- where the address could actually contain characters that specify intermediate servers to route to, I would have argued that front-end sanitization was important as, for example, html sanitization from end-users from a security perspective. However, IETF made lots of progress simplifying things- to the point where, at the very least, the standard tells us specifically that we should leave it up to the destination host to interpret the local part of the email address-- that is, the thing to the right of the @ should be given the thing on the left unmolested ideally- even being ignored by intermediate relay servers. Since that's what most people complain about, any validation to the left of the @ should become extinct. But off the top of my head that still leaves the thing on the right of the @ (such as localhost), buffer overflows by allowing longer strings than the standard allows (those limits do exist), and the problem with multiple @ which the MTA may or may not handle well... Since I'm not a security expert I'm going to go out on a limb and assume that I'm missing a bunch of other things. My point is not that the article is wrong, though- my point is that if he wanted to convince me to only validate by sending the email on any string, he should convince me that those security concerns are not an issue- not that it's not good at catching type-os.
• maxerickson 10y ago
  Yes, please do send activation emails (or perhaps a personal confirmation email if you are establishing contact with someone that wrote down an address for you). Those of us with firstnamelastname@commonhost will appreciate not getting bills and job offers and such.
  • JshWright 10y ago
    I've been getting monthly status reports from some guy's Hyundai for months... The unsubscribe link does nothing... I'm tempted to reset his password and change the email address.
    • kevin_thibedeau 10y ago
      Password resets are the only solution. I did that years ago when someone signed up for a Facebook account with my address and I kept getting friend notifications. I let it go for a few years and Facebook was happy to keep an unvalidated account active the whole time.
• justinator 10y ago
  In Dada Mail [0], there's quite a few steps to figuring out if the email address submitted for a mailing list subscription is valid, but most of it can really be organized under sanitizing the data you receive, which you should be doing anyways. Yes, we do validation for form of an address client side (which helps with hitting the server side so much), but we'll do it again server side. We also look at stats on how many times an address was submitted before, as well as per ip address over time across all fuctions of the app (as well as specifically for subscribing). Oh, and even if it's valid, and "real", sometimes we don't want to work with it either, ie: it shows up on something like StopFormSpam. It's actually a ton of work and much to orchestrate. [0] http://dadamailproject.com http://dadamailproject.com
• JacobJans 10y ago
  I do a lot of optin email. Here are some examples of bounced emails that people use to sign up: * somename@gmail.co * anothername@yhoo.com * myemail@hotmial.com These are very common errors that occur nearly every day. A regex isn't going to help here. What does help, is a notification that asks people to verify what they typed –– if the email contains an obvious, common error, such as one listed above.
  • gizmodo59 10y ago
    Asking to retype though being a simple solution IMHO is asking for a lot. Consider a user who uses mobile phone, even copy paste is annoying. Validating if the mail box exists and that it does not belong to a provider like mailinator and then sending a confirmation link to them works. While its not perfect, it does address lot of other concerns without sacrificing user experience.
    • stouset 10y ago
      Also, asking to retype makes sense for a password where you can't visually verify that you typed what you expected. For an email address, it's pointless and frustrating. Send an email. If it bounces or doesn't get verified in a timely fashion, it was a mistake and delete the account.
      • namenotrequired 10y ago
        And the user never discovers their mistake.
        • nilved 10y ago
          They'll discover they don't get a validation email.
        • Retra 10y ago
          That's just what happens when you give bad contact information.
    • 10y ago
• tedmiston 10y ago
  Hmm, sorry but I don't buy that the "correct way to validate" is not to validate the input. Email addresses aren't a special enough case to be handled differently than any other user input, which we always validate to both sanitize and show client-side errors, if nothing else. Sure, the complete regex is complex, but it is defined and is hardly unconquerable. Look at Django's `EmailValidator` implementation for example [0] that is mature and well tested [1]. The author has not convinced me that ignoring validation is the right choice when options with a scope so thorough exist. [0]: https://github.com/django/django/blob/master/django/core/validators.py#L170 https://github.com/django/django/blob/master/django/core/val... [1]: https://github.com/django/django/blob/a9215b7c36bff232bcc9416309726290dc74a9e8/tests/validators/tests.py#L48 https://github.com/django/django/blob/a9215b7c36bff232bcc941...
  • acdha 10y ago
    You can use a regex as a simple pre-check but you absolutely have to do more than that if you expect high-quality results. Back in the 90s, we ran the customer rewards program mailing list for a mainstream business you've heard of. A [gnarly] regex took care of the gross failures but we still had double-digit percentage of invalid addresses and many spam reports because people mistyped their username, used their old ISP's email address which had been disconnected, etc. The only approach which produced satisfactory results back then was to have a bit of (horrible) PHP code which did a full SMTP connection to deliver the welcome email. Even that wasn't enough to ensure you'd delivered it to the right person, however, so we had to track clicks on an activation link. I would be surprised if the average internet user has gotten significantly more reliable over the last couple of decades and that's born out by the wide variety of misdirected legitimate email my shortname@gmail.com account receives.
    • tedmiston 10y ago
      Definitely, I think email validation links are important too. However, it's pretty senseless to let an obviously invalid email address pass all the way through to that layer (and potentially get billed for sending messages to invalid email addresses).
• chavesn 10y ago
  All of that statistical analysis was actually a bit silly, because I've never heard the "typo" argument as a reason for email grammar validation[1]. Sounds like a straw man. It didn't need to be disproven. The conclusion is sound (although leaves out a discussion of the whether an email confirmation field is at least better than nothing). [1]: (As a side note, I think the most common explanations for grammar validation are programmer perfectionism and proactively stopping user garbage, such as copy-paste errors or intentionally fluffed fields that will result in a bounced email anyway.)
• r1ch 10y ago
  One thing I've found that helps a lot is instant delivery notifications. When you try to register a new account, our "We've sent a confirmation email" screen will report within a few seconds if there was a mail delivery error and allow the user to correct their address. Common typo detection for popular email domains is also beneficial (https://github.com/mailcheck/mailcheck https://github.com/mailcheck/mailcheck)
• sly010 10y ago
  If someone's valid email address [*\"32f2@13.31.43.11 they are up to no good and I don't want them as my customer. Also, according to the standard email addresses supposed to be case sensitive, since the username part refers to a unix user and unix is case sensitive. I work with a lot of email address lists originally collected on paper and of course noone knows that. So as bad as it sounds, part of my sanitation process is to lowercase everything. Noone ever complained. What the standard says and what people actually do is very different.
  • AgentME 10y ago
    Is it specifically the [, *, \, " symbols on the left that you're calling out, the presence of numbers on the right side, the presence of multiple periods on the right side, the lack of letters on the right side, or just the lack of non-numerics on the right side? I don't think most of those rules are needed technically; I wouldn't be surprised if at least one of those rules matches someone reading this comment thread. Any one of those individually seems like a strange minor reason to pre-emptively ban a customer if it doesn't necesarrily cause technical problems. If it's only people hitting multiple of those conditions, then maybe you could use a scoring function that only rejects users that meet multiple conditions? If the reason for the validation is a character judgment instead of a technical limit, then you could add more conditions too. People with email addresses that contain accented characters probably don't even speak the same language as you, so you could save yourself some headaches by marking those invalid. If you don't like leetspeak, then I think banning the letter "x" could be a good move too on average. "+" is used by a lot of people who want to trace whoever you might be selling your email lists to, so you could ban them before they blow the whistle on anything. Email addresses containing references to political candidates probably aren't owned by savory characters, so you could mark those as invalid too... Now that I think about it, since it's not for technical reasons, then none of this is really specific to emails. You could run passwords and other user content through this validation too. If the restrictions aren't for technical reasons, then they're just arbitrary tools for blocking users. Sorry for ranting a bit. I'm just tired of how often I get mystery validation errors from services because something stupid like that it turned out they thought that english works that happen to be sql keywords like "insert" shouldn't be allowed in the subject field, or my friend with an apostrophe in his name repeatedly being turned away from software telling him his name is invalid, and the idea that these rules could be in place just to cause people like us this annoyance ticked me off.
• chiefalchemist 10y ago
  Great article. Wrong. Question. The better question: In it's current form, is an email addresses really the best way to do what it is that's trying to be accomplished? (Hint: It's a fax machine.) I mean, if I have have a phone number, why can't I have an email number? Okay, perhaps not the greatest example. But then again, if a phone number can be switched from one carrier to another, in the second decade of the 21st century shouldn't "email" get the same consideration? Instead we're talking about regex or some other wonky validation? In 2016? That's just silly.
  • jones1618 10y ago
    > Why can't I have an email number? You can if you want (it is a valid email). But, if everyone had a numeric email it would be a lot harder to catch spam or know if you are sending to a bot. Sure, spammers can masquerade as a friendly name like yourmom313@domain.com now but it's easier to spot names you know than 471871731@domain.com. > Why can't emails be carried over to other domains? I like the idea in abstract. Practically speaking, though, this would not only require millions of emails to be purged from every ISP in the world it would also require some kind of creepy global email registry. That defies the decentralized spirit of the Web and would instantly become the Holy Grail of hacker targets.
• Benjamin_Dobell 10y ago
  The number of websites that try reject my email address with a + in it, ugh! Surprisingly, the validation is often done 100% client-side anyway, and simply modifying the incorrect regex lets my email address through... If I wrecked havoc on your back-end, then it's your fault for sucking ;)
  • cperciva 10y ago
    Worse than that: I've encountered a few web sites which accept email addresses with '+' characters... and then tell me that my email address has a ' ' character in it. Every time I see this I think "there's got to be a multiple-form-decoding vulnerability here"...
    • mook 10y ago
      I've got an account where they just plain stripped the + character. Since I happen to have used only alphanumeric charters after, I am now registered with an email address I can't actually receive mail on - it goes to somebody else's inbox. Account synchronization was involved - IIRC the initial address confirmation message got thorough.
      • oddlyaromatic 10y ago
        I thought that though the + is valid, nothing after the + is used to differentiate the email address? I use local+Organization when I sign up for an email list so that I can easily filter, plus I can see if that email address gets shared around. So on places that reject the + I just use everything before it as the local part. Maybe I'm missing something. Edit: I guess not all email providers do it this way but here's a link to more info: https://www.cs.rutgers.edu/~watrous/plus-signs-in-email-addresses.html https://www.cs.rutgers.edu/~watrous/plus-signs-in-email-addr...
        • gpvos 10y ago
          Yeah, of course it will work, but then it's harder to filter their mail to an appropriate folder.
• ikeboy 10y ago
  >I know hacking LinkedIn just to make a point about email validation is a bit extreme, but it is important to back up one’s opinions with data Hardcore.
• smallnamespace 10y ago
  Why not go the other way and compute the edit distance to commonly used domain names, and then prompt the user and ask if it's correct? E.g. if I type foo@googl.com, it should be pretty likely that I meant google.com.
• Ameo 10y ago
  I have a .link domain for my personal email and a lot of sites refuse to let me register because they don't recognize it as a valid TLD. Then there's the textbook company that lets me register but refuses to let me reset my password claiming that I'm trying to enter an "invalid email address."
  • devNoise 10y ago
    I've been using various emails on a personal domain for different sites. Some time this year Six Flags put in an email check and I can't register my season pass anymore. They give the following error: We were unable to finish validating your connection with the "*.net" email server. Yet I've been signed up for the pass holder announcements and get the email on a regular basis.
  • GirlsCanCode 10y ago
    I had a .to domain for a while, and I had an email address "firstname@firstname.to" where firstname is my first name. I wanted to use it when I needed to give out emails causally, like if someone from Church or some other group wanted my email. I gave up on it, not because of computer validation but because of stupid people! Nobody would "get" the .to domain and they'd always think there should be a .com or .gmail.com on the end of it. Especially older people. So I gave it up.
    • toomanybeersies 10y ago
      I'm discovering the same problem with my *.xyz domain name.
      • icebraining 10y ago
        As a counterpoint, I was surprised to see we've had very little trouble with our *.solutions domain, even from clients who are otherwise not very tech-savvy.
        • justusthane 10y ago
• smaili 10y ago
  For those looking for the conclusion: Send your users an activation email.
• gcb0 10y ago
  even Google fails this. register a Gmail address and type in the wrong alternative email. done. no confirmation required. someone with the mistyped email now have how to reset your password and take your account.
• dugluak 10y ago
  How about the common mistake of entering xyz@abc,com instead of .com. A lot of times I unintentionally make this mistake. If the system doesn't prompt me in this case then I would never know why I didn't receive any further communication from it. That's FAIL in my opinion.
• GirlsCanCode 10y ago
  What about bang addressing!?
• chenster 10y ago
  Even from http://emailregex.com http://emailregex.com, a popular regular expression summary for email, states it can only catch 99.99% of validate emails. However, I still like to include some basic form of email validation both on the client and server side, plus the activation email.
  • AgentME 10y ago
    >However, I still like to include some basic form of email validation both on the client and server side I worry you're more likely to permanently block a set of users with valid email addresses than prevent a user from making a typo.
    • chenster 10y ago
      The key here is "BASIC", something like [a-z]@[a-z] so at least they will have a at sign. Did you even read?
      • AgentME 10y ago
        I can't tell if you're being sarcastic or not, because that's perfectly proving my point. That validation bans anyone with a number immediately before the @, which includes my email address.
        • chenster 10y ago
          I was not.
• deleted 10y ago
  [deleted]
• kazinator 10y ago
  Sorry, I disagree. There is absolutely is a correct way to lexically validate an e-mail address: namely, implement a parser for the syntax specified in whatever RFC is the up-to-date successor of RFC 822. There is such a thing as incorrect e-mail address syntax: namely, non-RFC-conforming syntax, whatever that is. You may reject that, and that's about it. Please don't reject RFC-conforming e-mail addresses.
  • developer2 10y ago
    I agree, with two specific exclusions: notations for IP addresses in square brackets, and comments. Just removing those two never-encountered-in-real-life syntaxes reduces the RFC regex down to nothing. Comments are not a real thing, RFC be damned. And square bracketed IP addresses are never encountered in the real world, especially with the requirements for PTR records to pass all the major providers' spam filters. Anyone trying to provide an email address with a square bracketed IP or a comment is specifically trying to find an excuse to cause drama when their email is rejected. Those exceptions aside, fuck anyone who validates email addresses that don't permit perfectly valid real-world characters like '+', or who whitelist specific TLDs (.com, .org, .net et al).
    • jcranmer 10y ago
      Email addresses are defined and have an interpretation not according to RFC 5322 (which defines how you can write them in a message), but rather RFC 5321 (which defines how to route email addresses). Note that the RFC 5321 definition does not permit CFWS--its existence is merely an artifact in RFC 5322 of being able to insert whitespace (and later comments) anywhere in the grammar. Any tool which accepts CFWS in an email address that is not reading an addr-spec field of an RFC 822 mail message is incorrect. Beyond the issue of comments, I'd advocate rejecting the use of IP address literals and quoted localparts. Additionally, despite the injunctions on interpreting local-parts, in practice, it is best to treat email addresses as case-preserving: you'd consider a@example.com and A@example.com to be the same email address, but if the user typed in the latter, don't normalize it to the former.
    • zeveb 10y ago
• nxzero 10y ago
  Correct way is run a regex for [wildcard @ wildcard . Wildcard] then send an opt-in email real-time as the user is typing additional info. If it bounces before the user finished the onboard form - alert them to the issue. If it gets validate, autologin the user. If bounces or there's zero response by the time the user completes the form, alert them, ask to type their email again without access to the reprior entry - then give them the optin option via text message.
  • jasonkostempski 10y ago
    Polling email on the server is awfully wasteful. I like the "request an invite" pattern. Get an email address and nothing more, send the "invite", clear the form, tell them if they don't get an email in 5 minutes, check spam, still nothing, reenter the email. Don't associate the link with any particular session, just the entered address so there is no risk of leaking any private info, if they type in an address that actually belongs to someone else the only options the other person would have is ignore the email or sign up themselves. When they finally get their email right they'll get a link to a place where they can fill in the rest of the info and you can be assured they gave you the email address they wanted you to have.
  • zeveb 10y ago
    > [wildcard @ wildcard . Wildcard] That would invalidate ceo@cocacola, which is a legitimate address.
• amluto 10y ago
  I can think of one reason to do RFC2822 validation: security. It reduces the chance that someone can give a bogus email address that makes some SMTP server on the route misbehave.
• mangeletti 10y ago
  Firstly, great article. Secondly, this guy is so hilarious. I clicked to his podcast (where he reads Wikipedia pages) at the bottom and listened to this hilarious episode https://itunes.apple.com/us/podcast/david-reads-wikipedia/id1052573447?mt=2&i=358964123 https://itunes.apple.com/us/podcast/david-reads-wikipedia/id.... His specific style of sarcastic humor (just like the article - is there a name for this style of humor btw?) is rare and hilarious.
  • zeeveener 10y ago
    You named it for what it is. Sarcasm. Incredibly dry, sometimes monotonous sarcasm.
• Xorlev 10y ago
  At this point, our email validity criteria: .+@.+\..{2,} That is, at least one character for the inbox, at least one character for the domain, at least two for the TLD (we assume that TLD-less domains are undeliverable by us). This ensures we don't allow 'a@a' or 'a@a.a', but do allow 'a@a.io'.
  • DHowett 10y ago
    a@[IPv6:2001::1] is, unfortunately for your validation regex, a valid e-mail address. [EDIT: I see that you consider TLD-free e-mail addresses undeliverable; still!]
    • bbcbasic 10y ago
      .+@.+ FTW?
      • mnkypete 10y ago
        That's what we do. Everything else is just lying to yourself and hoping for the best..
      • regularfry 10y ago
        Or, more simply, `.@.`.
      • Senji 10y ago
        Enjoy getting a billion e-mails per second written to root@localhost
        • bbcbasic 10y ago
          As if. There would be a single confirmation email sent which would not be clicked.
  • blechschmidt 10y ago
    This might already filter out legitimate users. dig MX io. Also, you don't know what new TLDs ICANN might come up with at some point. I am pretty sure there are service providers that do and did limit the TLD length and then TLDs like xn--vermgensberatung-pwb came up.
• josh_carterPDX 10y ago
  I'm now going to put non-standard email characters in every form I fill out just to see how the site handles it.
• bigger_cheese 10y ago
  There is someone at my work with a hyphen and an apostrophe in their email address. Their inbox often gets used for testing things.
• ehnto 10y ago
  I have trouble with my simple .co address.
• chriscampbell 10y ago
  I respect the thought behind this article but if you don't want to build it yourself, we use the company .BriteVerify and it works pretty dam well for identifying invalid emails.
• tgarma1234 10y ago
  No. Absolutely beginner level blog post. You would use a third party tool like http://www.datavalidation.com/ http://www.datavalidation.com/ or mailgun's email validation service or BriteVerify etc etc. There are a ton of validation services now. We are living in a time when trillions of email addresses have been tried, entered and deployed to. So why reinvent the wheel on your website? 3rd party services are based not only on parsing the string but also on literally billions of emails actually deployed through various ESP's to tell you up front whether the email address entered by a user is correct. I could use a trashmail email address and it would validate by the OP's standards. First validate using a third party service and then send the double opt-in email to get a user click.
  • idlewords 10y ago
    Passing on user-submitted emails to a third-party service without their explicit consent is a huge privacy leak.
  • jasonkostempski 10y ago
    /s? I seriously can't tell.
    • pg_is_a_butt 10y ago
      the idiots here eat up these moronic services. see https://news.ycombinator.com/item?id=6109905 https://news.ycombinator.com/item?id=6109905
  • kinkdr 10y ago
    My philosophy is exactly the opposite. Allow anything as email address and make it as simple as possible for the user to sign up to use my application. This means, no email validation, no address verification emails, heck, I don't even have a password confirmation field. One field for name, one for email and one for password and you are in. If 10% of the users don't trust me with their real, or even throwaway email address, so be it. My goal is not to collect email addresses, but to have users use my application and add some value to their life. If another 10% of them enter a mistyped email, they will figure it out eventually and change it if they care.
• ChuckMcM 10y ago
  I think the 'valid but wrong' email is a more common failure. Having just spent a few weeks with my wife trying to convince some poor person that they had mistyped their email address when they created their Amazon account. Reminded me of this xkcd (https://xkcd.com/1279/ https://xkcd.com/1279/). It does seem effective to have someone type the address twice as that can catch a typo fairly easily.
  • jcoffland 10y ago
    I hate it when sites make me type my password in twice like I'm some sort of idiot. What's really bad is when they disable pasting. This is so stupid because it makes sure I cannot copy and paste from my password DB. I will often not use a site for this reason alone.
• contingencies 10y ago
  1. International domain names... you cannot filter characters much because of this. If you want to filter characters, be damn sure it's careful and precise filtering. 2. For immediate feedback, you can reasonably check it's not at at a non-routable IP range, ie. address@127.x.x.x or address@192.168.x.x or similar. However, this check is best done on your email server (MTA policy). It's unlikely anyone would enter this without malicious intent so there's no need to optimize for their use case.
  • developer2 10y ago
    "user@127.0.0.1" isn't even valid. An IP address as a host requires square brackets a la user@[127.0.0.1] - but this is only by RFC, and no real site allows signing up with an IP address instead of a hostname. Email validation is simple. You take the full RFC regex, and remove the notations permitting square brackets and comments. You wind up with a regex that accepts exactly 100% of real-world email addresses. If your regex contains "\.(com|org|...)", you're doing it wrong. If you can't figure out how to do the full regex properly, then match against /^[^@]+@[^.]+\./ - or hell, just check for an '@' symbol - as a basic "hrm that kinda looks like an email address" and send the email. It's really not difficult. The only problem is naive English-speaking people who only deal with latin1 thinking that [a-z0-9]+ is somehow the only valid criteria for a username or hostname.
• buro9 10y ago
  The best way to validate an email address: Send an email that they need to click on (or an email with a code they need to enter), OR ask the OAuth provider with authority for it to validate it (i.e. Google Oauth for Google addresses, Windows Live for Microsoft Accounts, etc). The best way to identify someone with an email address: Store a canonical version of their email address alongside the users email. Use the canonical version when signing-in/identifying and the raw version originally supplied to send email. This is the only way to not have duplicate accounts for firstlast@googlemail.com vs first.last@googlemail.com vs first.last@gmail.com . The canonical email is always lowercase, no dots, no + part, no prefix or suffix columns, known domain aliases are normalised to the most common alias (googlemail.com > gmail.com). I wrote a SQL canonical email func recently (in preparation for Persona shut-down) if anyone is interested: https://github.com/microcosm-cc/microcosm/blob/master/db/migrations/20160831112556_canonical_email.sql https://github.com/microcosm-cc/microcosm/blob/master/db/mig...
  • cimnine 10y ago
    Just make sure the (canonical) email address is not the primary identifier for the user, as email addresses may change over time.
  • justinlardinois 10y ago
    > This is the only way to not have duplicate accounts for firstlast@googlemail.com vs first.last@googlemail.com vs first.last@gmail.com . Periods being optional in usernames is something that Gmail started, not a universal rule or part of the specification. Are you going to build into your system all the possible variations for every email provider?
    • buro9 10y ago
      > Are you going to build into your system all the possible variations for every email provider? I've analysed my user database and am only doing the large providers for which I have high confidence.
• nicolas_t 10y ago
  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.
  • gpvos 10y ago
    I like activation emails, because it shows the website cares about being able to email me. Then again, I'm a technical user.
    • rplnt 10y ago
      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.
    • nicolas_t 10y ago
      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.
      • gpvos 10y ago
        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.
• gpvos 10y ago
  One more thing that irks me is that some websites capitalize or lowercase the part before the @. Email servers are allowed to treat that part case-sensitively, although most don't. (The part after the @ is indeed case-insensitive.)
• teekert 10y ago
  Small anecdote: We recently had a visitor from the US (a physician) who didn't understand why we didn't need a .com at the end of an email address, she was exchanging email addresses with a french person who's address ended in .fr :)
• sigi45 10y ago
  His number is probably wrong. I personally wrote/typed my email address wrong (when you have those two fields). There are also common pitfalls people are doing like empty spaces at the beginning and at the end which should be cleaned up before trying to send the email to " whoever@gmail.com". There is also an Email standard and when a normal library is able to validate it (and there are free good libs out there) than the effort to do so is similiar minimal but provides an additional support. What you should do is also to make sure that you are not sending unlimited emails out there. Otherwise you might be missused as a mail relay / spammer.
• mpetrovich 10y ago
  Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems. — Jamie Zawinski
• burnbabyburn 10y ago
  tl;dr send a confirmation email. it's 20 years that people suggest a cool new way to deal with email addresses, I don't even mind listening anymore! :)
  • dugluak 10y ago
    I think its good to do some kind of validation upfront. It's too much to ask a user to go through whole process again for a silly typo.
• jordanielewski 10y ago
  Personally, I just check '@' presence
• Timucin 10y ago
  I wish the author put the single sentence at the end to the up with a TL;DR; note: send verification emails, which I don't agree 100% while the article/author claims that's the 100% right way.
• vkjv 10y ago
  I like the approach of accepting anything that is a reasonable length with an`@`, but suggestinging corrections for possibly misspelled common domains. https://github.com/mailcheck/mailcheck https://github.com/mailcheck/mailcheck If you really need to validate, the only way I know how is to send them an email and click a link to confirm.
• flagelate 10y ago
  I literally just check for the presence of an @ with something on either side. Anything more, you're going to piss off a user at one point or another.
• zimbatm 10y ago
  TLDR; (with my own interpetation) 1. Email validation regexp should be: /.+@.+/ => Tell the user to enter a valid email if that doesn't match. 2. Send a validation email to actually exercise the system
• bballer 10y ago
  In all my projects I use the same methods for validating an email address: 1) Does it contain a `@` 2) Split the string on the `@` and make sure that at least one character exists on both sides of the `@` 3) Send verification email. This check is done server side, while on the client I just use an html5 input[type='email'] with a required attribute.
  • FungalRaincloud 10y ago
    That's probably reasonable, but you might want to amend 2 to "split the string on the last '@'". There's no restriction to only '@' before the domain. It's exceptionally rare that a server even allows '@' in the mailbox name, fortunately for us.
• puddintane 10y ago
  I always search out that a validation library hasn't already been done in my current language first before attempting validation with custom code - this leads to more easily maintainable code for future eyes. For example in PHP I use filter_var function with the FILTER_VALIDATE_EMAIL [1] - while it's great to know why and how to do a particular thing programming, it's better to use a time tested library that is maintained by multiple eyes versus just your own. [1] http://php.net/manual/en/filter.examples.validation.php http://php.net/manual/en/filter.examples.validation.php
• htor 10y ago
  What is weird is that input[type="email"] rejects some valid emails. Try out this codepen: http://codepen.io/anon/pen/dpoqVQ http://codepen.io/anon/pen/dpoqVQ
• nbevans 10y ago
  Validating e-mails is pointless - short of sending them a confirmation URL and waiting. Sanity checking them however is often useful for checking form input or data cleansing.
• suhith 10y ago
  This keeps coming up on HN, in the end the best thing to do is exactly as the article says. ACTUALLY SEND the email and see if they get it.
• fafournier 10y ago
  There seem to be a problem with the analysis. It seems to assume that everybody uses qwerty keyboards! What about qwertz, azerty, dvorak or even colemak... We need to recalculate with data aggregated and weighted by world-wide populations! :-D
• OOPMan 10y ago
  My approach to this is reasonably simple: 1: Does it have an @ 2: Is it at least 5 chars long (E.g. a@b.c)
• SZJX 10y ago
  Of course the only way to be 100% sure would be to actually test it out by sending an actual email isn't it. This is just so obvious. I think the point of email regexes out there is not to make up for the user's silly typing mistake. It's just more to reject nonsensical/malicious/blatantly false inputs etc. as the first layer of protection really, and nobody would really spend tons of time on crafting a "perfect" regex anyways I'm pretty sure, so that's never been a problem at all.