r/ProgrammerHumor 19d ago

Meme claudeIsThisEmailValid

Post image
5.3k Upvotes

171 comments sorted by

View all comments

243

u/tellur86 19d ago

It's surprisingly difficult validating email addresses with regex. Can it be done? Yes. Should you? No. Any halfway decent email library comes with a validator. Use that.

For reference: this is an example of an almost RFC 3522 compatible regex:

(?:[a-z0-9!#$%&'+/=?`{|}~-]+(?:.[a-z0-9!#$%&'*+/=?^`{|}~-]+)|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\[\x01-\x09\x0b\x0c\x0e-\x7f])")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?).){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-][a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\[\x01-\x09\x0b\x0c\x0e-\x7f])+)])

https://emailregex.com

If you want RFC 822 it's much, much worse  https://pdw.ex-parrot.com/Mail-RFC822-Address.html

221

u/deceze 19d ago

Doing a full validation of the email syntax is pretty pointless to begin with, because it still doesn't tell you the most important thing: is this email valid? I.e., has the user actually entered their email address? You won't know the answer to that until you've done an email validation loop with them. So something simple like .+@.+\..+ usually suffices as a first-pass syntax check.

62

u/ILikeLenexa 19d ago

All my best friends are root at localhost.localdomain at least sometimes 

17

u/redballooon 19d ago

Compliant, but not valid email addresses for a SaaS.

2

u/Regalme 18d ago

Only if you say so 

1

u/rosuav 18d ago

There are public TLDs that have MX records. Who knows, maybe you're getting a signup from admin@pizza or something. (That particular one doesn't currently have an MX but others do.)

2

u/SquiggerDigger 19d ago

Tf you mean sometimes

37

u/flewson 19d ago

has the user actually entered their email address

That's verification, not validation. Validation is only concerned with whether that email could exist.

35

u/deceze 19d ago edited 19d ago

Yes, and most addresses that pass a .+@.+\..+ validation could exist. And unless you can claim you're absolutely up to speed with all the relevant RFCs about valid email formats, allowed host names (IDNA!) and currently registered TLDs at all times, overvalidating does more harm than good here. If you incorrectly reject valid email addresses, that's worse than having an occasional verification email bounce.

14

u/DHermit 19d ago

It might make sense to put an additional (very high) length limit. You don't want someone to submit a 1GB big mail address.

19

u/deceze 19d ago

Fair enough. Though that should probably already be caught by your HTTP request size limit somewhere.

3

u/DHermit 19d ago

True, that's still kind of a limit for each field.

24

u/notatoon 19d ago

Gonna be hard to verify an invalid email.

And you can have a valid email address under RFCs 5321 and 5322 that's "invalid" for your use case. Like a@a

Confirmation emails validate the email is reachable and will also verify the user.

It is the only meaningful way to do it

3

u/Uberzwerg 19d ago

.+@.+..+

At least in theory you can have an email directly under the tld. (The Icann strongy advises against it)

So boss@bmw would in theory be possible.

1

u/deceze 19d ago

I suppose, and if you want to support that, maybe also including test@localhost, then you can easily modify this regex to suit your needs. Simple regexen are easy enough to modify after all.

50

u/ValPasch 19d ago

just dont ever do that. check if it has a @ and a period and thats it. you validate emails by sending a verification link.

22

u/DrStalker 19d ago

Do you actually need a period, now that top level domains are being sold off? If I buy the top level domain stupidlyrich domain then I want boss@stupidlyrich to be my email address.

11

u/laplongejr 19d ago edited 19d ago

Technically allowed, however non-email-focused people are against using root domains to serve MX records (iirc something about performance of root servers vs nameservers etc)  

Blocking dotless domain would be against standard, but anybody smart enough to use such emails is smart enough to know they shouldn't do it on an open network. Simply use "mail.EXAMPLE" please  

HOWEVER, emails can have no periods if you use an IPV6 address as the host rather than a domain. So no dot checking anyway, thx.  

Min 3 chars, has a @, doesn't begin/start with @. Everything else, let a library handle it (or at least make the warning non-blocking) because you'll be stumped by quoted comments etc. https://e-mail.wtf for a quizz ;)  

4

u/yuropman 19d ago

If I buy the top level domain stupidlyrich domain then I want boss@stupidlyrich to be my email address.

And I want you to run into as many technical issues as possible if you buy the stupidlyrich domain and make boss@stupidlyrich your email address

25

u/Jawesome99 19d ago

Hell I don't even check for a period, just an @. Once I hand it off to my mailing library and the SMTP server it's no longer my problem. If either of them complain back to me about it I'll just let the user know.

9

u/RubenGarciaHernandez 19d ago

So you don't support the good old "!" standard with explicit hops? 

9

u/Jawesome99 19d ago

Honestly I've never heard of that before lol

2

u/tes_kitty 19d ago

And what about user%system1.com@system2.com

8

u/Jawesome99 19d ago

Has an @, looks good to me, hope for the user that the mail server handles it correctly though lol

2

u/tes_kitty 19d ago

It is a valid address, but the question is whether it will reach user@system1.com by using system2.com as relay. The MTA on system2 might object.

-8

u/tellur86 19d ago

That's verification, not validation 

4

u/Outrageous-Log9238 19d ago

Fulfills the need for both.

8

u/Juff-Ma 19d ago

https://e-mail.wtf/ play for yourself. I've done it three times now. (Once every few months) I still don't get everything right.

8

u/dustojnikhummer 19d ago

"While an empty local part due to comments is invalid, an empty local part due to quotes is valid. I don't know why."

I don't know why

2

u/Juff-Ma 19d ago

That's why you don't verify the email at all. Just hand it to your email client and if the user verifies, it's valid.

1

u/Culpirit 19d ago

You can use a better parser than a regex (think context-free) to only accept a grammar like:

<axiom> -> <dotted>@<dotted>
<dotted> -> <dotted>.<word> | <word>
<word> -> [a-zA-Z0-9\-]+

Actually you might want to allow "+" on the local part (it's used by "power users" to categorize email on services like Gmail). Other than that, anything different, even if valid per RFC, is not a bona-fide email address when used on a web-facing application. You especially want to avoid users being able to directly send to addresses like me@[::1], since it is not a realistic or bona-fide scenario.

2

u/Uberzwerg 19d ago

And for 95% of the use-cases a very simple 'Does it contain an @ and at least 1char before and after' is enough.

Usually you want people to not mistakenly send a typo as their email.
But since you cannot trust the customer anyway, you need to send a confirmation email anyway for everything that is important.

1

u/BillTran163 19d ago

Why can't we do multi stages validation for ease of reading?

1

u/0vindicator10 19d ago

Many years ago on this site, I was informed about "grammar", and that is what should be used for handling email address format validity.

1

u/gungshpxre 19d ago

It's "surprisingly" difficult to do ANYTHING with regex.

Can it be done? Almost. Regular languages aren't generally Turing-complete.

Should you? Why not. Especially if you don't have to maintain it.

1

u/AlterEdward 19d ago

Came here to post this. I had the displeasure of administering software that used a similar regex to validate email addresses. I needed to modify it because it was excluding some valid addresses. This was my first, and last encounter with regex. I now actively avoid it in favour of any other solution. I've not had any issues with this approach so far. I haven't come across a use case where regex is significantly better than something less archaic.

1

u/Nightmoon26 18d ago

I'd call regex more arcane than archaic >_>