EmailAddressAttribute allow dot on the end

Question

EmailAddressAttribute in .NET 4.6.1 allow dot on the end. That means that following email: [email protected]. is valid. For Microsoft this email is valid. But, for example, for PayPal, email is not valid.

So does anybody know, is dot on the end of email valid or not?

Answer 1

There is a lot of contending information about whether this is legal, or valid. Those are two different views, and I'm going to try and explain a bit why.

Email addresses are described in part by RFC 5322 - Internet Message Format which explains email formats in excruciating detail.

In section 3.4.1 - Addr-spec, the email address format is explained. I'm paraphrasing for brevity but the general format is:

local-part@domain

With local-name described as one of the following dot-atom / quoted-string / obs-local-part and domain described as dot-atom / domain-literal / obs-domain.

So it's a domain name, which is described in RFC 1034 - Domain Names - Concepts And Facilities.

A domain name can be ambiguous or unambiguous, which is defined by the absence or presence of the trailing dot. Ambiguous domain names are not guaranteed to resolve to a location, but most (if not all at this point) DNS search lists append a period behind the scenes if one is not present, but this is a Quality-of-Life improvement. Unambiguous domain names must contain a trailing period, it's basically a terminating character in DNS.

Thomas Flinkow already mentioned what the source looks like, I just wanted to give some context as to why - historically - the regex might be the way it is. A trailing period is legal, but validity is defined by the mail providers.

Answer 2

Well, since I did not find any documentation on that, I checked the source of the EmailAddressAttribute to see if any comments explained whether or not

[email protected].

is considered valid, but I did not find comments regarding that.

What I did find is this regular expression, which is used to determine whether or not an address is invalid:

^((([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|
[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|
[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*)|((\x22)((((\x20|\x09)*
(\x0d\x0a))?(\x20|\x09)+)?(([\x01-\x08\x0b\x0c\x0e-\x1f\x7f]|\x21|[\x23-\x5b]|
[\x5d-\x7e]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(\\([\x01-\x09
\x0b\x0c\x0d-\x7f]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]))))*(((\x20|\x09)*
(\x0d\x0a))?(\x20|\x09)+)?(\x22)))@((([a-z]|\d|
[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|\d|
[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|
[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|\d|
[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.)+(([a-z]|
[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|
[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|
[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|
[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.?$

which is obviously quite long. The interesting part however is this little part at the very end:

\.?

which means match between 0 and 1 "." characters.

Therefore I feel like it is intentionally built in that email addresses ending with a period are considered valid, although I have not found any external resources on whether email addresses ending with a period are actually allowed by any email providers.

For the validating, I would advise to not rely only on the EmailAddressAttribute, but to make your own validator (since EmailAddressAttribute is sealed and you can not derive your own attribute), which could look somewhat like this:

public bool IsValidEmailAddress(string email)
{
    var emailValidator = new EmailAddressAttribute();
    return emailValidator.IsValid(email) && !String.EndsWith(".");
}

In the code above, the attribute is used to provide the basic checking implementation, and !String.EndsWith(".") takes care of email addresses falsely determined as valid that have a trailing period.

---

TL;DR: The definite answer seems to be what Yannick Meeus has written:

A trailing period is legal, but validity is defined by the mail providers.

and therefore Microsoft seems to have conformed to the rules, even though in practice only few (none?) mail providers allow a trailing period. So you have to decide whether or not you also confirm to the formal rules and allow the trailing "." or if you want to exclude it (as demonstrated in the sample code above).