Earlier quoted context omitted.
I tried using that expression for a while, but then a user with a valid email address containing upper unicode characters showed up. I switched to a simpler expression: ^[^@\s\x00-\x1f]+@[^@\s\x00-\x1f.]+(:?\.[^@\s\x00-\x1f.]+)*$ It requires exactly one "@", disallows whitespace and control characters, prevents repeated dots in the domain name, and ensures the domain doesn't end with a dot. It catches a few typos and…
Domains ending with a dot are valid though, and it's needed sometimes. For example, someone@ai. (ai. is a TLD) is a different email than someone@ai (ai is a local hostname)
Stop Validating Email Addresses with Regex (2012)
151–160 of 228 posts
Re: Stop Validating Email Addresses with Regex (2012)
#152The only way to validate an email is to send a message to the email address. Validating that it fits the rfc is pointless, because a) its very easy to create an email that is both false and meets the rfc, b) email provider might bypass the rfc and the email would still be working. To validate user input, I use that: /^[^@]+@[^.]+\..+$/. It's doesn't tell me if the email is semantically correct per the rfc because I'm…
It's the difference between type checking and business logic validation.
E.g., Type check that the user's name is a String and then let the database/business-logic yell at you when it's not unique.
In this case, checking that an email address input is "shaped" like 'not-empty@not-empty' is the "type check", and then actually sending an email is the only way for your business logic to know if it's actually valid.
Re: Stop Validating Email Addresses with Regex (2012)
#153I think an initial test with regex is valid. But you should do a proper email validation link. That being said, you need to be very careful with what regex validation you are doing. I still use an apple "@me.com" email. Somewhere there is a commonly used library (or commonly used regex copied from stack overflow) that seems to fail because my domain is short. I have had a number of times that I have been unable to ge…
Similar experience for me. Many online forms fail to accept any email extension that isn't ".com", ".net", ".edu" or ".org". I'm surprised, because developers should know better that there are many more extensions beyond these four. Here is a full list of domain extensions available: https://www.name.com/domains . Let's just say one of these is registered and used as my email. I have found two ways of getting around…
Here is the actual, official, list of TLDs:
Re: Stop Validating Email Addresses with Regex (2012)
#154If you are concerned with the maintainability of RegEx (i.e. "Now you have 2 problems"), do it via simple string parsing. It's more code, but it's readable by mere mortals.
If it has an @ sign, split at the @ sign.
If either string has a space or other invalid character, it's invalid. Yes, there are more invalid characters for the domain than the username (I would make the case the username should just be whitespace chars, and the @ sign).
If the second string doesn't have a dot in it, it's invalid.
Split the second string by dot. If the last string of that array is not a valid TLD, it's invalid. (I realize new TLD's are popping up these days, so this step may not be strictly needed)
Not being too strict is in your interest here. You avoid too many email bounces by allowing some things which may be bad but allowed in some email providers but not others. It's a case of "Perfect is the enemy of good enough".
Re: Stop Validating Email Addresses with Regex (2012)
#155If you are concerned with the maintainability of RegEx (i.e. "Now you have 2 problems"), do it via simple string parsing. It's more code, but it's readable by mere mortals. If it has an @ sign, split at the @ sign. If either string has a space or other invalid character, it's invalid. Yes, there are more invalid characters for the domain than the username (I would make the case the username should just be whitespace…
[deleted]
Re: Stop Validating Email Addresses with Regex (2012)
#156If you are concerned with the maintainability of RegEx (i.e. "Now you have 2 problems"), do it via simple string parsing. It's more code, but it's readable by mere mortals. If it has an @ sign, split at the @ sign. If either string has a space or other invalid character, it's invalid. Yes, there are more invalid characters for the domain than the username (I would make the case the username should just be whitespace…
> If either string has a space or other invalid character, it's invalid
Nope, could have a quoted string which can contain whitespace.
addr-spec = local-part "@" domain
local-part = dot-atom / quoted-string / obs-local-part
qtext = %d33 / ; Printable US-ASCII
%d35-91 / ; characters not including
%d93-126 / ; "\" or the quote character
obs-qtext
qcontent = qtext / quoted-pair
quoted-string = [CFWS]
DQUOTE *([FWS] qcontent) [FWS] DQUOTE
[CFWS]
Nope, domain names dont require a dot.
::= | " "
::= | "."
Doesnt need to be a "valid TLD" to be a valid domain
Re: Stop Validating Email Addresses with Regex (2012)
#157The only way to validate an email is to send a message to the email address. Validating that it fits the rfc is pointless, because a) its very easy to create an email that is both false and meets the rfc, b) email provider might bypass the rfc and the email would still be working. To validate user input, I use that: /^[^@]+@[^.]+\..+$/. It's doesn't tell me if the email is semantically correct per the rfc because I'm…
It isn’t pointless. It is fast feedback for typos and form validation
The parent's regular expression covers the most egregious typos without making any assumptions about domain names or tlds. If you wanted to help out with common typos you could add additional logic to specifically check for "*@gmial.com" or other permutations of the common domains. If you wanted to get really fancy, you could even run it by an edit distance function against the common domains and warn if they're close to a common one but not quite there.
Most typos, however, are likely to be in the first part, not in the domain. The only real way to validate against those is to try the address and see.
Re: Stop Validating Email Addresses with Regex (2012)
#158Earlier quoted context omitted.
It isn’t pointless. It is fast feedback for typos and form validation
But the proof of the validation is in the sending. If it’s important I send a validation email
There is some value in reducing the number of bad emails sent out, because email providers don't like it if you send large numbers of emails to bad addresses. So if you can help someone get their email right the first time, it's worthwhile, as long as the mechanism you use isn't overbearing.
Re: Stop Validating Email Addresses with Regex (2012)
#159Earlier quoted context omitted.
But in the context of a web app though? That's the key part: you're taking in email addresses from myapp.example.com. For other cases: sure, local email addresses can be useful (not often these days, but sometimes still are). But in this context I'm not really seeing any use case.
At previous $work, I wrote a rails app that managed releases. On the app you could sign up for email notifications when your change was released. These went through the unix local email system. So yes there is very much a use case
It's still a bit silly to tell every SaaS developer that they shouldn't validate that they have a normal-looking domain because some people's use cases call for sending emails to local addresses or to TLDs directly. If a developer needs to handle those cases, they know already, and they're in a vanishingly small minority.
Re: Stop Validating Email Addresses with Regex (2012)
#160If you are concerned with the maintainability of RegEx (i.e. "Now you have 2 problems"), do it via simple string parsing. It's more code, but it's readable by mere mortals. If it has an @ sign, split at the @ sign. If either string has a space or other invalid character, it's invalid. Yes, there are more invalid characters for the domain than the username (I would make the case the username should just be whitespace…
> If either string has a space or other invalid character, it's invalid Nope, could have a quoted string which can contain whitespace. addr-spec = local-part "@" domain local-part = dot-atom / quoted-string / obs-local-part qtext = %d33 / ; Printable US-ASCII %d35-91 / ; characters not including %d93-126 / ; "\" or the quote character obs-qtext qcontent = qtext / quoted-pair quoted-string = [CFWS] DQUOTE *([FWS] qcon…
Sure. Fine. Skip that part then.
The larger point I was trying to make still stands.