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

EmailAddressAttribute accepts invalid email address #4923

Closed
davidbutt opened this Issue Dec 10, 2015 · 7 comments

Comments

Projects
None yet
8 participants
@davidbutt
Copy link

davidbutt commented Dec 10, 2015

The following email address is accepted as valid by the EmailAddressAttribute:

a@aa.aa.

Note the trailing dot. This is an invalid address.

This only works if there is already a dot earlier in the address (as above).

@davidsh

This comment has been minimized.

Copy link
Member

davidsh commented Dec 10, 2015

Are you talking about the System.ComponentModel.DataAnnotations.EmailAddressAttribute class?

@stephentoub

This comment has been minimized.

Copy link
Member

stephentoub commented Dec 10, 2015

cc: @lajones

@lajones

This comment has been minimized.

Copy link
Contributor

lajones commented Dec 10, 2015

cc: @Eilon, @divega We had earlier decided that the purpose of EmailAddressAttribute was just to prevent "fat-fingering" errors - not to prevent every possible invalid email address. The algorithm we currently use is "must have at least one '@' and the '@' cannot be at the start or the end." The above passes that test (along with many other potential errors). Suggest we don't fix this, but feel free to chime in.

@Eilon

This comment has been minimized.

Copy link
Member

Eilon commented Dec 10, 2015

@lajones yup that's totally how I look at this. The value of parsing an RFC-valid email address is close to zero for me.

@lajones

This comment has been minimized.

Copy link
Contributor

lajones commented Dec 10, 2015

Closing as "By Design" then.

@lajones lajones closed this Dec 10, 2015

@divega

This comment has been minimized.

Copy link
Member

divega commented Dec 10, 2015

👍 The main scenario for the attribute is the validation of existing email addresses (as opposed to creating new email addresses). There are added costs and diminishing returns in trying to improve the validation to get closer to any standard. And ultimately even an email address that complies perfectly to those RFCs will still not be a valid email address if it doesn't exist.

@bassem-mf

This comment has been minimized.

Copy link

bassem-mf commented Nov 30, 2018

cc: @Eilon, @divega We had earlier decided that the purpose of EmailAddressAttribute was just to prevent "fat-fingering" errors - not to prevent every possible invalid email address. The algorithm we currently use is "must have at least one '@' and the '@' cannot be at the start or the end." The above passes that test (along with many other potential errors). Suggest we don't fix this, but feel free to chime in.

In my opinion this is not a good way to validate emails. The old Regex-based logic was much better at catching errors.

I am responsible for the development of a CRM software that has about a 1000 active users. Our software validates email addresses in 2 different layers: (1) the Web app layer using EmailAddressAttribute and (2) a lower layer using a Regex.

Since we updated the .Net version and EmailAddressAttribute switched to the new behavior, I see that the regular expression validation in the lower layer catches 5 to 10 invalid emails every day. And when I look at these invalid emails, they are clearly data entry mistakes by users. A lot of them look like that "someuser@gmail" and they forget to type ".com" at the end. These are errors that can be caught by a more advanced validation strategy.

I believe that the old Regex-based EmailAddressAtttribute was much more useful than the new one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment