Look, your email validation logic is very, very likely wrong

I used to do complex email validations (like regexes etc), but have avoided using them for a long time. Currently, my email validations are 3 steps:

1. Using the <input type="email">

2. Checking if "@" exists

3. Sending the actual email (which practically speaking - is the actual validation that I needed)

Covers 99.99% of all cases I say.

Funnily enough the reason unusual email addresses were blocked in a lot of early CGI scripts was precisely to stop the wacky relaying and routing that the author points out could possibly happen given a sufficiently ancient mail setup.

See e.g (PDF warning): http://www.city-fan.org/ftp/contrib/websrv/formmail-advisory... "Creative Recipient Addressing"

People forget what a big problem spam used to be. And the utter insanity that ensued when you combined Perl CGI scripts with poorly configured Sendmail on dodgy hosts.

I think "^[A-Z0-9+_.-]+@[A-Z0-9.-]+$" or similar got enshrined as "best practice" sometime back then and has survived to the present day by framework inertia and copy/paste transmission from sites with 10+ year old answers to "how to validate an email address".

Now we've gotten to the point where it's probably OK to try to send to an "emoji cat face" or "<dog=cat>"a%b@c!d.e@foo.com but nobody really expects those to be reliably deliverable or usable for signup anymore. It's just a UX thing now.

My observation is that if you use the dumb obvious regex but just give people the "+" in the local part, nobody will complain. Certainly not by email, anyway...