5 ms·

Have you tried parsing an email address with a regex? http://emailregex.com/ http://emailregex.com/

by pdpi 6y ago

Joeboy 6y ago
Have you tried parsing an email address (in an RFC compliant way) without a regex?
- deckard1 6y ago
  to be fair, the email RFC is a silly document that does silly things. The user part of an email address "may" be case-sensitive. But in practice, no one does that. Because imagine grandma on the phone with her bank not remembering if her email address was Mary123@gmail.com, MARY123@gmail.com, or mary123@gmail.com. The horror.
  - layer8 6y ago
    Some systems (used to) map the local part to local unix usernames, which are case-sensitive. Hence the sender would get a 550 No such user (or similar) if he got the case of the local part wrong.
- andyjpb 6y ago
  Yes! http://wiki.call-cc.org/eggref/4/email-address http://wiki.call-cc.org/eggref/4/email-address https://bitbucket.org/knodium/email-address/src/master/email-address.scm https://bitbucket.org/knodium/email-address/src/master/email... It's a fair few lines of code but most of it comes directly from the RFC. It's also longer than it could be because it covers the entire RFC822 syntax, including groups, lists, routes, comments and To: header styles.
DonHopkins 6y ago
Have you tried parsing a regex with a regex? http://regexregex.com/ http://regexregex.com/ [WARNING: DO NOT CLICK THAT LINK OR YOU WILL BREAK THE INTERNET!]
- drdeca 6y ago
  the language of regex expressions is not a regular language though? It has parenthesis matching.
jcranmer 6y ago
There's a certain amount of irony there where there's about a dozen different regexes that all match different languages. And none of them are right, for that matter (non-ASCII email addresses are a thing).
magicalhippo 6y ago
There are a lot of really useful use-cases between not using regexp and using regexp to parse email addresses. For example, our system needs to handle container numbers[1] as part of an official form, and we check them for correctness to avoid rejection of the form. As far as we're concerned the container number consist of four letters and seven digits. However the user is allowed to submit a container number with a hyphen or a space between the letters and the digits. Writing a regex that checks for a properly formatted container number is quick, easy to understand and a lot less convoluted than most alternatives. [1]: https://en.wikipedia.org/wiki/ISO_6346 https://en.wikipedia.org/wiki/ISO_6346
seph-reed 6y ago
/\S+@\S+/ (This is a joke)
- quesera 6y ago
  > (This is a joke) ...but it's closer to correct than most email regexes in the wild!
samatman 6y ago
Email is the rare "validate, don't parse" case. With an email address, you almost always want a valid email address, and don't much care why it's valid. So, sure, check for an @ in there, but then just... try and email it with a link, if the page gets visited, congrats, you have a valid email address.
- andyjpb 6y ago
  This will allow your program to be used as a vector to attack the things your program depends on. It's true that those bits of eMail infrastructure are probably more robust but it's still strictly bad practice. Even if you're "just" storing it in your database, you should sanitise it on the way in so that when someone does something "unexpected" with it, such as display it in a web browser UI, you're not going to suffer from injection attacks there either.
  - PeterisP 6y ago
    Relying on sanitization is bad practice. Your systems should work properly and securely even if every text field in your database is filled with Robert'); DROP TABLE Students;-- or <script>alert(document.cookie)</script> - if displaying them in web UI leads to an injection or XSS, then the web UI code is horribly broken and needs to be fixed, input sanitization is at best a temporary workaround.
    - andyjpb 6y ago
      You're not strictly wrong... But what I'm trying to say is that what's in your database should be well defined. You shouldn't just put any old stuff in there. You should have a standard for exactly how everything is escaped (or not) so that your consumers have a spec to work to. You'd do the same with, say, character encodings. One option is to convert everything to a single character set on the way in, such as UTF-8. Another option is to annotate everything with the character set it uses. You must chose one. Relying on adhoc code spread across the codebase for the security properties of untrusted data leads to whack-a-mole security situations. Being able to trust the data in your database is essential. Note, that absolutely doesn't mean things like "Robert'); DROP TABLE Students;--" shouldn't appear in database fields. It just means that if you define the type of a field to be "eMail address" then consumers of it really should be able to trust that it really is a legitimate and valid eMail address. What does "valid" mean in this context? Well, that's up to your spec. Perhaps just "legally structured". Perhaps "something that eMail can actually be delivered to". Perhaps "something that is known and assured to actually be associated with this particular user". ...but you must be explicit otherwise consumers have nothing to work from and you're building castles on the sand.
bentcorner 6y ago
https://davidcel.is/posts/stop-validating-email-addresses-with-regex/ https://davidcel.is/posts/stop-validating-email-addresses-wi... Apropos to OP, this article also quotes JWZ.
nwallin 6y ago
What, in your opinion, is the correct way to parse an email address?
- pdpi 6y ago
  Oh I have absolutely no good insight into what a better way to do it would be, if any. Just saying that doing it “properly” does not have a nice solution in the shape of a simple regexp

Have you tried parsing an email address with a regex? http://emailregex.com/ http://emailregex.com/

by pdpi 6y ago

Have you tried parsing an email address with a regex? http://emailregex.com/ http://emailregex.com/

Joeboy 6y ago

Have you tried parsing an email address (in an RFC compliant way) without a regex?

deckard1 6y ago
to be fair, the email RFC is a silly document that does silly things. The user part of an email address "may" be case-sensitive. But in practice, no one does that. Because imagine grandma on the phone with her bank not remembering if her email address was Mary123@gmail.com, MARY123@gmail.com, or mary123@gmail.com. The horror.
- layer8 6y ago
  Some systems (used to) map the local part to local unix usernames, which are case-sensitive. Hence the sender would get a 550 No such user (or similar) if he got the case of the local part wrong.
andyjpb 6y ago
Yes! http://wiki.call-cc.org/eggref/4/email-address http://wiki.call-cc.org/eggref/4/email-address https://bitbucket.org/knodium/email-address/src/master/email-address.scm https://bitbucket.org/knodium/email-address/src/master/email... It's a fair few lines of code but most of it comes directly from the RFC. It's also longer than it could be because it covers the entire RFC822 syntax, including groups, lists, routes, comments and To: header styles.

DonHopkins 6y ago

Have you tried parsing a regex with a regex? http://regexregex.com/ http://regexregex.com/ [WARNING: DO NOT CLICK THAT LINK OR YOU WILL BREAK THE INTERNET!]

drdeca 6y ago
the language of regex expressions is not a regular language though? It has parenthesis matching.

jcranmer 6y ago

There's a certain amount of irony there where there's about a dozen different regexes that all match different languages. And none of them are right, for that matter (non-ASCII email addresses are a thing).

magicalhippo 6y ago

There are a lot of really useful use-cases between not using regexp and using regexp to parse email addresses. For example, our system needs to handle container numbers[1] as part of an official form, and we check them for correctness to avoid rejection of the form. As far as we're concerned the container number consist of four letters and seven digits. However the user is allowed to submit a container number with a hyphen or a space between the letters and the digits. Writing a regex that checks for a properly formatted container number is quick, easy to understand and a lot less convoluted than most alternatives. [1]: https://en.wikipedia.org/wiki/ISO_6346 https://en.wikipedia.org/wiki/ISO_6346

seph-reed 6y ago

/\S+@\S+/ (This is a joke)

quesera 6y ago
> (This is a joke) ...but it's closer to correct than most email regexes in the wild!

samatman 6y ago

Email is the rare "validate, don't parse" case. With an email address, you almost always want a valid email address, and don't much care why it's valid. So, sure, check for an @ in there, but then just... try and email it with a link, if the page gets visited, congrats, you have a valid email address.

andyjpb 6y ago
This will allow your program to be used as a vector to attack the things your program depends on. It's true that those bits of eMail infrastructure are probably more robust but it's still strictly bad practice. Even if you're "just" storing it in your database, you should sanitise it on the way in so that when someone does something "unexpected" with it, such as display it in a web browser UI, you're not going to suffer from injection attacks there either.
- PeterisP 6y ago
  Relying on sanitization is bad practice. Your systems should work properly and securely even if every text field in your database is filled with Robert'); DROP TABLE Students;-- or <script>alert(document.cookie)</script> - if displaying them in web UI leads to an injection or XSS, then the web UI code is horribly broken and needs to be fixed, input sanitization is at best a temporary workaround.
  - andyjpb 6y ago
    You're not strictly wrong... But what I'm trying to say is that what's in your database should be well defined. You shouldn't just put any old stuff in there. You should have a standard for exactly how everything is escaped (or not) so that your consumers have a spec to work to. You'd do the same with, say, character encodings. One option is to convert everything to a single character set on the way in, such as UTF-8. Another option is to annotate everything with the character set it uses. You must chose one. Relying on adhoc code spread across the codebase for the security properties of untrusted data leads to whack-a-mole security situations. Being able to trust the data in your database is essential. Note, that absolutely doesn't mean things like "Robert'); DROP TABLE Students;--" shouldn't appear in database fields. It just means that if you define the type of a field to be "eMail address" then consumers of it really should be able to trust that it really is a legitimate and valid eMail address. What does "valid" mean in this context? Well, that's up to your spec. Perhaps just "legally structured". Perhaps "something that eMail can actually be delivered to". Perhaps "something that is known and assured to actually be associated with this particular user". ...but you must be explicit otherwise consumers have nothing to work from and you're building castles on the sand.

bentcorner 6y ago

https://davidcel.is/posts/stop-validating-email-addresses-with-regex/ https://davidcel.is/posts/stop-validating-email-addresses-wi... Apropos to OP, this article also quotes JWZ.

nwallin 6y ago

What, in your opinion, is the correct way to parse an email address?

pdpi 6y ago
Oh I have absolutely no good insight into what a better way to do it would be, if any. Just saying that doing it “properly” does not have a nice solution in the shape of a simple regexp