Unable to check email address for validity using regular expressions

What if I asked you to write a regular schedule to check e-mail addresses? You would probably think a minute, and then google the request. And you would get something like:

^([a-zA-Z0-9_-.]+)@([a-zA-Z0-9_-.]+).([a-zA-Z]{2,5})$ 

')
There are thousands of regulators on this topic. But why? Surely somebody, but read the standard RFC822 and issued a reliable regular season?



And even this monster is not able to check the email address. Why? It turns out that a lot can be hidden in a modest address. Some parts of the RFC822 standard are quite useful, and some are simply insane. But in any case it is interesting - let's understand.

Plus addresses

One of the most important features of the standard is the plus addresses. They can be useful and supported almost everywhere. Plus-address allows you to create a new mailing address from the old one, while the letters sent to the new address will come to the old mailbox.

Suppose Bob’s address is bob@smith.com. You can add a plus address by adding a + and a label after it: bob+spam@smith.com. If Bob registers on the website with the second address, he will still receive letters at bob@smith.com - but now he can create filters, or simply disable one of the plus addresses.

Another feature is that if you use unique plus-addresses for each of the sites, you can see where spam comes from or just letters that you did not expect to receive from this site.

When the regular breaks

#!$%&'*+-/=?^_`{}|~@example.org


Few know that the above address is absolutely admissible - all characters can be used in the local part (before the @ symbol). Moreover, the local part can even contain the @ symbol, if you enclose it in double quotes. For example:

"dream.within@a.dream"@inception.movie
bob."@".smith@mywebsite.com


And now - the carnival of madness

You, probably, already were surprised, what madness can be reached, studying email addresses. But while you are still ashamed of your attempts to write test regulars for addresses, here are some of the more insane things.

In principle, the previous versions of the addresses could still be thrust into the regulars, even if they looked monstrous. Now let's talk about the comments. Comments are arbitrary text enclosed in brackets, which can appear in one of 4 places of the address:

(here)a@b.com
a(here)@b.com
a@(here)b.com
a@b.com(here)


All options are semantically identical. They work like plus addresses — they just add some visual noise. All emails will need to come to a@b.com

If something worthy of effort, then for the sake of it, and you can overdo it
Ayn Rand, she is Alisa Zinovievna Rosenbaum

Add some more madness

Comments can be nested:

(here(is(some)crazy)comments)a@b.com




If you tried to parse recursive expressions, you know that it is very difficult. Now remember the monster from the beginning of the article so that your brain explodes.

Despite RFC822, we'd better agree that using simple and memorable email addresses is the right choice. Maybe we will find the best use of all these amazing features - in the meantime, write to me at

elliotchance+blog(silvrback)@gmail.com


PS I hope that spam bots will not guess that this is an email address.