Product Decisions This Supports
- Multi-account abuse prevention. Gmail ignores dots in the local part and everything after a
+, so john.doe@, johndoe@, and john.doe+promo@ are one inbox. This package canonicalizes the address so you can make an explicit product call — block, flag, or allow — instead of silently treating aliases as distinct users.
- Trial, credit, and promo integrity. Supports decisions about whether free trials, signup credits, referral bonuses, and promo codes are per-account or per-person. If the answer is "per-person," this is the cheapest available enforcement for the Gmail portion of your base.
- Referral loop policy. Self-referral through dot/plus aliases is a first-order fraud pattern. Canonical-form checks let you set a rule (reject, void the reward, or queue for review) as a product policy rather than a reactive fraud investigation.
- Registration identity uniqueness. A concrete build-vs-buy input for "one account per person" versus "one account per email string." It lets you ship the former without designing an identity graph.
- Data hygiene and backfill. Enables auditing existing accounts for alias clusters resolving to the same inbox — useful ahead of a pricing change, plan migration, or abuse cleanup.
- Scope control as a feature. It makes one narrow, auditable claim (Gmail canonicalization). That keeps the decision small and reversible instead of pulling the team into a full identity-verification roadmap. It does not address disposable domains, deliverability, or domain reputation — keep those separate.
When to Consider This Package
Adopt when:
- You're on PHP/Laravel and the signup path can call a normalizer before persistence.
- Your user base is consumer-skewed and Gmail is a material share of registrations.
- You have a per-person incentive — trial, credits, referral, promo, free-tier limits — worth protecting from trivial alias multiplication.
- You want a small, MIT-licensed, single-purpose dependency you can read in one sitting, vendor, or fork, versus a heavyweight fraud vendor.
- You already store the raw address for delivery and are adding a canonical column rather than replacing it.
Look elsewhere / don't adopt when:
- Auth is delegated to an identity provider (Auth0, Clerk, Cognito, Google Sign-In) and you don't control the email-of-record pipeline — confirm whether the provider already normalizes.
- Multi-accounting isn't economically interesting to attackers; you'd inherit a policy you then must maintain everywhere.
- You need disposable-email detection or deliverability checks — different problem, different tool.
- You want canonicalization across arbitrary providers. Dots are significant at most domains; applying Gmail rules globally will merge legitimate distinct users. Restrict to
gmail.com/googlemail.com, and treat custom Google Workspace domains as a separate judgment call.
- Your flow surfaces a hard "already registered" error without care — canonical checks can widen account enumeration or make users feel locked out of their own alias. Consider flagging for review over hard-blocking in sensitive flows.
- Single-maintainer risk is unacceptable on a critical path — though at this size the mitigation is "vendor the normalizer," not "find a bigger dependency."
Implementation caveats worth a PM's attention: store both raw and canonical (send to raw, index uniqueness on canonical); decide explicitly whether login, password reset, invites, and support lookups also use the canonical form — inconsistency is where abuse returns and support tickets come from; revisit if Gmail changes semantics, which a one-function dependency makes cheap.
How to Pitch It (Stakeholders)
To executives: A small, free, MIT-licensed utility that closes a cheap and common abuse channel — users stretching trials, credits, and referral bonuses by re-registering the same Gmail inbox with added dots or a +tag — at roughly the cost of one function call in the signup path. No vendor contract, no new data store, no identity roadmap.
The value: Every per-person incentive in the product is only as strong as the weakest identity check. For a meaningful slice of a consumer base, this closes the cheapest loophole first. It's low-cost, reversible, and straightforward to test against simulated abuse.
To engineering: One normalizer, applied at the boundary. Persist the raw address for delivery and the canonical form for uniqueness and lookups; scope it to Gmail domains only and do not generalize dot-stripping to other providers. Propagate the rule to login, reset, and invites so it's one policy rather than one endpoint. Small enough to read, vendor, or fork if we ever want to drop the dependency.
The honest caveat: This is not a fraud platform. It's one rule, done correctly, for one provider — real protection against casual abuse, not a determined attacker, and only worth it if we also decide what happens when a collision is detected: block, flag, or review.