So there are situations where isEmail will return true, but normalizeEmail will return false.
For example:
[email protected] -> isEmail returns true, normalizeEmail returns false.
Really this comes down to a behavior that I think the library should enforce:
If isEmail returns true, normalizeEmail should be able to return a value
Currently normalizeEmail can return false, which seems wrong. It feels like if normalizeEmail can't do what it needs to it should return the original string or null?
Currently normalizeEmail is actually doing domain-specific email validation as well as normalizing the email. For example [email protected] is syntactically valid, but invalid for gmail. Maybe isEmail should also be extended to contain this domain-specific logic to bring it into line with what normalizeEmail is doing.
Agreed, this is confusing behavior of normalizeEmail(). It should always succeed, provided the input email is valid. It should be isEmail() that rejects those particular emails (starting with +). We could add domain-specific validation to isEmail(), but I wonder if [email protected] is even valid (in the general case)?
@chriso i want to work on this issue but i have some questions:
@tux-tn [email protected] is an invalid gmail address. I think we should add domain-specific validation given how ubiquitous gmail addresses are.
According to this post, there are gmail addresses out in the wild that have a username part less than six characters. It's an edge case, but it's possible we ran into one of these today, and now I am faced with having to disable email validation altogether because it is trying to be too clever.
Most helpful comment
According to this post, there are gmail addresses out in the wild that have a username part less than six characters. It's an edge case, but it's possible we ran into one of these today, and now I am faced with having to disable email validation altogether because it is trying to be too clever.