I don't agree with the comment outright stating that you shouldn't strip out the "filters" (e.g. user_email+some_filter_to_flag_incoming_messages
@example.org). "Your use cases aren't the same as my use cases" and so on.[0]
tl;dr: The regex pattern you're looking for is: '(\+.*)(?=\@)'
Explanation:
To start, write a regex that matches the literal '+' sign and any single character, any number of times:
'(\+.*)'
When replacing this pattern with an empty string, this will turn [email protected]
into tristan
. If you decide to split on the @ symbol, congrats, concat the resulting string to '@' + domain.TLD to this and you're done. I mention this in case you've already split the e-mail address and it's just hanging around anyway.
If you're not splitting the user-email address on the @ symbol, you need to use a "positive look-ahead" (match this pattern if it's proceeded by this thing I specify) to tell your match when to stop (so we don't take away too much):
'(\+.*)(?=\@)'
with this in place, we get [email protected]
. Hooray, that wasn't actually so rough.
[0]: In one of my applications, I store the original filter-containing e-mail address that users give me for communications, but track filter usage and consider the canonical account (referenced-internally) to be the version without the filter (e.g. [email protected]). I do this to make it easier for users that opt-in to be located by e-mail address to search for each other.
I understand why people use aliases/filters:
- they give the illusion that they can be used to track spammers (as if an e-mail harvester wouldn't remove the filter before selling a list)
- they're useful in routing emails or triggering events (e.g. sending a text when you get an e-mail from [email protected])
- the "omg i can do this?" factor
Which is all to say, "I get it, people like filters," but there's valid reasons as an application author or a company to make note of them.
+
in their username. – Communicate