While the RFC allows a lot of weird email address edgecases, I see little reason to allow most of these when a user signs up to my service. How many legitimate users will use quoted strings, dotless domains or even IP addresses?
12 is almost certainly a typo
13 is probably a spammer
Also <input type=email> will reject several of these as well, so if you have such an edge-case email in your database, you'll run into issues with html forms.
How many legitimate users will use capital letters, which I had to add to an in-production email validator on an app with millions of MAUs?
Just send a confirmation email to whatever string they provide you.
You might want to first check that it is not a local address, and to reject it if it is (unless it is being used for an internal registration service). You should also reject it if the destination is unreachable (in which case it is not possible to send a confirmation email, anyways).
Millions?
If you are in the former category, then yes, follow the spec to the letter. If you're in the latter, then screw the precise guidelines of the spec and reject emails that are very unlikely to be valid: no quoted localparts, no IP address literals. In addition, go ahead and say that email is case-insensitive (more precisely, case-preserving).
As I say in my sibling comment, there are generally two purposes you might have with an email address. If your primary purpose is actually handling email, then that is when you need to be perfectly precise for email. But if your purpose is in using the email address as some sort of "universal internet ID"--this is true for the vast majority of uses of email addresses--then restricting the set of potentially valid email addresses is not only valid but a good idea.
Quoted string local-parts and IP address literals in lieu of domains are things which are generally broken by middleware software that deals with email addresses anyways, to such a degree that there is no way anyone who has such an email address is using it as anything other than a "do you actually support this" email address--it can't be a valid unique-ish identifier for them. Additionally, allowing them to creep into parts of your system may break assumptions of other databases, which increases the chance of weird, deep failures that may cause security vulnerabilities. That alone is a pretty good reason to block them.
Sure there is. It may signal more edge-case behavior to come. If you're building a developer tool, you should probably support it. But if you're building a consumer product, that may not be a customer you want.
I pass no judgment here. I only mean to admit my incorrect assumption.
What?
Some customers cost more to serve than they will ever make you. Still serving them may make sense. But often it doesn’t. If you’re bootstrapping a gummy bear start-up, a customer who pings you weekly with edge-case support tickets is unlikely worth the engineering effort to appease. If you’re building an AWS competitor, on the other hand, you may want to hire them.
For the average company trying to navigate these sorts of decisions, supporting users with emails like "a$123@1-2-3.12397.museum" probably isn't high on their list of priorities, regardless of whether it's "valid" or not.