Have you tried parsing an email address with a regex?
But in practice, no one does that. Because imagine grandma on the phone with her bank not remembering if her email address was Mary123@gmail.com, MARY123@gmail.com, or mary123@gmail.com. The horror.
http://wiki.call-cc.org/eggref/4/email-address
https://bitbucket.org/knodium/email-address/src/master/email...
It's a fair few lines of code but most of it comes directly from the RFC. It's also longer than it could be because it covers the entire RFC822 syntax, including groups, lists, routes, comments and To: header styles.
For example, our system needs to handle container numbers[1] as part of an official form, and we check them for correctness to avoid rejection of the form.
As far as we're concerned the container number consist of four letters and seven digits. However the user is allowed to submit a container number with a hyphen or a space between the letters and the digits.
Writing a regex that checks for a properly formatted container number is quick, easy to understand and a lot less convoluted than most alternatives.
[WARNING: DO NOT CLICK THAT LINK OR YOU WILL BREAK THE INTERNET!]
With an email address, you almost always want a valid email address, and don't much care why it's valid.
So, sure, check for an @ in there, but then just... try and email it with a link, if the page gets visited, congrats, you have a valid email address.
It's true that those bits of eMail infrastructure are probably more robust but it's still strictly bad practice.
Even if you're "just" storing it in your database, you should sanitise it on the way in so that when someone does something "unexpected" with it, such as display it in a web browser UI, you're not going to suffer from injection attacks there either.
But what I'm trying to say is that what's in your database should be well defined. You shouldn't just put any old stuff in there. You should have a standard for exactly how everything is escaped (or not) so that your consumers have a spec to work to.
You'd do the same with, say, character encodings. One option is to convert everything to a single character set on the way in, such as UTF-8. Another option is to annotate everything with the character set it uses. You must chose one.
Relying on adhoc code spread across the codebase for the security properties of untrusted data leads to whack-a-mole security situations.
Being able to trust the data in your database is essential.
Note, that absolutely doesn't mean things like "Robert'); DROP TABLE Students;--" shouldn't appear in database fields.
It just means that if you define the type of a field to be "eMail address" then consumers of it really should be able to trust that it really is a legitimate and valid eMail address. What does "valid" mean in this context? Well, that's up to your spec. Perhaps just "legally structured". Perhaps "something that eMail can actually be delivered to". Perhaps "something that is known and assured to actually be associated with this particular user".
...but you must be explicit otherwise consumers have nothing to work from and you're building castles on the sand.
Apropos to OP, this article also quotes JWZ.
(This is a joke)
...but it's closer to correct than most email regexes in the wild!