There is absolutely is a correct way to lexically validate an e-mail address: namely, implement a parser for the syntax specified in whatever RFC is the up-to-date successor of RFC 822.
There is such a thing as incorrect e-mail address syntax: namely, non-RFC-conforming syntax, whatever that is.
I agree, with two specific exclusions: notations for IP addresses in square brackets, and comments. Just removing those two never-encountered-in-real-life syntaxes reduces the RFC regex down to nothing. Comments are not a real thing, RFC be damned. And square bracketed IP addresses are never encountered in the real world, especially with the requirements for PTR records to pass all the major providers' spam filters.
Anyone trying to provide an email address with a square bracketed IP or a comment is specifically trying to find an excuse to cause drama when their email is rejected. Those exceptions aside, fuck anyone who validates email addresses that don't permit perfectly valid real-world characters like '+', or who whitelist specific TLDs (.com, .org, .net et al).
Email addresses are defined and have an interpretation not according to RFC 5322 (which defines how you can write them in a message), but rather RFC 5321 (which defines how to route email addresses). Note that the RFC 5321 definition does not permit CFWS--its existence is merely an artifact in RFC 5322 of being able to insert whitespace (and later comments) anywhere in the grammar. Any tool which accepts CFWS in an email address that is not reading an addr-spec field of an RFC 822 mail message is incorrect.
Beyond the issue of comments, I'd advocate rejecting the use of IP address literals and quoted localparts. Additionally, despite the injunctions on interpreting local-parts, in practice, it is best to treat email addresses as case-preserving: you'd consider a@example.com and A@example.com to be the same email address, but if the user typed in the latter, don't normalize it to the former.
Comments are and should be a real thing. They are, for example, how to use service-specific email addresses when using a mail provider who does not treat + as a folder extension (jack+suzy@provider.invalid is a perfectly valid email address for Jack & Suzy).
FWIW, I tested recently, and Google do exactly the Right Thing™ with comments in email addresses: they deliver the mail.
There is absolutely is a correct way to lexically validate an e-mail address: namely, implement a parser for the syntax specified in whatever RFC is the up-to-date successor of RFC 822.
There is such a thing as incorrect e-mail address syntax: namely, non-RFC-conforming syntax, whatever that is.
You may reject that, and that's about it.
Please don't reject RFC-conforming e-mail addresses.