5 ms·
Email Validation Rules
- huhtenberg 13y agoThat was "Email validation for pedants". Practically speaking, the following regex - /^[_\.0-9a-z-\+#]+@([0-9a-z][0-9a-z-]*\.)+[a-z]{2,6}$/i coupled with a DNS check for domain name is yet to generate a single false negative in years that we've been using it across multiple projects. (edit) Do read through the thread below before getting all downvote happy.
- nwh 13y agoSorry, just broke your regex. hello@visit.melbourne. Yes, that's a valid TLD now.
- huhtenberg 13y agoNo, it's not - http://en.wikipedia.org/wiki/List_of_Internet_top-level_domains http://en.wikipedia.org/wiki/List_of_Internet_top-level_doma... If you are referring to {2,6}, then it's easy to adjust once longer domains are put to actual use. If you are referring to the trailing dot, then that's exactly what I was saying - practically, email formats that are used by real people is a much simpler subset of what's permitted by the spec.
- nwh 13y agoYes, it is, or at least close enough that you should be considering it. http://newgtlds.icann.org/sites/default/files/ier/hu62oef5uc0u8riu78usp26r/ie-1-1918-10194-en.pdf http://newgtlds.icann.org/sites/default/files/ier/hu62oef5uc... gTLD can also contain punnycode/unicode now, which additionally breaks your regex in another way.
- huhtenberg 13y ago"Close enough" doesn't count :)
- nwh 13y agoIt does for all the irritated people that can't use their new domains on the tens of thousands of systems with rigid regex like this. Even if it's not breaking anything today, it's certain it will in the future.
- huhtenberg 13y agoIt "doesn't count" for melborne TLD that currently sits in the "Initial Preapproval" state. -- But more generally, you just don't want to hear what I'm saying. Right now, people do NOT use email addresses with internationalized domains, they do NOT put trailing periods in domain names, etc. Once they start doing that, the regex can be adjusted to accommodate for that on first false rejection. As it exists now, the regex is tailored exactly to how emails are used now, by real humans. A negative is an indication of a bot activity or some other oddity that needs attention. Feel free to support that transparently, but the question is why would you want to do that.
- vidarh 13y ago> for that on first false rejection. This assumes that you manually verify every rejection, or that they contact you. In other words: Either you're not using this anywhere with volume that matters, or you don't know that it hasn't caught false negatives. > A negative is an indication of a bot activity or some other oddity that needs attention High volume of negatives is an indication of bot activity or some other oddity. A single or handful of negatives is just humans going about their business as horrible typists. If your volume is small enough that you can treat every negative as something to investigate, you really have no basis for saying anything about how well your regex works.
- huhtenberg 13y agoIt's not the Gmail-level volume, but it's an email per day either. And yet there is still very few negatives, so it is possible to go through them by hand. Vast majority falls into "fafafa" and "test@test" category. The remainder is typos, e.g. commas instead of periods.
- temac 13y agoWhy do you want so much to limit to 6, especially since you also do a DNS validation? You should better lean on the permissive side; that would be one less thing to think about. That kind of "validation" does not check for existing email addresses anyway, so there is not much value in trying to be strict in this area.
- huhtenberg 13y agoYeah, I agree in principle, but it's at 6 simply because it works fine as is. Given new developments it might make sense to bump it up and/or add support for punycode, and we'll do it once it's actually needed.
- kijeda 13y agoWhat is the threshold where supporting a domain becomes important? It seems awfully arbitrary to say it "works fine as is" when it is disenfranchising millions of registered domains as it stands.
- nly 13y agoForget new gTLDs, the current ones are tricky enough: http://publicsuffix.org/ http://publicsuffix.org/
- rincewind 13y agohow do you test for false negatives?
- huhtenberg 13y agoBy manually going through the log of rejected email addresses.
- kijeda 13y agoAmongst other problems, that limits TLDs to 6 characters, which is about 16 characters shy of the longest TLD right now in the DNS root zone: https://data.iana.org/TLD/tlds-alpha-by-domain.txt https://data.iana.org/TLD/tlds-alpha-by-domain.txt Add to that the fact it would fail on a legitimate top-level domain like .рф or .中国.
- k33l0r 13y agoI found this talk by Ricardo Signes on email parsing to be an excellent primer into why email addresses (and emails in general) are terrible to parse: http://youtu.be/JENdgiAPD6c http://youtu.be/JENdgiAPD6c
- nly 13y agoInformative and entertaining, thanks.
- old-gregg 13y agoYep. I'd like to add that some ESPs have their own additional restrictions on mailbox names, plus it's usually helpful to verify the existence of the domain part (DNS) because people make mistakes all the time. We (Mailgun) have a free service which does all of these things: http://blog.mailgun.com/post/free-email-validation-api-for-web-forms/ http://blog.mailgun.com/post/free-email-validation-api-for-w...
- Sami_Lehtinen 13y agoIt's also trival to contact recipient STMP server and check if it accepts rcpt to.
- deleted 13y ago[deleted]
- adv0r 13y agoTest your method with this (valid) address ......n..............am.eeeee......@gmail.com
- adv0r 13y agoTest your method with this (valid) address ......n..............am.eeeee......@gmail.com
- bkanber 13y agoI feel like people really overthink email validation. I just look for an "@" and a ".". If you really need proof that an email address is valid, send an activation email. Otherwise, who cares if a few emails in your database are invalid? Additionally, lots of 3rd party mail systems have some mechanism to notify you of bounced emails, so you'll figure out which are invalid at your first attempt anyway.
- louischatriot 13y agoDefinitely, spending time validating email is useless. Look for an @ to make sure the user didn't mistake the email field for the name field and send him a confirmation email if you really want to be sure.
- davefp 13y agoI'd even drop the '.' requirement. Look for an @, then send a confirmation email. Done.
- Sephr 13y agoRequiring a dot breaks your form for people using bare TLD email or people using an IPv6 address instead of a domain.
- cytzol 13y agoThere's a sufficient mass of people with dots in their e-mail addresses that it's worth checking for an at and a dot, even if you don't require it - just to check that they haven't typed a comma or something instead.
- deleted 13y ago[deleted]
- Sami_Lehtinen 13y agoThere's no mention of minumum email length length, but I have noticed that some services do not accept email addresses like m(@)dy.fi or m(@)x.com etc. They claim that address is too short. Strip parenthesis from addresses.
- elchief 13y agoMinimum should be 6: a@x.ca Max is 254: http://stackoverflow.com/questions/386294/what-is-the-maximum-length-of-a-valid-email-address http://stackoverflow.com/questions/386294/what-is-the-maximu...
- thrownaway2424 13y agoThe practical way to validate an email address is: 1: Does the domain part have either an MX or A record? 2: Does the address in that record accept mail? 3: Does the server that accepts mail at that address respond favorably to the local part as a RCPT TO argument? If yes, it's a valid email address. In particular this article is wrong that emails are always 7-bit. With SMTPUTF8 you can put whatever you want in there.
- lucidrains 13y agodoes it really matter? there are sites that store your password in plain text and they manage to become big hits. there are sites that completely ignore current css design rules, and they do fine as well. why are you arguing over a problem that is basically 99% solved?
- cbsmith 13y agoIt's funny that that is the easiest thing the author can do to summarize the rules. I'd think a grammar (http://www.ietf.org/rfc/rfc2822.txt http://www.ietf.org/rfc/rfc2822.txt) would work just great.
- ruricolist 13y agoThe HTML5 standard prescribes a regex for implementers to validate email addresses on the client side: /^[a-zA-Z0-9.!#$%&’*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$/ So if you're going to use <input type=email>, you might as well use the same check on the server side.