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
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.