18 ms·

Stop Validating Email Addresses with Regex (2012)

• duxup 4y ago
  I appreciate the idea here but generally you set a non perfect regex expression and just roll on with whatever other verification there is (send email). Well I don’t but if you did I don’t see much harm. I won’t ask people to type the email twice, that’s just annoying.
  • junga 4y ago
    And it becomes super annoying when you can't paste into the second field. Had to implement this once - should have rage quit immediately.
    • hoosieree 4y ago
      Agreed, also anything that defeats a password manager is a red flag for me. I've seen sites that break a password manager's autofill AND disallow pasting a password. It's like they want me to use a bad password.
• usrbinbash 4y ago
  Can't upvote this enough. There simply is no need to check the email addr provided by the user. Send the mail, if it bounces, the user has only himself to blame. What if I don't want them to go through the hassle of an activation link? Then I don't bother with an email account in the sign-up process in the first place. If they want a passwd reset method, they can later provide an email in their settings page, if that isn't valid, well, tough luck.
  • passerby1 4y ago
    Bouncing usually requires money
    • akersten 4y ago
      So does sending the verification email, so it's a wash. Thinking about implementing email validation + verification is a great opportunity for developers to do two things: 1) Consider if you really even need to verify that email address. Why are you collecting email in the first place, why do you need it? HN is a great example of this - email totally optional, if you forget your password it's on you. Lot of online services going in the wrong direction with requiring a phone number. 2) Trust the user. Okay to give them nice nudges ("you probably meant gmail.com and not gmail.co") but if I really did mean gmail.co, let me through if I insist. Don't throw up a garbled mess of a Regex[0] that only serves to frustrate me when I try to sign up with my vanity email. I'll abandon the sign-up entirely. [0]: https://stackoverflow.com/questions/20771794/mailrfc822address-regex https://stackoverflow.com/questions/20771794/mailrfc822addre...
  • caiomassan 4y ago
    The most underrated crypto thing that people don't discuss enough, is that i don't need an email account to interact with web3 apps, i just sign in with metamask. if I could do it for every single app around that would be great.
    • jeofken 4y ago
      If only browsers had a public/private keychain built in to sign and encrypt messages. Authenticating = sign a message with your private key.
      • jeroenhd 4y ago
        Browsers have mutual TLS auth if you want that type of authentication. The UX is mediocre and MANY tracking websites will ask you to sign in (either out of incompetence or malice) in your regular browsing, but it's definitely possible to use such a system. Nobody is accepting random self-signed certificates, of course, usually they need to be signed by a CA belonging to the party you're authenticating to, but there's no technical reason why you can't use a random certificate to authenticate with a website, or even modify your browser to add a quick and easy button to generate them on the fly. Browser vendors have stopped caring about this type of auth and are focusing more on webauthn, which stores a cryptographic token in your device's secure storage (if available) or on the file system. When browsing from a phone, this means it's essentially "sign in with your fingerprint" for websites, which is really cool! You can't easily back those tokens up, though, so you still need something like a recovery email if you don't want your users to lose their accounts when they drop their phones too hard.
    • boondaburrah 4y ago
      What's wrong with a username and password?
      • arthurcolle 4y ago
        not secure enough, prone to easy abuse/workarounds.
  • makeitdouble 4y ago
    Don’t most emailing services heavily penalize a high bounce rate, including banning of the commercial account if it goes on for too long ? (which as far as I understand is also to protect the emailing service from getting blocked itself)
  • samwillis 4y ago
    I can assure you that this would end up with far more problems than it will solve. I run an online store, people miss entering their email address is one of the largest causes of customers contacting support, and they regularly jump to being angry accusing us of being incompetent or worse. I would take the 0.001% of people who may have an email incompatible with a regex being frustrated (which will happen to them all the time) over the 10% who screw up entering their address. We even have code that looks for common typos and prompt the users to double check them. Somehow they still make those mistakes.
    • Avamander 4y ago
      You can obviously warn the user, but it shouldn't be a strict validation. That's half of the point. It's probably a mistake if someone typed gamil.com instead of gmail.com, but it's not a mistake if someone typed pm.me (or something punycode).
  • kazinator 4y ago
    What's much more important than validating the syntax of the e-mail is not to let your service be turned into a relay for targeting e-mail addresses of third parties with "backscatter". Don't put up a web page where any visitor can put in an e-mail address, to which you send something, without any safeguards: like not sending to the same e-mail address more than just several times in a 24 hour period or something. Have Captches or or something to reduce the bots. Proof of work. Whatever. It may be wise to validate not for valid e-mail address syntax, but for certain invalid e-mail addresses to which you shouldn't send. For instance, would any legitimate user be subscribing with an e-mail address of postmaster@example.com? It seems it would be worth it to have a database of patterns of at least some well known mailing list addresses. Certain domains are almost certainly mailing lists; e.g. anything@vger.kernel.org is probably a list; don't send to it. Process bounces.
    • zeeZ 4y ago
      I got some like that just last week. They were using a public sales quote request contact form, filling it with a bunch of random characters except for a valid email address and the name, which was something like "♥ Martha wants to meet you! Click http:// http://... ♥"
      • Avamander 4y ago
        It's a massive issue. It's not only spam, it also enables malware distribution and e-mail bombs (flood of mail to cause DoS or to hide some other letters). It is mostly because proper defenses against such abuse aren't built into software allowing such forms (or cost money). Wordpress form plugins are one such widespread bad example.
  • robbiemitchell 4y ago
    > Send the mail, if it bounces, the user has only himself to blame. Some products don’t want to let users fail so easily. Especially if they spent good money to get you to the point of signing up.
  • leros 4y ago
    I would like to agree, but sending an email that bounces will negatively impact your email reputation and thus your deliverability. I work at a large web company. We ran a test around removing email validation and we had about 20% of users typo their emails when signing up. Simple things like not putting the period before com like "john@gmailcom". It resulted in customers basically creating accounts they couldn't get back to which was a bad user experience and loss of revenue for us. Based on our testing, email validation mostly served to prevent these basic typos.
  • mekster 4y ago
    > if it bounces, the user has only himself to blame So your system always makes the least effort and pushes the blame to users. Great. How about just even do a minimal check that is /.@./ so that the basic format is at least there or if you'd take 10 minutes to look around, you'll find the regex browsers are using and just steal it and be done with it, so most of the malformed inputs are warned to the user before the user realizes the confirmation email isn't arriving minutes (or days) later and possibly lose the conversion right there. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/email#basic_validation https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
• rokhayakebe 4y ago
  Someone could submit several fake email email addresses and negatively impact your domain name email reputation.
• mdoms 4y ago
  I'm happy for my service to quickly and correctly validate 99.999% of emails and I don't really care if your oddball edge case emoji Sanskrit 6-level-deep domain fails. Just do normal stuff.
  • phreack 4y ago
    I once suddenly couldn't log in to a paid bike renting service app because it wouldn't accept my (valid at sign-up) email on login as it had a '+' symbol. There was basically no way to contact the developers and it was impossible to get the support people to understand what my problem was so I literally never used the service again. Don't try to parse email with regex, it's just not worth it.
    • threeys 4y ago
    • discardedrefuse 4y ago
      This occasionally happens to me with a "category.site@depingus.mydomain.com" email address. I also respond by never using that site again.
  • Avamander 4y ago
    It has to be a very niche service for you to not have any users with a name that doesn't fit in the pointless constraints of US-ASCII.
• gleenn 4y ago
  One of the best validation techniques I heard was check for an "@" symbol and if they have one the call it good.
  • kingcharles 4y ago
    You are doing God's work, my friend.
  • wolrah 4y ago
    Most internet systems can also assume there will be at least one dot following the @ symbol and at least two characters after that. Something intended for us on internal domains of course can't many assumptions.
    • jeroenhd 4y ago
      The two character requirements can trip up foreign TLDs if the input is encoded as unicode (but everyone knows you're supposed to translate the domain to IDN before running validation, right? Right??) so I wouldn't even use that. There don't seem to be any TLDs that are only one character long in their encoded form, but I can easily see Chinese or Japanese TLDs leveraging their extensive character set to keep the TLD part of the domain short. As long as there's something behind the @ before a period, it's probably fine for an external email address. Missing a period can cause problems, because without a period or a TLD at the end, your mail service might try to send email to internal servers in your network. Send mail to a@b from server c.com and you might end up sending email to a@b.c.com instead. Not checking for a period in the domain part can therefore cause some pretty weird behaviour. If the email ends in an external domain, there's a period. If the email is intended for an internal host without a full domain name, the period should be at the very end of the address, turning it into a proper hostname. It's easy for people to type gmailcom and if you're using dot less domains in your network infrastructure you probably know about these hacks anyway. I don't think checking for a dot will break anything, even in the spec, except for something@[IPv6 address] but IP address emails are practically unused in real life anyway.
• Beltalowda 4y ago
  I wish they would just modify the standard to not allow "Look at all these spaces!"@example.com and such. Many email systems already don't accept it (e.g. gmail doesn't, probably others but I didn't test) so the actual practical value is small. There's a whole bunch of stuff in there that no one uses and just makes things harder than they need to be. I've been programming for 25 years. I've been reading this same article repeated over and over again for 25 years too. Clearly it's not working.
  • Avamander 4y ago
    It's not working, but not because the standard says you must support a much more lax format. It's not working because some people are writing bad code, that code does not only fail for spaces between quotes. It fails when more than 50% of the world tries to use their native alphabet - when using UTF-8. It's not the standard's fault that people implementing are not following the old adage of implementing standards: "Be strict in what you give, be lenient in what you accept." Considering how there's really not a tremendous amount of variety in what e-mail software people use, it boils down to those maintainers' stubbornness. If you dig trough old mailing list threads and issue tracker tickets, the ossification becomes quite visible.
• WaxedChewbacca 4y ago
  I recently encountered this thing, which I'd never seen before: https://html.spec.whatwg.org/multipage/input.html#valid-e-mail-address https://html.spec.whatwg.org/multipage/input.html#valid-e-ma... The original standard for email addresses seems to be so bad that it's just being scrapped and ignored. I think I'm OK with this.
• deleted 4y ago
  [deleted]
• janosd 4y ago
  This is horrible advice. If you don't check input for correctness at all, an attacker could inject all kinds of nastyness into am underlying system, which may expose bugs. For example, control characters, line breaks, shell escape characters, SQL injections, or simply uploading an ISO image into the E-mail field. There is the RFC, and there is what we would nowadays consider a sane E-mail address. Nobody has addresses with spaces, nor does anyone have an address with an IP literal in it. Why? Because no other system will accept it. Think bank, etc. TL;DR at the very least you need to validate field length, control characters, quote signs, and backslashes. Those have no business being in am e-mail address.
  • threeys 4y ago
• pkrumins 4y ago
  Here’s the regex you should use: .+@.+\..+ Works every time 100% of the time.
  • arthurcolle 4y ago
    Haha I like the other poster dude's suggestion of just letting it through if you see an @ symbol. Wouldn't yours work with potentially too many weird character sets? probably language/runtime dependent
    • Avamander 4y ago
      Those character sets should work, the standards allow it. Your software should auto-punycode the domain part anyways.
    • pkrumins 4y ago
      That dude gets it!
  • mappu 4y ago
    Famously won't work for n@ai, either with or without the trailing period to ensure global name resolution. The .ai is one of a rare few ccTLDs that have (or had) top-level MX and A records. https://mail.gnome.org/archives/evolution-list/2002-January/msg00466.html https://mail.gnome.org/archives/evolution-list/2002-January/...
    • pkrumins 4y ago
      2unusual4me
  • deleted 4y ago
    [deleted]
• dchest 4y ago
  RFCs for email addresses are cool, but on the web we have our own standards! https://html.spec.whatwg.org/multipage/input.html#valid-e-mail-address https://html.spec.whatwg.org/multipage/input.html#valid-e-ma... "This requirement is a willful violation of RFC 5322, which defines a syntax for email addresses that is simultaneously too strict (before the "@" character), too vague (after the "@" character), and too lax (allowing comments, whitespace characters, and quoted strings in manners unfamiliar to most users) to be of practical use here." The regex is: /^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/ Every browser implements this regex for <input type="email">. Chromium: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/forms/email_input_type.cc;l=46-53;bpv=0;bpt=1 https://source.chromium.org/chromium/chromium/src/+/main:thi... WebKit: https://github.com/WebKit/WebKit/blob/0d7afc5a45c140c44497a81e92416f01306be877/Source/WebCore/html/EmailInputType.cpp#L38 https://github.com/WebKit/WebKit/blob/0d7afc5a45c140c44497a8... Yes, do verify email addresses by sending a confirmation link if you bind users to their email addresses, though. Don't confuse validation with verification.
  • seanw444 4y ago
    I like your final sentence. Very to-the-point.
  • hathawsh 4y ago
    I tried using that expression for a while, but then a user with a valid email address containing upper unicode characters showed up. I switched to a simpler expression: ^[^@\s\x00-\x1f]+@[^@\s\x00-\x1f.]+(:?\.[^@\s\x00-\x1f.]+)*$ It requires exactly one "@", disallows whitespace and control characters, prevents repeated dots in the domain name, and ensures the domain doesn't end with a dot. It catches a few typos and I think it allows every real email address I've heard of.
    • easrng 4y ago
      Domains ending with a dot are valid though, and it's needed sometimes. For example, someone@ai. (ai. is a TLD) is a different email than someone@ai (ai is a local hostname)
• drewcoo 4y ago
  I tell everyone the same thing about access control. Don't check access. Also, never check file existence. These things just take up time, introduce race conditions, and can't be trusted anyway. That said, there are reasons to want to check some things with UI-level validation because calls to a slow back end are slow. Thus the name. I get that. So if you're doing UI validation, don't get it right. Just get it mostly right. And do it fast. Cheat!
  • mr_cyborg 4y ago
    > I tell everyone the same thing about access control. Don't check access. This caught my eye and I’m dying to know more - could you elaborate or point me to a good resource on this? My team has been dealing with some issues related to this recently.
    • rascul 4y ago
      It may be in reference to TOCTOU. [0] If you check that you can access a resource before you access that resource, you have implemented a race condition where you could potentially lose access to the resource in between the check and access attempt. It's probably not an issue if you have proper error handling, but it seems common to check that access is allowed then assume the resource will still be accessible later, without handling errors for when it's not. [0] https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use
      • mr_cyborg 4y ago
        Thank you so much for sharing this!
• mappu 4y ago
  I recently had a requirement to transform email addresses within free text into clickable mailto: links. That needs a regex. /[^ ]+@[^ ]+/ is OK except for trailing punctuation, double @'s, and it definitely doesn't work with that quoted example. The first Rails one in this post /\A[^@]+@([^@\.]+\.)+[^@\.]+\z/ is at least better than what I came up with - I'll take a battle-tested regex if it's on offer.
• arthurcolle 4y ago
  you could check some common PGP keyservers for a key corresponding to the email address. if it isn't uploaded, treat the email as unverified and untrusted. daydreams about strong cryptography
• barrell 4y ago
  I recently launched a webpage without validation on the email field. 90% of the rows created in the database were not emails. I understand the point about not maintaining complex regex, but I just used an npm package that maintains and updates validation regexs with web standards. Besides any remaining left-pad jokes still standing, I don’t see why I would eschew this solution for any future forms?
  • 3np 4y ago
    Not saying you shouldn't keep doing what works for you but: If visitors knowingly put invalid e-mail addresses 1) do you really need an e-mail address from them, rather than making the field optional? 2) If so, validation should be done by sending an e-mail with a validation link either way. As others pointed out, for a sanity-check something like /.+@.+/ should be good enough.
• User23 4y ago
  Ah, an old classic. Here[1] for example is a simple RFC 822 compliant email address recognizing regex: (?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t] )+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?: \r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:( ?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0 31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\ ](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+ (?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?: (?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z |(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n) ?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\ r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n) ?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t] )*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])* )(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t] )+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*) *:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+ |\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r \n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?: \r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t ]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031 ]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\]( ?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(? :(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(? :\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(? :(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)? [ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]| \\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<> @,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|" (?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t] )*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\ ".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(? :[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[ \]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000- \031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|( ?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,; :\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([ ^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\" .\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\ ]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\ [\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\ r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\] |\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0 00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\ .|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@, ;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(? :[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])* (?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\". \[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[ ^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\] ]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*( ?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\ ".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:( ?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[ \["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t ])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t ])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(? :\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+| \Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?: [^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\ ]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n) ?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[" ()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n) ?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<> @,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@, ;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t] )*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\ ".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)? (?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\". \[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?: \r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[ "()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t]) *))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]) +|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\ .(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z |(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:( ?:\r\n)?[ \t])*))*)?;\s*) Furthermore: "The regular expression does not cope with comments in email addresses. The RFC allows comments to be arbitrarily nested." Thus, clearly RFC 822 addresses cannot be described by any regular language. Ooof. I've been internettin' for a few years now and I had no idea that the email address format specifies comments. [1] http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html
• eric4smith 4y ago
  You actually should at least use regex to check some basic things. Like "@" "." or even just disallowed characters. As someone who sends a LOT of email for customers every week, a big percentage of our problem is incorrectly formatted emails. So we just don't even let them in these days. People are forgetting that for services that have to send email it costs dearly to bounce. Bounces decrease the quality of your list and you can get penalized by your email provider. By letting in stupid sh*t, you just are compromising yourself. So some simple regex that gets rid of the most egregious stuff is worth it.
  • kingcharles 4y ago
    Please don't check for a full-stop/period. It excludes those who have their email address directly on a TLD.
    • sverhagen 4y ago
      Is that an existing cohort? I'm not saying it isn't, I've just not run across them.
      • easrng 4y ago
        Probably not. http://ai./ http://ai./ has a website, but no emails AFAIK
        • kingcharles 4y ago
          https://mail.gnome.org/archives/evolution-list/2002-January/msg00466.html https://mail.gnome.org/archives/evolution-list/2002-January/...
          • deleted 4y ago
            [deleted]
          • easrng 4y ago
            Huh, looks like n@ai. still exists, I wonder if it's in use anymore.
• olsgaarddk 4y ago
  Does anyone on HN have any of these "surprising" email addresses that most people and developers do not expect? How does it work with common e-mail clients? How do people react when you show/tell them your email? I have a domain that uses non-ascii characters, and while I can receive emails on that domain, hosted by Fastmail, Fastmail clients refuses to _send_ emails to that domain (I can, if I type the domain as Punycode).
  • kingcharles 4y ago
    I can't type one of my email address on HN as it has emojis in the hostname. It works great with Fastmail. It gets problematic when I use emojis in the mailbox name as well. At lot of hosts won't allow that. You can see the email address on the front page if I paste the punycode web address on here: https://xn--bp8hgh.to/ https://xn--bp8hgh.to/
    • jeroenhd 4y ago
      Messing with emoji taught me how absolutely atrocious unicode support among email servers is. Gmail supports it, but even modern versions of postfix require special compilation flags to enable SMTPUTF8. While emoji aren't a use case you'll get many managers to care about, there are plenty of unicode characters that can. Email addresses using foreign script, for one, or even just characters like åäáà, not uncommon in European names, might convince people to consider enabling such features. Sadly, the process of enabling support for such characters is much harder than it should and I've got to admit they my mail infrastructure also can't handle these types of email addresses. Modern MS Exchange servers seem to have finally implemented support, though, so perhaps we may see more support for it in the future!
      • Avamander 4y ago
        I think postfix's DB drivers were also still latin-1 only, if I'm not misremembering I had to mojibake what I wanted it to pick up. Though UTF-8 is not the only thing atrocious with e-mail stacks, there's so much maintained-but-not-really non-standard software that a lot of people rely on. To end on a positive note, e-mail hosts are starting to demand SPF to accept mail.
• coolhoody 4y ago
  This won't be popular, but: 1. An experienced dev just killed 54k stars on GitHub due to pressing a button in an auto-pilot mode. Do you think a Joe High who wants to give you $100 won't ever type '2' instead of '@'? What about an old lady? Or someone with physical difficulties? Have you personally ever made a typo in an email? 2. That code in the article is not color highlighted (rainbowed for Regex) or formatted properly. If I write something in any language in one line without highlighting — it'd look unreadable as well. 3. A Regex for this specific purpose is write-once-and-forget. You won't need to edit it for 20 years. 4. Regex — for practical tasks — is way easier than it's being painted. Not easy — just not as hard as some suggest. 5. I'm not a Regex fanboy (nobody is).
  • goto11 4y ago
    Sure, but the most common typos would just result in a wrong address which is still syntactically valid. That is why the address should be verified by sending an actual mail for important stuff. This is also the only way to protect against fake addresses, since anyone can come up with a fake address which is still syntactically valid. I do like to check for '@' to enure the user have not entered their name or something by mistake, but beyond that the syntactic validation does not provide any value.
  • sverhagen 4y ago
    Agreed. And while I wouldn't attempt creating a regex for email addresses -- if I really felt I needed that, I think that's what libraries are for, not my job -- I have used plenty of regexes in useful and successful ways. I wanted to really add to your "you won't need to edit it for 20 years" comment that the regex should also be anchored with a unit test, that demonstrates the usages you designed for (and maybe a few negative tests to show what you specifically didn't intend to solve).
  • Cthulhu_ 4y ago
    Simple validation is easy enough to implement and will cover 99% of cases. For the rest you use verification, have the user activate their account before doing anything. Which is a pet peeve of mine; I've got an older e-mail address that probably ended up on some list, now there's people from Thailand and the UAE registering accounts using that e-mail address. Now while my account is still secure (2FA, long password, the works), it doesn't stop people from using it. Services like this one webshop and Deezer and probably a few others do not wait for e-mail verification before allowing users to place orders or use their service, or at least the free trial part of it.
• gregjor 4y ago
  Ten-year-old article. Everyone still uses regexes, including browsers. World has not ended, I rest my case. Some negligible fraction of pathological email addresses will get rejected by imperfect regular expressions. I’ve tested multiple email validation regexes against huge databases of actual emails and found they all validate.
• coder4life 4y ago
  I won't! https://emailregex.com/ https://emailregex.com/
• valand 4y ago
  Previous discussion: https://news.ycombinator.com/item?id=5763327 https://news.ycombinator.com/item?id=5763327
• kingcharles 4y ago
  PLEASE, FOR THE LOVE OF GOD, can all of you who write email validation not include a whitelist of TLDs that you allow. THIS IS KILLING ME. My primary email addresses are on two TLDs, one of which has been around for 24 years, the other for seven years, but about 10% of sites I try to register on refuse to accept them, saying that they are not valid. They clearly have not updated some internal whitelist since these TLDs were added. I just had one major ecommerce go into their DB and update my address. This was a bad idea because now my profile page has an error and I can't change anything else. STOP THIS. JUST STOP.
  • rrdharan 4y ago
    Obviously, they aren’t going to stop. Why wouldn’t you just give up and get another email address and set up forwarding? Life is too short to yell at clouds all day.
• xurukefi 4y ago
  What's even worse is that a lot of people think that it is a great idea to check the TLD against the set of existing TLDs. Of course, nobody gets such a whitelist right or cares to update it if new TLDs are created. From experience I can say that having an e-mail address with a not so popular and rather new gTLD is an absolute nightmare. We had to roll out aliases with "normal" TLDs to combat this.
  • tzs 4y ago
    That's because almost as soon as a new TLD becomes available spammers start using it as the from address in emails. For probably 99.999% of people the only email they will ever see with such a from address is spam. Just automatically marking all mail from those domains as spam turns out to have such a ridiculously small false positive rate and eliminates so much spam that it is worth it for many people. That does mean that in practice it is probably best to consider most new TLDs as web-only. Use them in URLs but have @com, @net, or @org email addresses for anything where you want outgoing mail to get through. When I was running my own mail system, I eventually ended up with all of the following TLDs going straight to a spam folder: accountant bid christmas click club cricket date download faith gdn gq help info link loan men party press pro racing review science site space stream team top trade uno webcam website win work xyz zone
    • jeroenhd 4y ago
      Every TLD is full of spammers. Most spam I receive comes from com/net/org domains, but blocking those is silly. Hell, I barely receive real email from Gmail and Outlook domains in my personal server, I'm pretty sure my spam algorithm is starting to get a bias against those domains at this point. When you're dealing with signups for a service, there's absolutely no reason to refuse a working email address.
• samwillis 4y ago
  This is a very bad idea, it will make your customers and support team unhappy. It’s is one of those “technically” vs “practicality” things, not using a regex will cause you more customer support problems than solve. I run an online store, typoed email addresses are one of the top causes of customers contacting support. In 10 years we have never had a customer contact us to complain their “valid” email address won’t be excepted on our site. If we were to remove the regex from the validation and “just try to send an email” as suggested it would create so much more work for our support team. You should also implement some “soft” validation looking for common typos, although people still somehow make those mistakes. I’m convinced that some people have types in their autocomplete address book.
• hennell 4y ago
  I wish validating emails through sending was more common. I have early days Gmail account based on a name. For some reason there are many people out there who put my email on their accounts. Great when I got free Disney+ for a few months because someone signed up with my email. Less fun when ovia health won't stop sending me fertility tracking information about a stranger because they put my email down and ovia didn't think it important to validate.
• derekjbernard 4y ago
  All forms should have input validation before you do things like try and store it or god forbid process it inside code. Instead of regex a better move might be using a forms validation library that works well and is actively maintained.
  • Avamander 4y ago
    Report as spam, it starts to hurt the sender in the end.
• VincentEvans 4y ago
  Validate emails in a manner that is representative of the typical use of your service. If it’s a specialist email processing tool, then you should probably follow an RFC. If it’s a dating app, you can probably just use a regex that covers common cases to help users avoid typos. I think the decision is similar to the one picking how modern are the browsers you are going to support. It’s a trade-off. That’s my take on it, don’t have a cow, man.
  • remram 4y ago
    You will want to check ownership by sending a verification email anyway. If you want to avoid typos, show a "are you sure... yes/no" warning, there is no need to block anybody. Typos will overwhelmingly lead to valid-looking addresses anyway.
    • kube-system 4y ago
      I usually just validate that there’s an “@” character. It prevents the most obvious typos like a blank field, or information entered in the wrong field. You’re right that you can’t prevent someone from typing their address incorrectly, but you can make sure they didn’t put in their phone number or their first name by mistake
      • deleted 4y ago
        [deleted]
      • lkbm 4y ago
        Mailgun has an API endpoint that works pretty well. If you enter "foo@gnail.con", it suggests "foo@gmail.com". It's overkill for an HN registration form, where if I type my email wrong, I can just re-register, but for checkout forms it can be worth putting in a little extra validation.
    • VincentEvans 4y ago
      I agree, but there are all kinds of scenarios where you might need to simply answer a question - “is this an email address, and does it look valid?”. I needed to do just that once - I was given a flat file with some bulk export data that came from some other system that I had no exposure to and needed to clean up contact data by figuring out what was what, separating names from phone numbers, from postal addresses, from emails, etc. It just needed some rate of success, not to be perfect. Lets not assume that we always know what people are trying to do and what is the best way to do it. Devil is in the details.
• orwellg1984 4y ago
  please don't do this, i like website using those shitty regex, allows me to use shit address instead of temporary ones..
• Biganon 4y ago
  1) simple regex to rule out the common typos such as 2 or 0 @, no period in the domain name, etc. I don't care about people whose domain name consists of a TLD only. Bring your nerdiness somewhere else, every other service is already rejecting your exotic e-mail address already anyway. Same for spaces in the local part of the address, etc. 2) if second level domain not in list of famous second level domains, AND levenschtein distance is small with a domain on the list (typically gmial, oultook, yhaoo,...), display a huge warning. Don't refuse if the user insists it's correct, but show a huge and red warning that blinks. Same with the TLD to detect "cmo", "ogr", "inof" etc. 3) Maybe send a validation email, now that you've ruled out a big number of potential mistakes. You won't get that many bounces. Or don't send the email if you don't need to! I fail to imagine a scenario that wouldn't be neatly covered by this 3-step process.
  • ryandrake 4y ago
    > I don't care about people whose domain name consists of a TLD only. I’ve never understood this, but heard it often from developers and product owners in the industry. “I don’t care about the small number of users who X” where accommodating X is essentially free. Or worse: deliberately taking the eng time to reject users X where accepting takes no work! Especially in a business context where users X are trying to hand the business money. I had a tech lead once who say we should reject non-ASCII characters in user input “because they are an edge case.” Nothing in the rest of the data flow or database storage required ASCII characters and it took eng effort to filter them out. Boggles the mind sometimes.
    • Jiro 4y ago
      Accomodating an individual X is essentially free. Having a policy of accommodating all the X's that turn up is not free because those small individual expenditures add up.
• user3939382 4y ago
  The worst is the behavior from, for example, CVS, where they accept a .email TLD in one place and reject it in another. At least have one set of rules. PayPal has the same problem.
• aetherson 4y ago
  I wrote an email validating regex at one point. It checked that there was exactly one @ sign in the address, which was neither the first nor last character. Seemed like a pretty good compromise to me.
  • maxk42 4y ago
    Still incorrect. Valid email addresses can contain multiple '@'s as long as all but one are quoted.
    • antihero 4y ago
      Yes but why would you do this other than to be extremely smug when forms fail for you?
    • aetherson 4y ago
      And we lost the 0.00001% of the market that has such an email address.
    • eli 4y ago
      Says who? I don't consider that address valid.
• kuharich 4y ago
  Past comments: https://news.ycombinator.com/item?id=4486108 https://news.ycombinator.com/item?id=4486108
• anothernewdude 4y ago
  You can validate the field with whatever you want. It's going to be your data that you have to deal with later. Don't want users to use comments in emails? Don't validate them. There is not reason whatsoever to validate to a standard just because it's a standard. Validate to what you will support.
• stavros 4y ago
  I gave a very fun talk on the topic in FOSDEM (VOLUME WARNING!): https://www.youtube.com/watch?v=xxX81WmXjPg https://www.youtube.com/watch?v=xxX81WmXjPg It's more a joke than edifying, but it was very fun for me (and, I think, the audience), and illustrates the difficulty of email validation well.
  • lkbm 4y ago
    I've always loved the "Email Hates The Living" talk[0] and am sad it's not available in higher quality. This is a great alternative. [0] https://www.youtube.com/watch?v=4s9IjkMAmns https://www.youtube.com/watch?v=4s9IjkMAmns
• throwaway787544 4y ago
  Half the computers in the world don't realize that + is a valid character in an email address, because programmers keep rolling their own email validation.
• bachmitre 4y ago
  ok
• fock 4y ago
  My private mail is just _@mydomain. Recently some gov website didn't want that as an input...
  • allenu 4y ago
    I have an email that has “spam” in the name and I remember some form long ago disallowing its use. I assume they denied it thinking it was fake.
• charles_f 4y ago
  The only way to validate an email is to send a message to the email address. Validating that it fits the rfc is pointless, because a) its very easy to create an email that is both false and meets the rfc, b) email provider might bypass the rfc and the email would still be working. To validate user input, I use that: /^[^@]+@[^.]+\..+$/. It's doesn't tell me if the email is semantically correct per the rfc because I'm not running an rfc correctness validation service. What I want is to make sure that users didn't input their name in the email field. This tells me if it ressembles an email
  • northisup 4y ago
    It isn’t pointless. It is fast feedback for typos and form validation
    • wombatpm 4y ago
      But the proof of the validation is in the sending. If it’s important I send a validation email
      • lolinder 4y ago
        There is some value in reducing the number of bad emails sent out, because email providers don't like it if you send large numbers of emails to bad addresses. So if you can help someone get their email right the first time, it's worthwhile, as long as the mechanism you use isn't overbearing.
    • lolinder 4y ago
      The parent's regular expression covers the most egregious typos without making any assumptions about domain names or tlds. If you wanted to help out with common typos you could add additional logic to specifically check for "*@gmial.com" or other permutations of the common domains. If you wanted to get really fancy, you could even run it by an edit distance function against the common domains and warn if they're close to a common one but not quite there. Most typos, however, are likely to be in the first part, not in the domain. The only real way to validate against those is to try the address and see.
• jmbwell 4y ago
  I think the point of the article is that this seems like it would be an easy problem to solve, but it is not. Lots of commenters insisting that they need to validate somehow. If you have a need to validate, use a good email validation library. Better consistency throughout your app, and someone else has figured out the hardest stuff. Stop validating emails. But if you can’t stop, at least stop rolling your own regex on the fly to do it. Use a good library instead.
• elif 4y ago
  As a former email professional this hurts bad... Why validate? JusT SpAm!? It's quasi-legal. Bounce rate? Who cares!! Not like we are monitoring ip reputation anyway amirite?
• egberts1 4y ago
  Just chiming in on about the ‘local-part’ of the email address. I wrote a short (but incomplete) research comparing mail servers (MTAs) and their handling of local-part in my ongoing effort to reduce spam and to tackle who is leaking my email address. ‘Local-part’ is the part of the email that is between your account name and the ‘@‘ symbol. For some MTAs, it CAN be the part before your account name. https://egbert.net/blog/articles/comparison-of-local-part-in-mtas.html https://egbert.net/blog/articles/comparison-of-local-part-in...
• nerdjon 4y ago
  I think an initial test with regex is valid. But you should do a proper email validation link. That being said, you need to be very careful with what regex validation you are doing. I still use an apple "@me.com" email. Somewhere there is a commonly used library (or commonly used regex copied from stack overflow) that seems to fail because my domain is short. I have had a number of times that I have been unable to get emails because a system flagged it as invalid. Getting through to support or trying to change my email is always a nightmare in these situations. So be careful with your assumptions!
  • foofoo4u 4y ago
    Similar experience for me. Many online forms fail to accept any email extension that isn't ".com", ".net", ".edu" or ".org". I'm surprised, because developers should know better that there are many more extensions beyond these four. Here is a full list of domain extensions available: https://www.name.com/domains https://www.name.com/domains . Let's just say one of these is registered and used as my email. I have found two ways of getting around this issue. 1) Continue registration for a new site using a temporary email. Once logged in, I find I am often allowed to change the email to whatever I want within my user settings. 2) Contact support and request they updated it for me manually. These two work arounds don't always work. But more often than not they do.
    • kingcharles 4y ago
      I have the same problem on about 10% of sites. I had a big ecommerce site go into their DB the other day and update from my temp email to my real. Now my profile is fucked because it validates the email address on the page load.
    • teddyh 4y ago
      Here is the actual, official, list of TLDs: https://www.iana.org/domains/root/db https://www.iana.org/domains/root/db
      • foofoo4u 4y ago
• northisup 4y ago
  Why are rfc compliant regexes not a part of the stdlib of most languages?
• RajT88 4y ago
  If you are concerned with the maintainability of RegEx (i.e. "Now you have 2 problems"), do it via simple string parsing. It's more code, but it's readable by mere mortals. If it has an @ sign, split at the @ sign. If either string has a space or other invalid character, it's invalid. Yes, there are more invalid characters for the domain than the username (I would make the case the username should just be whitespace chars, and the @ sign). If the second string doesn't have a dot in it, it's invalid. Split the second string by dot. If the last string of that array is not a valid TLD, it's invalid. (I realize new TLD's are popping up these days, so this step may not be strictly needed) Not being too strict is in your interest here. You avoid too many email bounces by allowing some things which may be bad but allowed in some email providers but not others. It's a case of "Perfect is the enemy of good enough".
  • deleted 4y ago
    [deleted]
  • supermatt 4y ago
    > If either string has a space or other invalid character, it's invalid Nope, could have a quoted string which can contain whitespace. addr-spec = local-part "@" domain local-part = dot-atom / quoted-string / obs-local-part qtext = %d33 / ; Printable US-ASCII %d35-91 / ; characters not including %d93-126 / ; "\" or the quote character obs-qtext qcontent = qtext / quoted-pair quoted-string = [CFWS] DQUOTE *([FWS] qcontent) [FWS] DQUOTE [CFWS] > If the second string doesn't have a dot in it, it's invalid. Nope, domain names dont require a dot. <domain> ::= <subdomain> | " " <subdomain> ::= <label> | <subdomain> "." <label> > Split the second string by dot. If the last string of that array is not a valid TLD, it's invalid. (I realize new TLD's are popping up these days, so this step may not be strictly needed) Doesnt need to be a "valid TLD" to be a valid domain
    • RajT88 4y ago
      Sure. Fine. Skip that part then. The larger point I was trying to make still stands.
• rendall 4y ago
  I've been seeing this kind of argument from the mid-levels on my current team, paraphrased like this: "I am having a hard time understanding this, therefore it needs to change."
  • b3morales 4y ago
    That can be a valid complaint as long as it's not about the logic or rules themselves, but how they're expressed in the code. Code that your team members can't work on is a liability.
    • rendall 4y ago
      Agreed. I see complexity as kind of a mass, and our job is in part to reduce it as far as possible. Like mass, you can shuffle complexity around, or add more, or discover unexpected ways to reduce it, but there is no way to reduce it below the problem's lower bound. Sometimes, the solution is as simple as it's going to get, and it's still complicated. State management is a good example. I'm more referring to that situation. This article's headline is an example of the argument I mean. If not using Regex is the proposal for reducing complexity, it's not going to reduce complexity.
      • b3morales 4y ago
        > Sometimes, the solution is as simple as it's going to get, and it's still complicated. State management is a good example. I'm more referring to that situation. That's fair. There is definitely irreducible, or essential complexity that we have to deal with.
• Avtomatk 4y ago
  Regular expressions are validators of user input. Verification of user inputs are very important because they provide error messages, if you just send an email and it fails it can be for many reasons: 1. The user made a mistake when typing the email. 2. Some internal server failed to send the email. Without an error, the user will never know what went wrong.
• adalu 4y ago
  ``` //pseudo Go import ( "strings" "internal/inputs" ) func emailValid(input inputs.ProfileInput) bool { if len(input.Email < 3) { return false } return strings.Contains(input.Email, "@") } ``` An email should be at least 3 chars long and contain a @ sign to be valid. a@a can be a valid email address if your hostname is a and your mta accepts the email address. A user a may or may not exist (virtual). And as the author wrote 10 years ago, if the mail doesn't arrive, no validation can help if the email address doesn't exist. But len>=3 and @ sign presence is enough of a sanity check.
  • leohonexus 4y ago
    I like the simplicity, but @@@ isn’t a valid email address (and .@. isn’t too, same as @…---…, and soon enough we’ll quickly regress back to the original problem of having too long of a regex)
• chadlavi 4y ago
  I dunno, I think something very broad like /.+@.+\..+/ is probably good enough to catch like 99% of input problems. Gimme a string, an at-symbol, a string, a period, then another string. I don't think you can actually have an email that won't match this pattern? But instead of showing an error you can just kinda say, hey are you sure you want that? and let them do it anyway. this is more of a validation suggestion.
• standardUser 4y ago
  The last time I implemented something like this we used a little library to check for typos on common domains and gave users a chance to correct on the front end before submitting. It significantly cut down the frequency of bad email addresses. All of the other stuff is important too, but the most common issue is going to be someone tying "gnail" instead of "gmail", not having an obscure domain. On a related note, I have mylastname@gmail.com and I receive emails from other people with my last name several times every week. I am almost certain they mean to type [firstinitial]mylastname@gmail.com but miss that first character. That's my working theory anyway. I've had to intervene multiple times when getting sent important medical emails for a different person with my same last name.
• thyrox 4y ago
  I think normalising emails is equally important these days, esp if you are offering any sort of free trial on your website (that incurs a cost to the seller) as it has become quite common for freeloaders to create dozens of accounts using the dots and plus signs just to abuse the free services.
• neoCrimeLabs 4y ago
  2012? And it seems so little has changed. Several times per month I am told by websites that my supplied email isn't valid even though it can receive email. All because it is using one of the "new" top level domains ".email" and has been for 6+ years now. The breakdown of websites this happens most on are large corporate websites or very small online shops using some no-name shopping cart software.
• harshreality 4y ago
  This is almost entirely because a lot of websites stupidly reject +. A few stupidly reject - or _ too. That's easy to fix while still using regex validation. There might be some people who run their own webservers and use more exotic addresses (local parts), but 100% of them also have more normal email address they use for random website signups. If all websites would make sure to accept + in local parts, and - and _ everywhere, there wouldn't be enough people angry at the situation for articles like this to be written and generate any traction at all. Sending emails might cost a fraction of a cent if you use a 3rd party service. When it's not free, regex validation can save money. There's a potentially valid reason to do it. Or maybe the people writing the website's javascript are just control freaks. So what? That's not a reason to argue for all websites to stop doing regex email address validation. Allow + in the local part, along with - and _ everywhere. That's all you have to do. You don't have to give up regex validation and try to send every typo'd email address that a visitor might enter on a form.
• meristem 4y ago
  And then there are the validations that do not accept emails longer than x number of characters. (Personal experience, yes.)
• EVa5I7bHFq9mnYK 4y ago
  I have a domain that is all digits. It passes validations in 99% of web forms, but email silently fails to deliver in about 10% of cases. So there is a great disconnect between web form validations and actual mail sender validations.
• jrnichols 4y ago
  all these years later, and I still encounter systems that refuse to accept anything but a com/net/org/gov/edu email address. I have one ending in .fyi and .life and it's a no-go with a few places. Toyota, Paramount, and Experian come to mind.
• joshdata 4y ago
  It's complicated but thankfully you don't have to reinvent the wheel: https://github.com/JoshData/python-email-validator https://github.com/JoshData/python-email-validator (my project) The README covers a lot of ground: internationalized domain names, internationalized local parts, SMTPUTF8, Unicode normalization, not performing SMTP checks, not permitting obsolete email syntax, and missing UCS-4 support in Python 2.7.