If you try to handle email precisely correctly according to the specification, you will find that users will complain that you're handling email incorrectly. Th

If you try to handle email precisely correctly according to the specification, you will find that users will complain that you're handling email incorrectly. The biggest aspect of this is case-sensitivity: local parts are officially case sensitive, but the overwhelming practice is that email addresses are case insensitive, and people expect to find email addresses via case-insensitive lookup. 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.