Yeah, I agree, I think I'd have written that myself, but I don't think I'd reject it in review on that basis. I don't agree with sibling comment that it's 'shitty', it's trivially improved sure but it basically doesn't matter - if you want it to be actually correct you need to send an email to it for verification anyway.

Otherwise we can start saying not just not empty, it also needs no other @s etc. and before you know it we're rivalling the actually correct attempt up-thread. If you just want to catch typos, encourage entering real address (not just a space or full stop to fill mandatory field) then any basic thing is something, a compromise between legibility and how much it'll catch, we know there's a tonne of (mainly adversarial) bad input it'll miss, that's fine.

Is there a country where this has happened?

The denial of service was not intentional so I doubt you would win anything.

> I'm going to sue you for denying service arbitrarily and win

Which country are you claiming this entirely implausible legal scenario would work in?

It's all devs in general. As a java dev I have lost count of the number of times I have to tell any dev not to use a damn regex to validate emails.

But why do you even need to validate that email? Send the subscriber a confirmation link - if they get it then it was valid, if not then it's on them to fix the situation in whatever way they find fit.

A single massive and unreadable regex isn't an appropriate way to validate a spec that complex. With its complexity it can't be logically evaluated- only tested, whereas a function that breaks the spec out into steps/parts is going to be a lot more maintainable, readable, and auditable.