There is a typo on line 17.

That is an absurdly complex regex

Email address specs turn out to be rather complicated.

I really wish people wouldn't code their own checks rather than use already existing standards. Some languages like Java even include proper checks in their standard library: https://java.net/projects/javamail

Several jobs back I had no end of arguments with some Java devs about not writing their own checks, that kept routinely failing on legitimate addresses.

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.

It really is, I wonder if anyone has tested that extensively. It's so complex that just by reading it I don't think anyone would be able to confirm it matches the RFC correctly.

It's a pragmatic one. It has no false negatives, and there's rarely a reason to care about false positives. (Especially not where a stricter regex would (be the only mechanism to) catch it, but a fake-but-valid address wouldn't trivially bypass it.)

At the very least, I assume .+ at the start is a better choice.

The RFC says:

     addr-spec   =  local-part "@" domain        ; global address
     atom        =  1*<any CHAR except specials, SPACE and CTLs>
     word        =  atom / quoted-string

so I think the bit in front of the @ has to be non-empty.

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.

Agreed. I should have said so, too.

I agree with the sentiment, but this one is just shitty. Switch out the stars for pluses and it’d be a lot better

At a certain point I think you're allowed to say you don't care if the person with this email address is capable of signing up or using your service:

very.”(),:;<>[]”.VERY.”very@\\ "very”[email protected]

Too bad - if that's my email address and you're rejecting it, I'm going to sue you for denying service arbitrarily and win. Not every country is the USA.

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

You'd have to fix your code, at least.

Is there a country where this has happened?

> 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?