Runtime: EmailAddressAttribute accepts invalid email address

Created on 10 Dec 2015  路  7Comments  路  Source: dotnet/runtime

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

[email protected].

Note the trailing dot. This is an invalid address.

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

Most helpful comment

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.

All 7 comments

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

cc: @lajones

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.

@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.

Closing as "By Design" then.

:+1: 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.

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

sahithreddyk picture sahithreddyk  路  3Comments

chunseoklee picture chunseoklee  路  3Comments

matty-hall picture matty-hall  路  3Comments

bencz picture bencz  路  3Comments

nalywa picture nalywa  路  3Comments