I imagine the challenge is knowing what parsing rules apply to which domains. Gmail supports the + thing, but that's non-standard. Is that something you tried to handle in a general way?
> Gmail supports the + thing, but that's non-standard
Plusaddressing is valid and has been since 1982[1]. It's part of RFC822 and the subsequent RFC2822.
The fact that many websites do not allow + in an email address during validation is a common programming mistake and the sign of an undertrained engineer.
> The fact that many websites do not allow + in an email address during validation is a common programming mistake and the sign of an undertrained engineer.
But the RFC from what I can recall is _wild_. I can't find the part so maybe I am mixing something else up, but I believe you can embed comments into an email address.
All I am saying is that the possible scope of valid email addresses is likely so large, trying to write a parser for them is a sign of an underexperienced team rather than not having one at all.
Sorry, I should have been clearer. Gmail will place messages for user@gmail.com and user+foo@gmail.com in the same mailbox. The grandparent comment talks about normalizing the address by removing stuff after the +. This sort of deduplicates the addresses. Other platforms may have distinct mailboxes for user and user+foo, so you can't strip it on those platforms. The mapping of user+foo to user is non-standard.
There won't be a general approach to deduplicating addresses that map to the same mailbox as the mapping rules aren't always public. But for Gmail, the rule is public, so a best effort deduplication could strip the +.
