The validation for yup.string().email() allows an invalid email such as [email protected] to be marked as valid.
Yup version 0.26.10
Is there an ETA to get this fix into the next version?
It's unlikely to make it into a release. MY option generally for email validation is that we should make it less strict. the only way to properly validate an email address is to send an email to it. More robust regex approaches, always create false positives and false negatives.
ref: https://github.com/jquense/yup/issues/386#issuecomment-450428912
@jquense, I agree that a single regex cannot cater for all variations in email addresses. However, in this scenario, the part of the email address after the @ is well defined by the RFC spec to require a valid Internet Domain Name.
Given the specification is clear that a domain cannot have two . appearing next to each other, this rule can be added to yup base email regex.
Resources for further reading:
On Twitter, for instance, the example above [email protected] is invalid

I've tried another doubtful email format on Yup - [email protected]- and unfortunately string().email() also say is valid :( This is the result on Twitter:

When I use an empty string or undefined (e.g: const email = "") to yup.string().email() it gets validated, shouldn't it return a fail in email validation?
Yup version: 0.27.0
Browser: Chromium 76.0.3809.100
OS: Ubuntu 18.04
I copied the regex in v. 0.28.0, put it through a regex tester here. It looks like double periods don't match so my first question is has this been dealt with?
Secondly, while we're at it, shouldn't we also limit the amount of chars for an email? before the @ and after. Got a bit confused by this this discussion on stack overflow, would be cool to implement it with the right standard length.
@EyalTAnyvision, no, this has not been fixed because the problem is not in the domain part, i.e. .com but in the subdomain, i.e. .com..au. I think a length limit is definitely a good idea.
I've opened a new PR for this https://github.com/jquense/yup/pull/751. This includes the length constraints as suggested by @YashdalfTheGray.
Awesome!
On Fri, Jan 17, 2020, 05:58 Tri Q. Tran notifications@github.com wrote:
I've opened a new PR for this #751
https://github.com/jquense/yup/pull/751—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jquense/yup/issues/507?email_source=notifications&email_token=ALI2BIKGCEYK3APWFII66GTQ6EUHXA5CNFSM4HB4YEU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJGLWQA#issuecomment-575454016,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALI2BIP2TC5RV5QIL4Y5IZDQ6EUHXANCNFSM4HB4YEUQ
.
I just did Yup.string().matches() and use another email regex:
/^(([^<>()\[\]\\.,;:\s@"]+(\.[^<>()\[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/
Most helpful comment
It's unlikely to make it into a release. MY option generally for email validation is that we should make it less strict. the only way to properly validate an email address is to send an email to it. More robust regex approaches, always create false positives and false negatives.
ref: https://github.com/jquense/yup/issues/386#issuecomment-450428912