Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Email Validation behaviour #1895

Closed
JeremySkinner opened this issue Feb 10, 2022 · 0 comments
Closed

Email Validation behaviour #1895

JeremySkinner opened this issue Feb 10, 2022 · 0 comments

Comments

@JeremySkinner
Copy link
Member

A common bug report that we receive is that that the email validator doesn't work correctly, and identifies something as a valid email address when it shouldn't.

This is not a bug and is the correct/intentional behaviour.

The email validator is intentionally naive, and uses the same logic as ASP.NET Core's default [EmailAddress] attribute for consistency, which is just to perform a simple check that a string contains an "@" character. This is explained in our email validator documentation here: https://docs.fluentvalidation.net/en/latest/built-in-validators.html#email-validator

It is also mentioned in the 9.x upgrade guide, when we switched from a regex to using the simple check:
https://docs.fluentvalidation.net/en/latest/upgrading-to-9.html#default-email-validation-mode-changed

This discussion may also be of interest as to why trying to build comprehensive email validation regex is the wrong approach: https://www.reddit.com/r/csharp/comments/hlzpwn/why_is_emailaddress_attribute_validating_as_true/ (TLDR; the best way to validate email addresses by sending a verification email to the address. At the UI-level just perform a simple/basic check).

@JeremySkinner JeremySkinner pinned this issue Feb 10, 2022
@FluentValidation FluentValidation locked as resolved and limited conversation to collaborators Feb 10, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant