Glad I'm not the only one just checking for an '@'. I wouldn't want to prevent users from registering with my sites just because I didn't foresee some funky email address formatting with my regular expression.
... And remember, the password can only be 8-16 characters [A-Za-z0-9] because we wouldn't want to do accidentally cut yourself on some other 'weird' character like a space or underscore or something. ;-)
How many emails to asdasdasd@example.com or sdfsdf@gmail.com are you willing to pay for (the nickels add up)? What if someone uses my email address to sign up for your service?
The driving force is that you want to correct an invalid email ASAP, preferably in the client with live feedback coloring, etc.. Most email services I know don't give you any immediate feedback, and some only give you a basic check that can bounce later. So claiming you just have to check for an @ sign and try sending means there is going to be a huge delay before you know about the error.
Saying the user will just come back and register again is not good. That's like saying if your page is very slow to load, users will just wait for it to load. They don't. They leave and never come back most of the time.
If you can't afford to write the code to help the users fill out the form in a way that will work, fine, that's something you didn't have time for considering the percentage of users it will help/retain. But don't claim it is useless.
Not useless, but validation of the presence of a valid email does not validate the accuracy of the email. It may be valid and still wrong. Therefore the return on investment, and the possible exclusions of valid email doesn't justify the time in most cases. So not useless, but certainly a poor investment of time.
Incase I've typed it wrong, that should basically work for anything that contains at least one @ and one dot, in that order, as well as at least one character at beginning, middle and end. It's served me well thusfar.
Edit for clarification:
The reason I prefer this over just checking for an @ is that if you're just checking for @ a common mistake like "me@hotmail,com" will be considered valid.
A square bracket, however, is not a dot (which is for what the original regexp checked).
And I just tried sending an email to me@[my.ip.addr.[0]]. Postfix somehow recognised it was for this local host, but failed because it wasn’t part of the virtual domains I had put into it. ‘perverse’ seems to be somewhat appropriate.
[0] Sorry, too lazy to check the appropriate documentation IP address ranges. 20db?
As far as I know the new tlds will still have a dot between tld and actual domain (I could be wrong though) but it's just been pointed out that IPv6 emails addresses could fail on my regex.
The reason I don't currently use x@y is just to have a better shot at catching typos without being too restrictive.
To use just the TLD, the domain will need to be fully qualified with a trailing dot, "x@tld.". Otherwise, the domain can get confused with just the hostname in the local domain (tld.example.com). Just the hostname is a valid email address but wouldn't need to be accepted by most signup forms.
My guess is that nobody will use just the TLD because of the confusion. And because a lot of software does not support fully qualified names.
It should be similar to your version, but only matches just enough parts that require for email validation (i.e. "o@example.c" part of foo@example.com).
I like that, much more elegant! My only changes would be to make the middle .* into .+? as that way it requires at least one char, and the ? is for lazy repetition.
Just a top level domain after the @ is a valid email (e.g. foo@com). Things like this are why we end up with massive regular expressions for email validation. That said, if you are only warning the user, but not preventing them from submitting foo@com, then it is probably good enough.
Don't bother even reading it. His solution is to "Just send your users an email. The activation email is a practice that’s been in use for years, but it’s often paired with complex validations that the email is formatted correctly. If you’re going to send an activation email to users, why bother using a gigantic regular expression?"
Want to know why it's not more common than the regex "method"? His method has its own host of problems - what if your mail server is down for six hours - will people come back to your site six hours later when they get the email? What flags will get set on your sender account when Gmail gets 100,000 bogus email sends? Do you force your users to "Look in your inbox and click the activation link" for every email address change also? There are others but I've made my point. There's a finite amount of "stuff like this" that users will put up with - you can either put the onus to "get it right" on the user (regex validation for emails), or you can put that onus on your system.
An argument for another is always, "If a user can't get their email address entered correctly, I don't want them as a customer". And you can take that multiple ways - technical difficult entering emails, "challenging" email addresses, etc.
People are farfar more likely to get their email address wrong by misspelling their own name or putting @hotmail.com when they meant to put @gmail.com; regex will not protect you from either of these things.
We actually had an email list of ~50k people that had been validated within nothing other than "check there are at least 3 characters in the string" and when we looked at which addresses were bouncing when we sent to them there were approximately zero that failed because they had ommited the @ or because they were using some weird invalid unicode.
Even the spam bots were submitting valid email addresses.
Spam bots, if there was no check in place to slow them down, would dwarf real people registrations in all systems always. So let's not confuse these two topics - they are different. One part of a system that allows users to register needs to ensure that you have an identifier for a customer and a way to contact that customer, and other techniques try to ensure that you aren't allowing the spammers in the door. Whether you use regex or sending an activation email - neither of those can tell you whether this email address is or is not a spammer.
That's true, but I would posit that you need a registration email anyway (assuming you even care if the email is valid) because even if your regex is perfect there's no way to detect people simply mistyping their email address in a way that is technically valid.
This has been an issue since the day I started programming for the web, back somewhere in '95.
It has regularly come up on HN, and pretty much any programming related forum I've used since the mid-90's.
As an industry at the heart of the information society you have to wonder what the hell we are doing wrong if we cannot stop this constant regression into well known bad practices.
Plus a Large Regex for mail validation is not supposed to be heavily used. It's supposed to be used once at registration for example. So why would it matter if it's slow/heavy/...
I really don't think so since you're soliciting an email server while a regex is just some code that has to be run, and they are run on a tiny string (a mail is never really long).
Also it's bothering for the user, if you need mail confirmation then do it, but otherwise it should be a RULE OF THUMB to always avoid annoying user. Thus avoid mail confirmation.
This article is actually a really bad advice. I don't know why it's upvoted so much.
I'm not completely sure that I get annoyed when a web site sends me a confirmation email. It helps me know that the site indeed knows my correct email.
> What is so special about parsing email addresses that makes everyone invent their own solution - regex or otherwise?
A valid email address can contain almost anything; this makes validation via a standard parser mostly useless. As such, devlopers reach for stricter parsers out of a combination of a not comprehending the standards, feeling vague discomfort about letting 'just anything' past data validation, and misplaced concern for users that they believe can't type their own e-mail address.
Add to that the occasional business complaint from the marketing arm about bogus e-mail addresses, and you have people repeatedly solving the problem in slightly different ways, justifying their own divergences from the standard by applying the justification that nobody will use a 'weird' address anyway, and they're actually being helpful.
1) Because the solutions actually prevent some users from typing their actual e-mail address.
2) There are so many ways to get the e-mail address wrong that it's almost not worth bothering validating the few things that you can validate.
Now, here's what would be an interesting validation method that doesn't actually require sending an e-mail. It requires an RFC-compliant e-mail parser, not a regexp:
- Perform A/MX lookups on the domain part. The domain part can be an IP address, so those get a free pass.
- Connect to the returned MX, issue a MAIL FROM+RCPT TO:
c> MAIL FROM: test@example.org
s> 250 2.1.0 Ok
c> RCPT TO: is_address_valid@example.com
s> 554 5.7.1 <is_address_valid@example.com>: Relay access denied
c> RSET [reset the transaction, no e-mail is sent]
- If you get back a permanent 5xx error, the address is invalid. If you get back a 250 Ok, the address is probably valid (it could still be a relay that allows backscatter, in which case it will allow any address on one of its configured domains). If you receive a 4xx, the address may or may not be valid -- graylisters will send 4xx, as will servers that can't currently accept e-mail, etc.
This gives you definitive failure (5xx) and almost-definitive success (250 Ok). It's a cheap DNS lookup + TCP connection that you can begin performing immediately and asynchronously when a user enters their address in a form.
So in addition, 'spell check' for likely domains. People probably don't mean to type 'gmale.com' -- but don't prevent them from doing so, if that's what they really meant.
> Hopefully that's not the SMTP syntax you're actually using.
I typed it out live. I'm not an SMTP client and I don't have the RFCs memorized.
> I'd reject (give you a 5xx) that from my mail server for those reasons alone.
Postfix accepts it. I haven't checked the RFC to verify your concerns, but assuming they're correct, then my expectation is that postfix is liberal in what it accepts because A) it's a good idea, and B) a real mail transfer agent probably ignored those two minimal rules at some point in the past.
Postfix (and the other big receivers) will ignore it, but will send using the proper RFCs. It's still a good sign of a badly written bulk mail engine, and worth rejecting for.
My MTA doesn't "throw away" email. It sends back a 5xx with an appropriate message that the sending end isn't RFC compliant. Absolutely nothing wrong with that - if it's a legit sender they know I didn't get the mail.
At which point the legit sender does what -- replace their MtA? More likely they just contact thir receipient out-of-band (eg; gmail) and avoid your over-zealous mta.
Whether you think you're 'Throwing away' is just semantics. From a user's perspective that's exactly what you're doing.
It's my MTA, I'm the "user". My server, my rules. Just like if you want to come into my house you come in the front door and take your shoes off, not crash through the window in muddy boots.
I think it's mostly just bikeshedding. This is a problem that is both largely unimportant but also common enough that many have encountered it (and thus have an opinion).
That seems terrible when combined to a username which needs to be unique. User registers with username, email and whatever else. Email is incorrect, they never receive the activation email and cannot register a new account using their preferred username.
Of course there's plenty of ways around that, but this seems to be the most common pattern.
Assuming that running the regex is much faster than sending an email, it would probably be much less server load to check the regex and never send X% of emails, unless X is extremely small.
(Looking up and implementing a regex) * 1 + (running the regex) * (every email) + (sending email) * (every valid email) < (sending email * every email)
Also, this post only considers the signup/activation use case. If you're getting an email for ecommerce to send an order confirmation, you want to know if the email might be invalid before the user completes the order and you try to send it.
You still need to confirm the validity of the email request by sending an confirmation email, so you might as well just check for '@' and let your confirmation system handle the rest.
This assumes that you get the regex 100% right and never lose a user by rejecting a valid email address. This is much harder than it seems ( http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html ), and is no guarantee an valid email address that is in use, as the article makes clear.
After some very basic checks, e.g. "contains at at least 3 chars, one of which is an @", you should Just. Send. The. Email.
Who bothers to type in a complex but invalid email address? The overwhelmingly common failure modes are:
1) Nothing entered at all. The basic check catches this.
2) Deliberate invalid email address. e.g. homer.j.simpson@springfieldnuclear.com - a regex will not catch this.
3) Typo in email address. e.g. john.smith@gmial.com - a regex will not catch this either.
The regex has downsides and complexity, but essentially no benefit.
Please don't quote that RFC-822 regexp when arguing this. That's for the contents of mail headers (which can include comments and so on), not an actual valid email address.
A regexp for validating RFC-2821 email addresses is actually fairly simple.
Whichever RFC it is, it is not so simple that everyone gets it right. For innstance, a significant percentage of websites don't let you register email addresses containing a plus sign in the name, e.g. john.smith+foo_bar@host.com
I agree with the author of this blog, but he doesn't address the problem where you want to scrap all the email addresses in a text file. For this situation, I don't see what to use except regexp.
Yeah, but it you want to get all the emails in a text like "Please contact me at myfakemail@gmail.com. I already sent an email to contact@mycompany.com, but no one replied...", then you would have to use regexp.
Some people use many email addresses and so could create many accounts. With one email address they can still use the '+blahblah' method to sign up unlimited times, unless you prevent that which would annoy people who use it legitimately for filtering.
Some people have a garbage or throwaway email account that they sign up for everything with, and only ever look at to find the confirmation emails.
If people don't want to give you a valid email then there's no reason to be sending them anything.
The question is why people are validating the email in the first place.
* to ensure it is deliverable? Well, then you better send them an email.
* to let people know when they misread the labels and put something that was clearly not an email in the email field? A simple check for an at-sign is usually sufficient.
* because some tester opens a ticket saying you can enter an invalid email in the email field? Yeah, that's where most of the complicated regexps come from.
* Because users often miss a character like a dot or an @, and catching that early saves a lot of pain with undelivered confirmation e-mails and so on.
I actually think that this library functions as a really great client-side validation that won't get you tripped up in trying to be RFC compliant. There's really not anything more that I'd do aside from sending that blessed confirmation email.
Because it takes system resources to deliver email. Furthermore, if people make a simple typo, why go to the extent of attempting to send something to it when it's obvious?
Because it's not obvious. Ask developers to recite the rules for correct email address, and most of them will get it laughably wrong. I blame the standard, which is far more "featureful" than is actually required, but that is the way it is.
Actually, I was just thinking the core error was something else; conflating routing with identity. bob@subgenius.com is a routing instruction, 'J. R. "Bob" Dobbs' is a human identity, and '"J. R. 'Bob' Dobbs" <bob@subgenius.com>' is just a mess.
So don't attempt to register an email with comments in it, or for that matter with an ip host.
We need a much more restrictive standard for emails, but until we have that we have to accept that each site will have a competing not-completely-overlapping set of standards. So make sure your email doesn't attempt to do anything too funny.
I feel about this much the same way I feel about the endless proliferation of Markdown variants; if we could all agree on one simplification, sure, but the current situation where we haven't really stinks. For instance, ask early Gmail users about putting + in the email.
So while I agree with you in principle, in practice it seems infeasible. The differences bite in practice, unfortunately.
I'd say nothing of value is lost in that case. These people are very costly to support. Email has been in common use for at least 20 years. They need to step up to the plate and learn at this point.
There are times when it is good business to stand on principle, and then there are times to just help your customers a little bit. Email signups are definitely the latter IMO.
might I remind you one of the reasons why Apple have posted record profits over the last decade? It's worth nailing the UX experience to be as inclusive as possible.
It's also worth considering that one of the biggest generational markets (baby boomers) include a lot of those people you're telling us to ignore.
Refusing to send email to someone because your software mistakenly rejects their email address is not exactly being as inclusive as possible, though, is it?
I agree. In addition to being pretty damn old at this point the pronunciation of "@" should resolve the "aol.com@joe/joe@aol.com" issue for all but the most clueless (all but the most likely to cost you in support). That case is particularly egregious.
to ensure it is deliverable? Well, then you better send them an email.
I deal with user support for a site and I'd estimate at least 2% of our new users (>50 people PER DAY) enter wrong email addresses. Not "I forgot to put .com at the end" but "I thought my email was john.doe@gmail.com when it's actually john.doe@yahoo.com" which would pass validation with flying colours. The only real "solution" is to tell a user if the validation email has been sent yet (to deal with "well maybe I should wait 5 more minutes") and if it has and they don't have it allow them to change their email to their real email address. So many sites (incl. the one I manage) do not allow this, it's crazy.
>if it has and they don't have it allow them to change their email to their real email address
Couldn't an unscrupulous individual use that feature to take over non-activated accounts? An immediate use for that exploit doesn't spring to mind but this makes my spidey sense tingle. What sites allow this?
From my experience a user will almost always remember the password they've just entered, even if they got the email wrong. They should be able to login to a not-yet activated account and be presented with the option to correct the email for the activation email to be sent to. There's no potential for abuse there.
Only ticket I've ever seen about email validation was that a webapp was refusing to accept a customer's valid (and already registered/paying money in another system) address.
That's roughly 40 chars ?
People coming from some regions easily have 20 to 30 chars for the family name alone [1]. That's more or less the length of our test string if the add the given name(s).
If the issue only appeared on all W's I'd guess you could set the bug as minor and discuss if it's worth fixing. If it costs an incredible amount of time to fix it, the problem relies more on defining priorities than on having too much granularity on the testing side.
To go back on your parent post, I'd say validating funky emails is of the same level. The test team should bring up the edge cases, fixing them or not is a matter of priorities.
So what's wrong if you do a full validation (http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html) ? You as developer or site owner or user don't need to do it by hand or in your head. It is done in a fraction of a second by the computer even if benefits are not the greatest like validating the strength of a password but still. Complaining about it because you don't like it and telling other people not to do it because of your reasons and spending time writing a blog post about it is overkill - like validating the email address with a regexp :)
There's nothing wrong with doing full validation. Just don't use that regexp - it's for RFC822 email addresses, which is how you might see them in an email header, including things like comments.
You want an RFC821 (or more specifically RFC5321 now) email address regexp. See my post here about the email validator I wrote: https://www.emailitin.com/email_validator
Yeah, and then you wind up sending mail to "joe@hotmailcom" or "liz@gmailc.om", and your users don't get your messages and are sad. Don't validate the local part, do validate the domain.
Why not have a simple validator that works with 99% of users emails but not make it mandatory that it passes validation?
"We see that bob@localhost doesn't look like a email address are you sure it's right?"
That way you can help users that messed up their email but not prevent all the corner cases. The idea is that most email addresses fall in a very narrow subset of the RFC: user@domain.tld and most people would have entered their email wrong if it didn't match that pattern.
If you really want to do checking of email addresses right on the signup page, include a confirmation field so they have to type it twice.
No. This puts the burden of checking email validity on every user, even perfectly capable valid users. If you're validating for edge cases (mistakes or otherwise invalid addresses), treat it as an edge case and don't annoy users who can type.
> This puts the burden of checking email validity on every user, even perfectly capable valid users.
? Whenever I hit a form which wants me to retype my address, I just triple-click to select the entire address, then middle-click to paste it into the confirmation field.
IF I were to validate by regex, I would put a confirmation for emails that I couldn't validate that read "We are very sorry but your email doesn't appear to be valid, however validating emails is very difficult so it may be our mistake. Can you confirm your email is correct?" And if they don't modify it, accept it as valid. It is an extra step but seems more friendly.
Amen! Anyone else here use myemail+token@gmail.com when they have to register with their email to find out who is selling them out and to make spam filters easier?
It still amazes me that 70% of the places I attempt using foo+bar@gmail.com call it invalid. And that does not even begin to touch the myriad valid permutations that are "invalid" out there.
I use 33mail.com for the same purpose - it gives you a unique wildcard subdomain (and also a shortened domain (<yoursub>.33m.co) so you can create uinque addresses per signup etc, without the problems of + being rejected (or gicing away your real email address)
You can then block any address with a click if it's being abused.
If you're feeling generous, enough people using this link will earn me premium features: http://www.33mail.com/rj37w3
And likewise, it amazes me that people think that for all their efforts at combating filters, captchas and the like, that the most nefarious of spammers aren't stripping off "+token"s from email addresses.
Spammers tend to be stupid. When I post my email address as "me+tag@mydomain.com" on a certain popular, well-scraped website, I see lots of rejected traffic to "tag@mydomain.com".
I used to use mail@mikeash.com as my primary e-mail address. Enough sites rejected that (due to thinking that "mail" was bogus somehow) that I eventually switched to mike@mikeash.com.
210 comments
[ 2.8 ms ] story [ 250 ms ] threadEdit: Oh wait, on your own sites :-) I'm just slightly annoyed that I have to add a fqdn when doing local development with some apps...
However, they can, if implemented correctly, tell you if the email address is syntactically valid.
I personally prefer: /[^@]+@[^@]+\.[^@]+/
Basically the same except that it will throw an error if someone enters an extra at sign.
/^[^@]+@[^@]+\.[^@.]+$/
Saying the user will just come back and register again is not good. That's like saying if your page is very slow to load, users will just wait for it to load. They don't. They leave and never come back most of the time.
If you can't afford to write the code to help the users fill out the form in a way that will work, fine, that's something you didn't have time for considering the percentage of users it will help/retain. But don't claim it is useless.
Incase I've typed it wrong, that should basically work for anything that contains at least one @ and one dot, in that order, as well as at least one character at beginning, middle and end. It's served me well thusfar.
Edit for clarification: The reason I prefer this over just checking for an @ is that if you're just checking for @ a common mistake like "me@hotmail,com" will be considered valid.
Somewhat artificial, yes.
I wonder what the security implications of this is.
I wouldn't add IP address support to an email regex because I'd rather turn away such perverse data anyway. Nobody uses IP-based email addresses.
And I just tried sending an email to me@[my.ip.addr.[0]]. Postfix somehow recognised it was for this local host, but failed because it wasn’t part of the virtual domains I had put into it. ‘perverse’ seems to be somewhat appropriate.
[0] Sorry, too lazy to check the appropriate documentation IP address ranges. 20db?
Why not just check for x@x?
^(.+)@(.+)$
max length is 254 according to the RFC I believe, so you can check for that too.
http://stackoverflow.com/questions/386294/what-is-the-maximu...
Turns out the 320 value was actually incorrect, its 256 but the mailbox is wrapped in square brackets, so 256 - 2 = 254.
My guess is that nobody will use just the TLD because of the confusion. And because a lot of software does not support fully qualified names.
It should be similar to your version, but only matches just enough parts that require for email validation (i.e. "o@example.c" part of foo@example.com).
Want to know why it's not more common than the regex "method"? His method has its own host of problems - what if your mail server is down for six hours - will people come back to your site six hours later when they get the email? What flags will get set on your sender account when Gmail gets 100,000 bogus email sends? Do you force your users to "Look in your inbox and click the activation link" for every email address change also? There are others but I've made my point. There's a finite amount of "stuff like this" that users will put up with - you can either put the onus to "get it right" on the user (regex validation for emails), or you can put that onus on your system.
An argument for another is always, "If a user can't get their email address entered correctly, I don't want them as a customer". And you can take that multiple ways - technical difficult entering emails, "challenging" email addresses, etc.
We actually had an email list of ~50k people that had been validated within nothing other than "check there are at least 3 characters in the string" and when we looked at which addresses were bouncing when we sent to them there were approximately zero that failed because they had ommited the @ or because they were using some weird invalid unicode.
Even the spam bots were submitting valid email addresses.
This is going to your dominant type of failure.
Kinda harsh sentiment considering that we all mistype stuff, especially on site that disable auto complete.
It has regularly come up on HN, and pretty much any programming related forum I've used since the mid-90's.
As an industry at the heart of the information society you have to wonder what the hell we are doing wrong if we cannot stop this constant regression into well known bad practices.
What I don't understand with this ever-repeating discussion is why the complexity has to be visible. e.g.
Many functions are complex - we put those in libraries, pushing them under the hood, and move on.What is so special about parsing email addresses that makes everyone invent their own solution - regex or otherwise?
Also it's bothering for the user, if you need mail confirmation then do it, but otherwise it should be a RULE OF THUMB to always avoid annoying user. Thus avoid mail confirmation.
This article is actually a really bad advice. I don't know why it's upvoted so much.
A valid email address can contain almost anything; this makes validation via a standard parser mostly useless. As such, devlopers reach for stricter parsers out of a combination of a not comprehending the standards, feeling vague discomfort about letting 'just anything' past data validation, and misplaced concern for users that they believe can't type their own e-mail address.
Add to that the occasional business complaint from the marketing arm about bogus e-mail addresses, and you have people repeatedly solving the problem in slightly different ways, justifying their own divergences from the standard by applying the justification that nobody will use a 'weird' address anyway, and they're actually being helpful.
How is this misplaced? People screw up even the most basic of computer tasks all the time.
2) There are so many ways to get the e-mail address wrong that it's almost not worth bothering validating the few things that you can validate.
Now, here's what would be an interesting validation method that doesn't actually require sending an e-mail. It requires an RFC-compliant e-mail parser, not a regexp:
- Perform A/MX lookups on the domain part. The domain part can be an IP address, so those get a free pass.
- Connect to the returned MX, issue a MAIL FROM+RCPT TO:
- If you get back a permanent 5xx error, the address is invalid. If you get back a 250 Ok, the address is probably valid (it could still be a relay that allows backscatter, in which case it will allow any address on one of its configured domains). If you receive a 4xx, the address may or may not be valid -- graylisters will send 4xx, as will servers that can't currently accept e-mail, etc.This gives you definitive failure (5xx) and almost-definitive success (250 Ok). It's a cheap DNS lookup + TCP connection that you can begin performing immediately and asynchronously when a user enters their address in a form.
... or just send the user an activation e-mail.
I typed it out live. I'm not an SMTP client and I don't have the RFCs memorized.
> I'd reject (give you a 5xx) that from my mail server for those reasons alone.
Postfix accepts it. I haven't checked the RFC to verify your concerns, but assuming they're correct, then my expectation is that postfix is liberal in what it accepts because A) it's a good idea, and B) a real mail transfer agent probably ignored those two minimal rules at some point in the past.
No, it might be worth scoring the e-mail with a spam filter, but the MTA shouldn't be overzealously throwing away e-mail.
Whether you think you're 'Throwing away' is just semantics. From a user's perspective that's exactly what you're doing.
Of course there's plenty of ways around that, but this seems to be the most common pattern.
(Looking up and implementing a regex) * 1 + (running the regex) * (every email) + (sending email) * (every valid email) < (sending email * every email)
Also, this post only considers the signup/activation use case. If you're getting an email for ecommerce to send an order confirmation, you want to know if the email might be invalid before the user completes the order and you try to send it.
After some very basic checks, e.g. "contains at at least 3 chars, one of which is an @", you should Just. Send. The. Email.
Who bothers to type in a complex but invalid email address? The overwhelmingly common failure modes are:
1) Nothing entered at all. The basic check catches this.
2) Deliberate invalid email address. e.g. homer.j.simpson@springfieldnuclear.com - a regex will not catch this.
3) Typo in email address. e.g. john.smith@gmial.com - a regex will not catch this either.
The regex has downsides and complexity, but essentially no benefit.
A regexp for validating RFC-2821 email addresses is actually fairly simple.
Regex from the source: https://github.com/php/php-src/blob/master/ext/filter/logica...
http://fightingforalostcause.net/misc/2006/compare-email-reg...
Some people use many email addresses and so could create many accounts. With one email address they can still use the '+blahblah' method to sign up unlimited times, unless you prevent that which would annoy people who use it legitimately for filtering.
Some people have a garbage or throwaway email account that they sign up for everything with, and only ever look at to find the confirmation emails.
If people don't want to give you a valid email then there's no reason to be sending them anything.
filter_var('bob@example.com', FILTER_VALIDATE_EMAIL)
more info here : http://php.net/manual/en/function.filter-var.php
* to ensure it is deliverable? Well, then you better send them an email.
* to let people know when they misread the labels and put something that was clearly not an email in the email field? A simple check for an at-sign is usually sufficient.
* because some tester opens a ticket saying you can enter an invalid email in the email field? Yeah, that's where most of the complicated regexps come from.
I actually think that this library functions as a really great client-side validation that won't get you tripped up in trying to be RFC compliant. There's really not anything more that I'd do aside from sending that blessed confirmation email.
Is he really though?
We need a much more restrictive standard for emails, but until we have that we have to accept that each site will have a competing not-completely-overlapping set of standards. So make sure your email doesn't attempt to do anything too funny.
So while I agree with you in principle, in practice it seems infeasible. The differences bite in practice, unfortunately.
"My email address is joe.aol or was it aol.com@joe? Wait joeaol@com?"
It's also worth considering that one of the biggest generational markets (baby boomers) include a lot of those people you're telling us to ignore.
Couldn't an unscrupulous individual use that feature to take over non-activated accounts? An immediate use for that exploit doesn't spring to mind but this makes my spidey sense tingle. What sites allow this?
This is the source of 80% of all "bugs" I've fixed over the years.
Another personal favorite: If you enter WWWWWWWWWWWWWWWWWWWW W WWWWWWWWWWWWWWWW for name, it messes up the layout on the display screen.
[1] http://news.bbc.co.uk/2/hi/africa/5651310.stm
If the issue only appeared on all W's I'd guess you could set the bug as minor and discuss if it's worth fixing. If it costs an incredible amount of time to fix it, the problem relies more on defining priorities than on having too much granularity on the testing side.
To go back on your parent post, I'd say validating funky emails is of the same level. The test team should bring up the edge cases, fixing them or not is a matter of priorities.
You want an RFC821 (or more specifically RFC5321 now) email address regexp. See my post here about the email validator I wrote: https://www.emailitin.com/email_validator
"We see that bob@localhost doesn't look like a email address are you sure it's right?"
That way you can help users that messed up their email but not prevent all the corner cases. The idea is that most email addresses fall in a very narrow subset of the RFC: user@domain.tld and most people would have entered their email wrong if it didn't match that pattern.
No. This puts the burden of checking email validity on every user, even perfectly capable valid users. If you're validating for edge cases (mistakes or otherwise invalid addresses), treat it as an edge case and don't annoy users who can type.
? Whenever I hit a form which wants me to retype my address, I just triple-click to select the entire address, then middle-click to paste it into the confirmation field.
:(
It still amazes me that 70% of the places I attempt using foo+bar@gmail.com call it invalid. And that does not even begin to touch the myriad valid permutations that are "invalid" out there.
You can then block any address with a click if it's being abused.
If you're feeling generous, enough people using this link will earn me premium features: http://www.33mail.com/rj37w3