Discrepancies between isValid and normalizeEmail

[rathboma]

So there are situations where isEmail will return true, but normalizeEmail will return false.

For example:

+123456789@gmail.com -> 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 +123456789@gmail.com 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 +123456789@example.com is even valid (in the general case)?

[tux-tn]

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

• +123456789@gmail.com is not working because normalizeEmail is considering it as a subaddress, should we return 123456789@gmail.com 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 +123456789@gmail.com 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.