Discrepancies between isValid and normalizeEmail

[rathboma]

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?

Extend isEmail?

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.

[chriso]

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)?

[tux-tn]

@chriso i want to work on this issue but i have some questions:

• [email protected] is not working because normalizeEmail is considering it as a subaddress, should we return [email protected] or return false/null in that case?
• Should we check for Email providers limitations in normalizeEmail and isEmail, for example gmail is limiting the local part of the address to a minimum of 6 characters and a maximum of 30 character and the first character needs to be alphabetic.
• Many RFC 5322 compliant email addresses cannont be used in gmail/yahoo/.. Should we remove invalid characters like $ or % ?

[chriso]

@tux-tn [email protected] is an invalid gmail address. I think we should add domain-specific validation given how ubiquitous gmail addresses are.

[twelve17]

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.