6 ms·

Regexp-based RFC822 email address validation

105 points by jondot 14y ago

fuzzix 14y ago
Email validation is indeed a complex and occasionally surprising beast. Clearly this regex is impractical, but any validation you invent yourself is likely incorrect. The best way to validate email addresses remains sending an email to them.
- rmccue 14y ago
  +1, seeing as you're probably going to be sending an activation email anyway. You can do some practical checks, like checking that there's a '@' in the email, and probably trimming spaces (I think leading/trailing whitespace isn't allowed, from memory).
  - HyprMusic 14y ago
    In RFC822 spaces are actually allowed, I think they just have to be in a quoted string.
- regularfry 14y ago
  Is it impractical, though? It's already been written, and I've not seen any suggestion that it's not correct (other than the problem with comments, but that's intrinsic to regexes in general). As long as you're going to follow up by actually sending an email, I don't see a problem with this as a first-pass filter.
jmedwards 14y ago
I had a quick glance through the expression, looks good from here.
- jmedwards 14y ago
  (where here = an asylum for the insane.)
bdg 14y ago
Great, now I have something to strike fear into the hearts of new devs who ask me about email validation. I'm not sure I'm comfortable using a regex like this in production. Sure, we can write lots of tests and ensure it performs correctly, and the rfc is unlikely to change so once proven solid it won't change... but using this just feels wrong. Like I'm using the dark side of the force.
billyjobob 14y ago
This regex tests for RFC 822 compliance, but what if you get a user who has an email address that itself doesn't comply with the RFC?
- ygra 14y ago
  Then they have a hard time receiving mail from anyone, I guess.
- jacques_chester 14y ago
  Actually, it doesn't. Email addresses can't, strictly speaking, be tested for with regexes. This one "only" tests various nestings to I think about 3 levels deep.
message 14y ago
Old as hell
- ta12121 14y ago
  It boggles my mind too. This is new to people here?
rplnt 14y ago
It was posted a fews days ago in this thread http://news.ycombinator.com/item?id=4774426 http://news.ycombinator.com/item?id=4774426 with a great comment: > If seeing this doesn't make you second guess using a RegExp when a parser is more appropriate, well...you might be a Perl programmer?
- fungi 14y ago
  i'm building a simple offline webapp for collecting email addresses at an event on an ipad with no internet connection. im using a simple regex (may use this one instead) to validate email before sticking in localStorage for latter retrial... if not with regex, how should i validate the email addresses?
  - lucian1900 14y ago
    A parser would likely be shorter and easier to understand.
    - tjgq 14y ago
      They hint that they use this huge regex instead of a parser for performance reasons. At any rate, the regex was not written by hand; it is a concatenation of simpler, easier to understand regexes.
  - VMG 14y ago
    don't
  - jlarocco 14y ago
    As somebody else said, don't. If you really feel you need some kind of validation, have two email fields so the user can enter it twice and double check it themselves. No matter how much effort you put into it, and how complicated your validation code is, if the users want to mess with you, they can always just enter a valid fake address, so there's no point wasting a lot of energy on it because it's easy to defeat anyway. And since it's impossible to validate addresses with a regular expression, there's a small chance you'll reject a valid address and look dumb.
Jabbles 14y ago
As others have said, the only way to know if an email address is valid is to try and send an email. This doesn't mean that this is useless, as you may want to get users to double-check their input if it doesn't pass this. Some test cases to think about: http://isemail.info/_system/is_email/test/?all http://isemail.info/_system/is_email/test/?all
- oinksoft 14y ago
  There is a middle ground ... I have had success using an approach like the one found in this Python library: http://pypi.python.org/pypi/validate_email http://pypi.python.org/pypi/validate_email It performs regex validation, and if that passes, tries to get the SMTP server to validate the user's presence. Quite useful for when a user might fat-finger their username in the address. So, for compliant mail servers, sending an email without verifying receipt via some confirmation token is no more reliable than this method (if it will falsely validate the user, it will probably falsely digest the message as well).
  - bjourne 14y ago
    Be careful as validating email addresses like that will quickly get you grey or blacklisted by various spam cops. The method works well for a few addresses, but you can't use it to validate thousands of addresses at the same time. I learnt that the hard way. :)
    - oinksoft 14y ago
      That makes a lot of sense ... a reliable way to determine if a user is real could easily be abused.
    - mosselman 14y ago
      Could you expand on this? Why will it get you black listed? What kind of situation are we talking about? It would be pretty annoying to get black listed.
      - 14y ago
meaty 14y ago
I only check for an @ and at least one character either side. Anything else is the user's problem.
- sgt 14y ago
  Same here, and personally I don't see the justification for spending all those CPU cycles going through a massive regular expression such as this one. I'd rather put this on the client side (javascript), as a validation to make sure the user doesn't supply an invalid e-mail address by accident (i.e. for his own convenience and nothing else).
  - blibble 14y ago
    compared to pushing the response back out to the client, the cost of matching against that regex is going to be insignificant, even with it being as monstrous as it is. (note that I'm not saying using that regex is a good idea!)
- jnazario 14y ago
  actually you may want to make sure they have at least four characters separated by a dot, e.g. .\@\\.[..]+ ... and i think this is how the regex begins ... my point though is that you can't send mail to a TLD, you need a domain name. and i don't think we have any one character TLDs. this is quickly turning into an exercise where you see how such a regex starts to happen. "well, then you have to consider this case ... and handle these exceptions ... and then enforce this ..."
  - derefr 14y ago
    But you can send mail to, say, a machine listed as "a" in your hosts file.
  - Adirael 14y ago
    And with the new personalized TLDs, wouldn't you be able to have something like ceo@nike? I just check for an @ and at least a character after and before it.
culshaw 14y ago
A more modern thought. Do you really need to test that strictly for an email address? If the user is trying to give you a fake email address, chances are they don't want to be part of your service/offering anyway. I test for an @ and characters either side, that's most flexible bases covered. I know this doesn't apply to all scenarios but it's one worth considering.
- nathan_long 14y ago
  You probably want to ensure that there's a dot somewhere to the right of the @, also, but yes, that sounds sane to me. "something@something.something" Start of line, at least one non-@, @, at least one character, dot, at least one character, end of line. ^[^@]+@.+\..+$ Test: http://rubular.com/r/G69q1k6fP2 http://rubular.com/r/G69q1k6fP2 If it fits that, try emailing them.
  - perokreco 14y ago
    There doesn't need to be a dot on the right side.
    - deleted 14y ago
      [deleted]
    - xyzzy123 14y ago
      I found your comment fairly cryptic. I had a fun twenty minutes trying to work out what you meant, and under what circumstances dotless RHS in email addresses might be legal. I suppose from the RFC, sure the spec doesn't require dots. For example, I can use http://mythic-beasts.com/~pdw/cgi-bin/emailvalidate http://mythic-beasts.com/~pdw/cgi-bin/emailvalidate and verify that sure, '1@2!3!4' is a valid RFC822 email address. But I think e.g. UUCP-style addreses are a pathological case, and we don't _really_ want users signing up with them. Another option would be intranets, e.g. 'baker@internal', but again I think that's being a bit pedantic, since most people on HN are writing webapps for the public Internet, not mail clients. So can we get an email with foo@<some-dotless-string> routed across the public Internet? Even a bounce would do :) You might be able to do a riff on xyzzy123@[23.55.211.36] (e.g xyzzy123@[389534500] or xyzzy123@[1737D324]. However, do you _really_ want your users to specify these? There are mx records for existing TLDs (e.g. com, org, au, mx) - but all the mx records I tried refused connections on port 25. So no mail for 'xyzzy123@com' :( So gTLDs are another option, and there was a time when it looked like xyzzy123@xyzzycorp might route (as long as it didn't collide with anything on the local resolver's search list). But it seems that dotless use of gTLDs is seriously deprecated at this point, and that ICANN will treat it as a TOS violation: http://domainincite.com/10254-why-domain-names-need-punctuation http://domainincite.com/10254-why-domain-names-need-punctuat... Basically, ICANN's conclusion was that dotless TLDs are a terrible idea for many technical reasons. I looked into IDNs too, but of course due to the way DNS works, you can't really get around the dots. So the conclusion of all this is that: 1) Using an RFC822 regex is a terrible way to check emails. The things it thinks are valid are MUCH wider than what you actually want. 2) You should probably check the RHS against a public suffix list if you are e.g. accepting a user email address on a signup page. If you accept dotless TLDs or other constructions (e.g. ips on RHS) there is some (low, but nonzero) risk that a malicious user could cause your systems to route mail to your other systems internally.
chris_wot 14y ago
The only thing I've ever seen that is worse than this is the sendmail configuration file.
xentronium 14y ago
Please note that RFC822 also covers some unusual forms of writing an address; all of the following are correct addresses: * John Doe <john.doe@example.com> * foo:a@b.example,c@d.example,e@f.example; * john.doe@example.com (John Doe) See also the excellent explanation by Jukka Korpela for more details: http://www.cs.tut.fi/~jkorpela/rfc/822addr.html http://www.cs.tut.fi/~jkorpela/rfc/822addr.html
- deweerdt 14y ago
  Yes, absolutely. When people want to validate an email address, it's more likely they're referring to the SMTP envelope address: http://tools.ietf.org/html/rfc5321#section-4.1.2 http://tools.ietf.org/html/rfc5321#section-4.1.2 RFC 822 (RFC 5322 in its more recent incarnation) refers to the From: header in the email, RFC 5321 refers to the address used in the 'MAIL FROM:' (and RCPT) SMTP command.
- dfox 14y ago
  and if i remember correctly, this regexp should also accept foovax!example.com!john.doe, which is certainly something you do not want to accept
Smrchy 14y ago
For JS validation on the client i use this: http://blog.tcs.de/javascript-near-perfect-email-validation--check-routine-as-string-prototype/ http://blog.tcs.de/javascript-near-perfect-email-validation-... A lot shorter and has only 3 cases that would not be detected. Enough for 99.x% of all entered emails.
jrajav 14y ago
I can't find an online tester that doesn't choke on this, but if you're curious to try it out, here's the token Perl one-liner: echo "x@y.com" | perl -lne 'print "$_ is valid!" if /(?:(?:\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])*)?(?:[^()<>@,;:\\".\[\] \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])*)?(?:[^()<>@,;:\\".\[\] \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*(?:(?:[^()<>@,;:\\".\[\] \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*)/'
JimWestergren 14y ago
With PHP the following simple code works great for me: function validate_email($email) { if(filter_var($email, FILTER_VALIDATE_EMAIL) === FALSE) { return false; } else { return true; } }
adv0r 14y ago
This validation ignore one exception : Gmail allows users to enter an arbitrary number of dots . Therefore these are a valid email addresses : your......name@gmail.com y.o.u.r...name....@gmail.com and all resolve to yourname@gmail.com http://support.google.com/mail/bin/answer.py?hl=en&ctx=mail&answer=10313 http://support.google.com/mail/bin/answer.py?hl=en&ctx=m...
- Lockyy 14y ago
  And this is a problem I constantly run into with web services, some throw an error if I use a ., others throw an error if I try to do something like example+note@example.com. I use one or the other to help sort emails. It's even worse when a sign up form accepts an email in the latter format, but the login form does not for some reason. So I have an account with a note added but I cannot login. I had this problem with the Odeon website for a while, eventually had to phone them up and ask them to change my accounts email address to one without a note.
roel_v 14y ago
This is from "Mastering Regular Expressions", by Jeffrey Friedl, O'Reilly 1997. The book presents it as a 'fun' example of how to write huge regex'es that are still understandable and maintainable (the version posted here is without all the comments that are in the book).
habosa 14y ago
I find it pretty entertaining that this RegEx is so big that visual patterns emerged. In my browser there are clear diagonal lines of "@" symbols across the RegEx. If it looks like ASCII art, your RegEx is probably too big.
3ds 14y ago
As per html5 spec the recommended regex is: /^[a-zA-Z0-9.!#$%&'+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)$/ http://www.w3.org/TR/html5/states-of-the-type-attribute.html#valid-e-mail-address http://www.w3.org/TR/html5/states-of-the-type-attribute.html...
- stratoukos 14y ago
  This will not match addresses with non latin characters.
  - mitchty 14y ago
    Yep, shouldn't the right answer be: accept whatever the user gave you, validate it with a link in the email you send that they've received it. Should be even more important if you ever intend to do business with say someone from China. Good luck dealing with validating hanji in an email.
  - tedunangst 14y ago
    Addresses do not have non Latin characters.
    - Aissen 14y ago
      Which is false: http://tools.ietf.org/html/rfc6530 http://tools.ietf.org/html/rfc6530 http://tools.ietf.org/html/rfc6531 http://tools.ietf.org/html/rfc6531 http://tools.ietf.org/html/rfc6532 http://tools.ietf.org/html/rfc6532 http://tools.ietf.org/html/rfc6533 http://tools.ietf.org/html/rfc6533
      - tedunangst 14y ago
        Relying on standards that new for something like email would be a mistake IMO. Ymmv.
- ambiguity 14y ago
  You are missing a * just before the $.
crusso 14y ago
I've been watching people deal with this problem for years and years... why? I can parse a CSV file far more easily. You'd think there would be an RFC that specifies a simple email address format that everyone can follow. If you don't conform to that format, your email gets dropped on the floor until you get a better client.
- DanBC 14y ago
  This is one of the things that people really want for email2. Unfortunately email works well enough, and has such a massive install base, that email2 is never going to happen. That's why you see so many "Email but not email" startups.
topbanana 14y ago
The point of regex is to be human readable. This might as well be a binary blob
bryanlarsen 14y ago
This is a generated regexp, it's not hand crafted. Making fun of it is like pasting up machine code compiled from C and saying "machine code sucks".
gvalkov 14y ago
I'm surprised there isn't a Perl6 version of Mail::RFC822. This is exactly the kind of thing that Perl6 rules[1] are supposed to excel at. It would be good publicity, especially now that rakudo has usable releases. [1]: http://en.wikipedia.org/wiki/Perl_6_rules http://en.wikipedia.org/wiki/Perl_6_rules
turshija 14y ago
'@'.' is a valid email address. seriously ? :)
1nvader 14y ago
This regex deserves a downvote! If you don't undertand it (and i guess you don't if it's not written by hand) - don't never ever use it! The only way to validate a email adress is to send a validation mail/link.
smackfu 14y ago
Validation of emails is pretty pointless since most errors will be typos that pass the regex anyway. You're better off trying to give warning messages based on common typos.
CalvinCopyright 14y ago
Makes me think of the first reply to this StackOverflow question: http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags http://stackoverflow.com/questions/1732348/regex-match-open-...
- michaelhoffman 14y ago
  But, unlike XHTML, it is possible to validate an e-mail address with a regular expression (assuming comments have been removed).
  - _delirium 14y ago
    It's also, unlike XHTML, not particularly easy to do it with a parser: most of the complexity of the regex is due to the litany of edge cases for what constitutes a valid email address, not due to it being a regex.
mosselman 14y ago
E-mail validation can be useful, but I would stay away from this thing. Look at what you are trying to do from a higher level. Most likely the user wants something from you as well as you from them. If a user gives you a bad e-mail, despite a very basic e-mail regex, whatever, they won't get an e-mail, not my problem. If it is to register on your website, just let them, send them a confirmation e-mail to their 'email', meanwhile allowing them to use the system (or not). Then if after x-time they haven't confirmed, just delete the user again. This will save you a lot of trouble. If you want something more high-tech like checking a huge list of e-mails in a system you could go with a solution suggested below, just send them an e-mail. Regex is evil!
saurik 14y ago
This concept been covered on Hacker News so many times before. :( During a similar conversation 70 days ago, I left a detailed comment that is also relevant now regarding how RFC822 is actually totally irrelevant for the concept of e-mail addresses: what it specifies is how to escape the field values in MIME headers, and thereby has a bunch of rules for how to format an e-mail address that are really "how to embed an e-mail address in a MIME document". RFC821, the SMTP specification for how you actually send e-mail, is closer, but has different rules about what is allowed because SMTP isn't MIME. A couple things aren't allowed, and some other things now are allowed and don't need to be escaped. Why people think users should type e-mail addresses in RFC822 escaping and not RFC821 escaping makes no sense to me. However, the real punchline is: why are you asking users to enter e-mail addresses escaped at all? If you have an HTML form, for example, you don't need to escape them, as there is no higher-level protocol in which they are being embedded: the box can contain any characters that are needed, and there are no concepts like MIME comments, etc.. Asking a user to escape their e-mail address in that box is as silly as asking them to escape their username or password according to HTML or URL or some other escaping rules. Or, imagine if they had to enter their full name, but escaped using MIME encoded words... =?iso-8859-1?Q?=A1Hola,_se=F1or!?= makes about as much sense as escaping your e-mail address. My original comment, which contains many more details about which specific RFCs are involved and what they mean, along with specific examples where things can get different, and a discussion of the context, here: http://news.ycombinator.com/item?id=4486872 http://news.ycombinator.com/item?id=4486872
- andrewvc 14y ago
  So, your reply 70 days ago was in reply to me regarding the ruby library Evan and I wrote. Funny enough, this perl regex was one of the inspirations for the ruby library Evan and I wrote (though that uses a PEG for parsing) Weird how things go around...
dutchbrit 14y ago
There's a very nice function in PHP that validates emails. filter_var('foo@bar.com', FILTER_VALIDATE_EMAIL); The actual beast: https://github.com/php/php-src/blob/master/ext/filter/logical_filters.c#L499 https://github.com/php/php-src/blob/master/ext/filter/logica...
dfox 14y ago
email address validation should not be motivated by what is valid address by some RFC, but what you feel confortable passing to your MTA, because you have exact understanding of what will happen. On the application side you probably don't want to store adresses with comment and real name fields and other such only human readble data. My rules are: contains exactly one @, contains zero or more +, does not contain any other characters that are special cased by this (notably ',', ';' and '!').

105 points by jondot 14y ago

Email validation is indeed a complex and occasionally surprising beast. Clearly this regex is impractical, but any validation you invent yourself is likely incorrect. The best way to validate email addresses remains sending an email to them.

rmccue 14y ago
+1, seeing as you're probably going to be sending an activation email anyway. You can do some practical checks, like checking that there's a '@' in the email, and probably trimming spaces (I think leading/trailing whitespace isn't allowed, from memory).
- HyprMusic 14y ago
  In RFC822 spaces are actually allowed, I think they just have to be in a quoted string.
regularfry 14y ago
Is it impractical, though? It's already been written, and I've not seen any suggestion that it's not correct (other than the problem with comments, but that's intrinsic to regexes in general). As long as you're going to follow up by actually sending an email, I don't see a problem with this as a first-pass filter.

jmedwards 14y ago

I had a quick glance through the expression, looks good from here.

jmedwards 14y ago
(where here = an asylum for the insane.)

bdg 14y ago

Great, now I have something to strike fear into the hearts of new devs who ask me about email validation. I'm not sure I'm comfortable using a regex like this in production. Sure, we can write lots of tests and ensure it performs correctly, and the rfc is unlikely to change so once proven solid it won't change... but using this just feels wrong. Like I'm using the dark side of the force.

billyjobob 14y ago

This regex tests for RFC 822 compliance, but what if you get a user who has an email address that itself doesn't comply with the RFC?

ygra 14y ago
Then they have a hard time receiving mail from anyone, I guess.
jacques_chester 14y ago
Actually, it doesn't. Email addresses can't, strictly speaking, be tested for with regexes. This one "only" tests various nestings to I think about 3 levels deep.

message 14y ago

Old as hell

ta12121 14y ago
It boggles my mind too. This is new to people here?

rplnt 14y ago

It was posted a fews days ago in this thread http://news.ycombinator.com/item?id=4774426 http://news.ycombinator.com/item?id=4774426 with a great comment: > If seeing this doesn't make you second guess using a RegExp when a parser is more appropriate, well...you might be a Perl programmer?

fungi 14y ago
i'm building a simple offline webapp for collecting email addresses at an event on an ipad with no internet connection. im using a simple regex (may use this one instead) to validate email before sticking in localStorage for latter retrial... if not with regex, how should i validate the email addresses?
- lucian1900 14y ago
  A parser would likely be shorter and easier to understand.
  - tjgq 14y ago
    They hint that they use this huge regex instead of a parser for performance reasons. At any rate, the regex was not written by hand; it is a concatenation of simpler, easier to understand regexes.
- VMG 14y ago
  don't
- jlarocco 14y ago
  As somebody else said, don't. If you really feel you need some kind of validation, have two email fields so the user can enter it twice and double check it themselves. No matter how much effort you put into it, and how complicated your validation code is, if the users want to mess with you, they can always just enter a valid fake address, so there's no point wasting a lot of energy on it because it's easy to defeat anyway. And since it's impossible to validate addresses with a regular expression, there's a small chance you'll reject a valid address and look dumb.

Jabbles 14y ago

As others have said, the only way to know if an email address is valid is to try and send an email. This doesn't mean that this is useless, as you may want to get users to double-check their input if it doesn't pass this. Some test cases to think about: http://isemail.info/_system/is_email/test/?all http://isemail.info/_system/is_email/test/?all

oinksoft 14y ago
There is a middle ground ... I have had success using an approach like the one found in this Python library: http://pypi.python.org/pypi/validate_email http://pypi.python.org/pypi/validate_email It performs regex validation, and if that passes, tries to get the SMTP server to validate the user's presence. Quite useful for when a user might fat-finger their username in the address. So, for compliant mail servers, sending an email without verifying receipt via some confirmation token is no more reliable than this method (if it will falsely validate the user, it will probably falsely digest the message as well).
- bjourne 14y ago
  Be careful as validating email addresses like that will quickly get you grey or blacklisted by various spam cops. The method works well for a few addresses, but you can't use it to validate thousands of addresses at the same time. I learnt that the hard way. :)
  - oinksoft 14y ago
    That makes a lot of sense ... a reliable way to determine if a user is real could easily be abused.
  - mosselman 14y ago
    Could you expand on this? Why will it get you black listed? What kind of situation are we talking about? It would be pretty annoying to get black listed.
    - 14y ago

meaty 14y ago

I only check for an @ and at least one character either side. Anything else is the user's problem.

sgt 14y ago
Same here, and personally I don't see the justification for spending all those CPU cycles going through a massive regular expression such as this one. I'd rather put this on the client side (javascript), as a validation to make sure the user doesn't supply an invalid e-mail address by accident (i.e. for his own convenience and nothing else).
- blibble 14y ago
  compared to pushing the response back out to the client, the cost of matching against that regex is going to be insignificant, even with it being as monstrous as it is. (note that I'm not saying using that regex is a good idea!)
jnazario 14y ago
actually you may want to make sure they have at least four characters separated by a dot, e.g. .\@\\.[..]+ ... and i think this is how the regex begins ... my point though is that you can't send mail to a TLD, you need a domain name. and i don't think we have any one character TLDs. this is quickly turning into an exercise where you see how such a regex starts to happen. "well, then you have to consider this case ... and handle these exceptions ... and then enforce this ..."
- derefr 14y ago
  But you can send mail to, say, a machine listed as "a" in your hosts file.
- Adirael 14y ago
  And with the new personalized TLDs, wouldn't you be able to have something like ceo@nike? I just check for an @ and at least a character after and before it.

culshaw 14y ago

A more modern thought. Do you really need to test that strictly for an email address? If the user is trying to give you a fake email address, chances are they don't want to be part of your service/offering anyway. I test for an @ and characters either side, that's most flexible bases covered. I know this doesn't apply to all scenarios but it's one worth considering.

nathan_long 14y ago
You probably want to ensure that there's a dot somewhere to the right of the @, also, but yes, that sounds sane to me. "something@something.something" Start of line, at least one non-@, @, at least one character, dot, at least one character, end of line. ^[^@]+@.+\..+$ Test: http://rubular.com/r/G69q1k6fP2 http://rubular.com/r/G69q1k6fP2 If it fits that, try emailing them.
- perokreco 14y ago
  There doesn't need to be a dot on the right side.
  - deleted 14y ago
    [deleted]
  - xyzzy123 14y ago
    I found your comment fairly cryptic. I had a fun twenty minutes trying to work out what you meant, and under what circumstances dotless RHS in email addresses might be legal. I suppose from the RFC, sure the spec doesn't require dots. For example, I can use http://mythic-beasts.com/~pdw/cgi-bin/emailvalidate http://mythic-beasts.com/~pdw/cgi-bin/emailvalidate and verify that sure, '1@2!3!4' is a valid RFC822 email address. But I think e.g. UUCP-style addreses are a pathological case, and we don't _really_ want users signing up with them. Another option would be intranets, e.g. 'baker@internal', but again I think that's being a bit pedantic, since most people on HN are writing webapps for the public Internet, not mail clients. So can we get an email with foo@<some-dotless-string> routed across the public Internet? Even a bounce would do :) You might be able to do a riff on xyzzy123@[23.55.211.36] (e.g xyzzy123@[389534500] or xyzzy123@[1737D324]. However, do you _really_ want your users to specify these? There are mx records for existing TLDs (e.g. com, org, au, mx) - but all the mx records I tried refused connections on port 25. So no mail for 'xyzzy123@com' :( So gTLDs are another option, and there was a time when it looked like xyzzy123@xyzzycorp might route (as long as it didn't collide with anything on the local resolver's search list). But it seems that dotless use of gTLDs is seriously deprecated at this point, and that ICANN will treat it as a TOS violation: http://domainincite.com/10254-why-domain-names-need-punctuation http://domainincite.com/10254-why-domain-names-need-punctuat... Basically, ICANN's conclusion was that dotless TLDs are a terrible idea for many technical reasons. I looked into IDNs too, but of course due to the way DNS works, you can't really get around the dots. So the conclusion of all this is that: 1) Using an RFC822 regex is a terrible way to check emails. The things it thinks are valid are MUCH wider than what you actually want. 2) You should probably check the RHS against a public suffix list if you are e.g. accepting a user email address on a signup page. If you accept dotless TLDs or other constructions (e.g. ips on RHS) there is some (low, but nonzero) risk that a malicious user could cause your systems to route mail to your other systems internally.

chris_wot 14y ago

The only thing I've ever seen that is worse than this is the sendmail configuration file.

xentronium 14y ago

Please note that RFC822 also covers some unusual forms of writing an address; all of the following are correct addresses: * John Doe <john.doe@example.com> * foo:a@b.example,c@d.example,e@f.example; * john.doe@example.com (John Doe) See also the excellent explanation by Jukka Korpela for more details: http://www.cs.tut.fi/~jkorpela/rfc/822addr.html http://www.cs.tut.fi/~jkorpela/rfc/822addr.html

deweerdt 14y ago
Yes, absolutely. When people want to validate an email address, it's more likely they're referring to the SMTP envelope address: http://tools.ietf.org/html/rfc5321#section-4.1.2 http://tools.ietf.org/html/rfc5321#section-4.1.2 RFC 822 (RFC 5322 in its more recent incarnation) refers to the From: header in the email, RFC 5321 refers to the address used in the 'MAIL FROM:' (and RCPT) SMTP command.
dfox 14y ago
and if i remember correctly, this regexp should also accept foovax!example.com!john.doe, which is certainly something you do not want to accept

Smrchy 14y ago

For JS validation on the client i use this: http://blog.tcs.de/javascript-near-perfect-email-validation--check-routine-as-string-prototype/ http://blog.tcs.de/javascript-near-perfect-email-validation-... A lot shorter and has only 3 cases that would not be detected. Enough for 99.x% of all entered emails.

jrajav 14y ago

I can't find an online tester that doesn't choke on this, but if you're curious to try it out, here's the token Perl one-liner: echo "x@y.com" | perl -lne 'print "$_ is valid!" if /(?:(?:\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])*)?(?:[^()<>@,;:\\".\[\] \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])*)?(?:[^()<>@,;:\\".\[\] \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*(?:(?:[^()<>@,;:\\".\[\] \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*)/'

JimWestergren 14y ago

With PHP the following simple code works great for me: function validate_email($email) { if(filter_var($email, FILTER_VALIDATE_EMAIL) === FALSE) { return false; } else { return true; } }

adv0r 14y ago

This validation ignore one exception : Gmail allows users to enter an arbitrary number of dots . Therefore these are a valid email addresses : your......name@gmail.com y.o.u.r...name....@gmail.com and all resolve to yourname@gmail.com http://support.google.com/mail/bin/answer.py?hl=en&ctx=mail&answer=10313 http://support.google.com/mail/bin/answer.py?hl=en&ctx=m...

Lockyy 14y ago
And this is a problem I constantly run into with web services, some throw an error if I use a ., others throw an error if I try to do something like example+note@example.com. I use one or the other to help sort emails. It's even worse when a sign up form accepts an email in the latter format, but the login form does not for some reason. So I have an account with a note added but I cannot login. I had this problem with the Odeon website for a while, eventually had to phone them up and ask them to change my accounts email address to one without a note.

roel_v 14y ago

This is from "Mastering Regular Expressions", by Jeffrey Friedl, O'Reilly 1997. The book presents it as a 'fun' example of how to write huge regex'es that are still understandable and maintainable (the version posted here is without all the comments that are in the book).

habosa 14y ago

I find it pretty entertaining that this RegEx is so big that visual patterns emerged. In my browser there are clear diagonal lines of "@" symbols across the RegEx. If it looks like ASCII art, your RegEx is probably too big.

3ds 14y ago

As per html5 spec the recommended regex is: /^[a-zA-Z0-9.!#$%&'+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)$/ http://www.w3.org/TR/html5/states-of-the-type-attribute.html#valid-e-mail-address http://www.w3.org/TR/html5/states-of-the-type-attribute.html...

stratoukos 14y ago
This will not match addresses with non latin characters.
- mitchty 14y ago
  Yep, shouldn't the right answer be: accept whatever the user gave you, validate it with a link in the email you send that they've received it. Should be even more important if you ever intend to do business with say someone from China. Good luck dealing with validating hanji in an email.
- tedunangst 14y ago
  Addresses do not have non Latin characters.
  - Aissen 14y ago
    Which is false: http://tools.ietf.org/html/rfc6530 http://tools.ietf.org/html/rfc6530 http://tools.ietf.org/html/rfc6531 http://tools.ietf.org/html/rfc6531 http://tools.ietf.org/html/rfc6532 http://tools.ietf.org/html/rfc6532 http://tools.ietf.org/html/rfc6533 http://tools.ietf.org/html/rfc6533
    - tedunangst 14y ago
      Relying on standards that new for something like email would be a mistake IMO. Ymmv.
ambiguity 14y ago
You are missing a * just before the $.

crusso 14y ago

I've been watching people deal with this problem for years and years... why? I can parse a CSV file far more easily. You'd think there would be an RFC that specifies a simple email address format that everyone can follow. If you don't conform to that format, your email gets dropped on the floor until you get a better client.

DanBC 14y ago
This is one of the things that people really want for email2. Unfortunately email works well enough, and has such a massive install base, that email2 is never going to happen. That's why you see so many "Email but not email" startups.

topbanana 14y ago

The point of regex is to be human readable. This might as well be a binary blob

bryanlarsen 14y ago

This is a generated regexp, it's not hand crafted. Making fun of it is like pasting up machine code compiled from C and saying "machine code sucks".

gvalkov 14y ago

I'm surprised there isn't a Perl6 version of Mail::RFC822. This is exactly the kind of thing that Perl6 rules[1] are supposed to excel at. It would be good publicity, especially now that rakudo has usable releases. [1]: http://en.wikipedia.org/wiki/Perl_6_rules http://en.wikipedia.org/wiki/Perl_6_rules

turshija 14y ago

'@'.' is a valid email address. seriously ? :)

1nvader 14y ago

This regex deserves a downvote! If you don't undertand it (and i guess you don't if it's not written by hand) - don't never ever use it! The only way to validate a email adress is to send a validation mail/link.

smackfu 14y ago

Validation of emails is pretty pointless since most errors will be typos that pass the regex anyway. You're better off trying to give warning messages based on common typos.

CalvinCopyright 14y ago

Makes me think of the first reply to this StackOverflow question: http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags http://stackoverflow.com/questions/1732348/regex-match-open-...

michaelhoffman 14y ago
But, unlike XHTML, it is possible to validate an e-mail address with a regular expression (assuming comments have been removed).
- _delirium 14y ago
  It's also, unlike XHTML, not particularly easy to do it with a parser: most of the complexity of the regex is due to the litany of edge cases for what constitutes a valid email address, not due to it being a regex.

mosselman 14y ago

E-mail validation can be useful, but I would stay away from this thing. Look at what you are trying to do from a higher level. Most likely the user wants something from you as well as you from them. If a user gives you a bad e-mail, despite a very basic e-mail regex, whatever, they won't get an e-mail, not my problem. If it is to register on your website, just let them, send them a confirmation e-mail to their 'email', meanwhile allowing them to use the system (or not). Then if after x-time they haven't confirmed, just delete the user again. This will save you a lot of trouble. If you want something more high-tech like checking a huge list of e-mails in a system you could go with a solution suggested below, just send them an e-mail. Regex is evil!

saurik 14y ago

This concept been covered on Hacker News so many times before. :( During a similar conversation 70 days ago, I left a detailed comment that is also relevant now regarding how RFC822 is actually totally irrelevant for the concept of e-mail addresses: what it specifies is how to escape the field values in MIME headers, and thereby has a bunch of rules for how to format an e-mail address that are really "how to embed an e-mail address in a MIME document". RFC821, the SMTP specification for how you actually send e-mail, is closer, but has different rules about what is allowed because SMTP isn't MIME. A couple things aren't allowed, and some other things now are allowed and don't need to be escaped. Why people think users should type e-mail addresses in RFC822 escaping and not RFC821 escaping makes no sense to me. However, the real punchline is: why are you asking users to enter e-mail addresses escaped at all? If you have an HTML form, for example, you don't need to escape them, as there is no higher-level protocol in which they are being embedded: the box can contain any characters that are needed, and there are no concepts like MIME comments, etc.. Asking a user to escape their e-mail address in that box is as silly as asking them to escape their username or password according to HTML or URL or some other escaping rules. Or, imagine if they had to enter their full name, but escaped using MIME encoded words... =?iso-8859-1?Q?=A1Hola,_se=F1or!?= makes about as much sense as escaping your e-mail address. My original comment, which contains many more details about which specific RFCs are involved and what they mean, along with specific examples where things can get different, and a discussion of the context, here: http://news.ycombinator.com/item?id=4486872 http://news.ycombinator.com/item?id=4486872

andrewvc 14y ago
So, your reply 70 days ago was in reply to me regarding the ruby library Evan and I wrote. Funny enough, this perl regex was one of the inspirations for the ruby library Evan and I wrote (though that uses a PEG for parsing) Weird how things go around...

dutchbrit 14y ago

There's a very nice function in PHP that validates emails. filter_var('foo@bar.com', FILTER_VALIDATE_EMAIL); The actual beast: https://github.com/php/php-src/blob/master/ext/filter/logical_filters.c#L499 https://github.com/php/php-src/blob/master/ext/filter/logica...

dfox 14y ago

email address validation should not be motivated by what is valid address by some RFC, but what you feel confortable passing to your MTA, because you have exact understanding of what will happen. On the application side you probably don't want to store adresses with comment and real name fields and other such only human readble data. My rules are: contains exactly one @, contains zero or more +, does not contain any other characters that are special cased by this (notably ',', ';' and '!').