assuming your websites has a sign-up and you provide some free credit/usage for each new sign ups.<p>In gmail and GSuite accounts (not sure if other email services does the same) you can do the +1 trick.<p>Add +N after your username and receive the email in the same sandbox (which is actually useful in many cases).<p>The point is, knowing that, do you consider<p>user@gmail
user+1@gmail
user+2@gmail
user+3@gmail
user+4@gmail
user+5@gmail<p>as 6 different and unrelated accounts in your db?<p>it is fair to _regex_ the email and remove the +1 trick?
What is the value of the resource you're providing with each signup? Running a regex is only worth it if you're offering value that you have to pay for, like a free tshirt or some paid compute credits. And even then, it's only a problem if you have insufficient cash to cover the abuse.<p>If however you're offering LOW COST items (ex: digital goods, or a free month of your SAAS), then absolutely do not filter these. Search for them afterward and contact them. These are some of your most valuable users: people who are willing to put up with the pain of creating new logins over and over again just to use your service. Find out what they love. Find out what it would take for them to start paying. They can provide intelligence far in excess of the free service credits you're providing.
You should always treat that case as distinct email addresses.<p>If you have problems with one person signing up multiple times then this won't fix it for you. There are many other ways a person can have lots of email addresses. You will waste a lot of time chasing your tail.<p>I reasonably use plus style addresses to establish different identities and I generally pass on a website if their registration or other processes assumes things about my address or disallow valid characters in an email address.<p>I also don't try and rip-off a website by abusing their free services.
You should treat them as unique, Google is not the only e-mail provider.<p>You can use that knowledge in constructing your anti-spam heuristics though.
A plus sign is allowed in the user part of email addresses. Though it's most commonly used as a tag (and I've only seen it used that way) it could be used as an actual address and since the receiving mail server decides how to handle it you have no way of knowing.<p>If you choose to strip the tag I'd only do so when processing a new signup and make sure that the user can login with his user+tag@example.com and that all email goes to that address.
The best solution to this problem I heard was to along these lines:<p>* have a separation between accounts and users. Account is the entity that pays for the service. Usually account has users associated.<p>* collect payment/credit card information on account creation<p>This way, you don't really care about user+1, because you have their payment info already, and can assume at least some intention to pay after their free tier is up.<p>There are many legitimate reasons why somebody while doing evaluation would create several users, i.e. I do name@a.com as well as name+testing@a.com in few services.<p>If you find out that too many of your customers are not willing to pay, look at it more as a business problem, trying to reach better customers that you can charge more, rather than to better enforce some account de-duplication.<p>I think I heard this approach from patio11, Amy Hoy or some interview on Mixergy?
This is one of my favorite tricks for testing web apps. The only downside is getting your inbox blown up when the company runs an email blast, but it's nothing a filter can't catch.<p>I think these patterns are generally negative for most ecommerce companies (you've priced too low, you're signing up tons of low-LTV customers at huge CPA, etc.) and good for SaaS companies that can solicit feedback or otherwise monetize their "frequent triers".
In GSuite it's also possible to redirect all unmatched addresses to some email address, e.g., invalid1@a.com, invalid2@a.com all go to valid@a.com<p>You should consider asking phone verification, or keep a credit card of file.