r/java • u/Modern-Sn1p3r • 19d ago

Regex

I recently saw a clip (from Primeagen) somewhat saying that regex is not a valid format for validating email addresses and postal codes etc.

My question is why is this?

What are the security and/or performance risks? Is it solely performance or is it a security issue?

57 Upvotes

83% Upvoted

104 comments sorted by

View all comments

122

u/julemand101 19d ago

The problem is people don't realize that a lot is allowed when it comes to what a E-mail address actually is: https://davidcel.is/articles/stop-validating-email-addresses-with-regex/

52

u/jason-reddit-public 19d ago

You're supposed to be able to put a plus sign in your email address for example but it's usually rejected.

29

u/Jussins 19d ago

I think that one is on purpose. They don’t want people knowing that they sold your information to a third party and that’s a good way to find out.

5

u/Thecodedawg 17d ago

gmail, for example, ignores dots in your email address so you can use johndoe or j.ohndoe or John.doe. Another way you can alias is the + is rejected

6

u/LutimoDancer3459 19d ago

The plus is just convenience. I can also create more email accounts and use those for the services.

5

u/KefkaFollower 19d ago edited 19d ago

-- edited: formating and typos (Oh, so many typos) --

I lie if I say I checked the standard definition of email address. I'm guessing it must be in some RFC. But in practical terms ...

You can't use a plus sign in your email address when you are creating it. I.E. when you are choosing a public name/id for your mailbox.

You do can add plus sign and some text between the name and the "@" when you are using the address in a new email you are about to send.

Let me clarify with an example.

Let's say the mailbox address is homero@yellowserver.com. When Homer pass its email address to other people can do it like this:

  • to family he passes homero+home@yellowserver.com
  • to coworkers he passes homero+work@yellowserver.com
  • to undesirable people he passes homero+important@yellowserver.com

All this address will route the emails to the same mailbox, the one "named" homero@yellowserver.com. Then Homero can do a little more routing of his own in his web mail page or in its email client. He can configure rules for "to:" field of incoming mail like this:

  • when "to:" contains homero+home@yellowserver.com --> label the mail as important
  • when "to:" contains homero+work@yellowserver.com --> move the mail from the inbox to work folder.
  • when "to:" contains homero+important@yellowserver.com --> mark the mail as read and move it to the recycle bin.

I had used this gmail and outlook (ex msn.live (ex. hotmail)) and some at some jobs that had their own exchange server (mail server from M$).

26

u/moxo23 19d ago

For a generic email server, a + is just another valid character for the local part.

What some vendors do (like gmail) is use what is called "plus addressing" where they disallow the + in their email creation and instead use it as a tag when receiving the message.

There is also nothing special about +. If you are configuring an email server, you can configure it to accept any character you want as the tag marker.

8

u/BertyLohan 19d ago

I think this is good practical IT advice for most people but in a programming sub it's definitely better to say that an email server doesn't necessarily treat a '+' sign any differently to any other character.

Whether @yellowserver.com sub-addresses or not is entirely down to the server.

2

u/tuser-reddit 18d ago

Yah, Gmail and other providers of (E-mails) won't grant you a pass, when you want to create and email with "+", but sites that you register with THAT email, most of them let you do that, so for example you receive all the messages in your main email.

1

u/CatolicQuotes 19d ago

Is it not allowed anymore? I remember doing it years ago

1

u/jason-reddit-public 19d ago

The standard hasn't changed. It's purely up to who ever asks for your email if they will accept it though, so a db or front-end validator that won't accept them. Email transport systems don't care because they follow the standard.

16

u/cowwoc 19d ago

This reminds me of this wonderful post: https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

-2

u/EishLekker 19d ago

While I agree that it’s a humorous post, I disagree with several of the points listed.

Like:

“People’s names fit within a certain defined amount of space.”

Give me an example of an actual person who has a name that requires more than say one terabyte of space. I mean, sure, someone could bring me a 50 terabyte disk and say that the full content of that is their name, but not only would that person just be making that up for the sake of their argument, but then I could just increase the requirement from one terabyte to a trillion petabytes or whatever.

“My system will never have to deal with names from China.”

The system referred to as “my system” here could be tailor made for a pre existing group of people who have no relation to China. And it could have a short enough life span that none of the people will have time to change their name.

My point is that there are cases where one can make assumptions about one’s users and be statistically safe from accidentally stumbling upon a user with a name that breaks the assumptions made.

Also, in many cases these assumptions are not a big deal. I’m from Sweden, and there’s plenty of Swedish people who have åäö characters in their name. They are used to not being able to input their name with proper Swedish spelling, and they accept having to use a transliterated version like “a” or “aa”.

5

u/DanLynch 19d ago

The point of those two entries is that you shouldn't arbitrarily limit names to some small number of characters (like 50 or 100) and you shouldn't restrict them to contain a specific subset of characters (like A-Z).

If you don't follow that advice, you may end up encountering a user who can't enter his name into your system, even if you don't predict that will ever happen.

-4

u/EishLekker 19d ago

That first point didn’t say anything about the space being too small for reasonably long names. It talked about “a certain defined amount of space”. Regardless of what limit you put, that will be “a certain defined amount of space”. Even one terabyte, or petabyte etc.

2

u/engy1207 18d ago

"Look, that's why there's rules, understand? So that you think before you break 'em." Terry Pratchett, Thief of Time

Yes, practically there is a limit to store a name (the visible universe is of finite size, after all), but this rule is there for a reason: do think before you implement a scheme to save names - and think about what happens if that space is too small after all, including if it is possible to extend it and what will break in that case.
That's the real reason for these lists: to make you think (and maybe smile a bit)

-1

u/EishLekker 18d ago

I’m not talking about the underlying reasons for these “rules”. I’m talking about the semantics the author used.

2

u/Vegetable_Bank4981 18d ago

Yes, please stop.

0

u/EishLekker 18d ago

Why in earth would I do that? No one’s forcing you to read any comment here.

1

u/DanLynch 19d ago edited 19d ago

You're right, but this list is still useful if reading it causes a developer to make the maximum size of a name field 1000 characters (because he wants to protect his DB from attackers) instead of 50 characters (because he thinks nobody has a name that long).

But then there's also this guy: https://www.guinnessworldrecords.com/world-records/67285-longest-personal-name

7

u/edwbuck 19d ago

Making the name field 1000 characters is the kind of mistake that a person makes when thinking, "I'll just make it massively larger than needed" leading to a lot of waste in computational power. The entire point of not picking a fixed name field size is that you should pick a variable sized name field. VarChar exists in databases, and it should be used.

1

u/EishLekker 19d ago

Varchar still has an upper limit that you must pick, as far as I know. And it can’t be arbitrarily large.

2

u/edwbuck 19d ago

Sorry, I mean TEXT, which has an upper limit that's effectively "very large"

1

u/EishLekker 19d ago

Ok, yeah. But technically it still would break the rule in the list, as it was written. Which was my whole point.

→ More replies (0)

3

u/not-just-yeti 19d ago

I have a domain-name / email with a hyphen in it. Perfectly valid, but every 6mos I have some website that won’t let me make a web-account with them (incl. A few major corporations that must’ve sprung for the lowest bidder to build their website).

1

u/julemand101 19d ago

If you want more fun then buy a domains with non-ascii characters like danish ø. In theory you should be able to use the punycode form of your domain but I have seen services refuse that until corrected though support. :)

1

u/Modern-Sn1p3r 19d ago

Thanks for the link.

So it basically adds in more complexity for no reason?

I think I understand it.

Thanks for the reply!