Laravel Disposable Email Laravel Package

Product Decisions This Supports

• Signup abuse mitigation (build vs. buy): Disposable email blocking is a narrow, well-defined capability. This package gives you a one-line Laravel validation rule (disposable_email) instead of an in-house blocklist service — a strong "buy/borrow" call for teams whose core product is not fraud detection.
• Trial, freemium, and promo abuse reduction: Prevents repeated free trials, referral-credit farming, coupon stacking, and poll/vote stuffing where attackers use throwaway inboxes. Tie adoption to metrics: fake-account rate, trial-to-paid conversion quality, support tickets from invalid emails, and downstream bounce rate.
• Lead and data quality gating: Useful anywhere an email is the identity key — newsletter capture, waitlists, gated content, partner/lead forms, tenant provisioning. Better data hygiene upstream reduces CRM cleanup and email deliverability damage later.
• Roadmap sequencing: Treat this as a Phase 1 hardening item, not a strategic feature. It is a low-effort abuse control you can ship alongside auth/onboarding work; larger investments (email verification, device fingerprinting, rate limiting, risk scoring) can be evaluated separately with real abuse data from this baseline.
• Scope decisions for onboarding UX: The package exposes a Blade helper (@disposableEmail) and detailed check API (source(), matchedDomain(), whitelisted()), which supports policy choices — hard block vs. soft warning vs. "allow but flag for review" — and lets you measure false positives before committing to a hard block.
• Operational roadmap item: The remote list sync (erag:sync-disposable-email-list) and caching are recurring jobs, not one-time setup. That is a standing maintenance cost to schedule (daily/weekly) and monitor (disposable:stats).
• Build vs. buy nuance: Building this yourself means curating and constantly refreshing a domain list — a low-value, never-ending chore. Buying a maintained list plus a Laravel-native integration is almost always cheaper than owning the data pipeline. The genuine build decision is the enforcement layer (risk scoring, review queue), not the list itself.
• Use cases to prioritize: consumer signups with free tiers, marketplaces (fake seller/buyer accounts), SaaS trials, surveys and contests, community/forum registration, and any flow where "one real human, one account" matters. Deprioritize B2B sales-led signups where disposable domains are rare but blocking a legitimate prospect is costly.
• Pricing/packaging input: If abuse controls are a differentiator for your tiering (e.g., enterprise anti-fraud), this package is a cheap substrate, but it is only table stakes — don't position it as a premium feature on its own.

When to Consider This Package

Adopt when:

• You are on a supported Laravel version (docs cover 10–13) and the abuse vector is specifically disposable/temporary inboxes at signup or form submission.
• You want a Laravel-native surface: a validation rule string, a rule object, a facade, a Blade conditional, config-driven whitelist and subdomain blocking — all fitting existing Form Request and validator patterns.
• Your team is small and would rather not own a blocklist refresh pipeline; MIT license and composer require remove procurement friction.
• You need per-project customization: custom .txt blacklists in storage/app/blacklist_file, a whitelist for trusted test/partner domains, block_subdomains, and optional caching for high-volume checks.
• You want the option to start soft (warn/log via Disposable::check()) and graduate to a hard validation block once false positives are understood.
• You have a place to schedule erag:sync-disposable-email-list and someone to watch disposable:stats and list staleness.

Look elsewhere (or build/gate) when:

• Maturity risk is unacceptable. ~283 stars, zero dependents, single-maintainer project, and no downstream ecosystem proof. That is a supply-chain and bus-factor concern for a payment-adjacent or regulated flow. Mitigation: wrap it behind your own interface (EmailRiskChecker) so it is replaceable in an afternoon, and pin versions.
• You need more than a domain list. Disposable detection does not verify the mailbox exists, catch aliasing/plus-addressing, catch human fraud rings, or score risk. If your abuse problem is bots, chargebacks, or account farms, this is one weak signal — pair with email verification (double opt-in/SMTP check), rate limiting, device/IP reputation, and CAPTCHA.
• False-positive cost is high. Legitimate users on privacy-forward domains, corporate catch-alls, or shared test infrastructure can be caught by broad lists. If your segment is privacy-sensitive or enterprise, blocking outright may cost more revenue than the abuse it prevents. Use the whitelist and a soft-block/review path.
• Non-Laravel or polyglot stack. The value here is the Laravel integration ergonomics; a plain domain-list lookup is trivially portable and probably shouldn't carry a framework dependency.
• You need an SLA, vendor support, or audited data provenance. There is no commercial backing here; if compliance requires a maintained vendor with contractual guarantees, choose a commercial email-verification/fraud API.
• You already have an ESP or identity vendor (e.g., verification or fraud provider) that bundles disposable detection — consolidating vendors may beat adding a second source of truth.
• Release cadence looks inconsistent. Latest release is dated 2026-10-08 — verify that against your own timeline before committing; a future/oddly-dated release should be checked (changelog, commit activity, open issues) as part of due diligence rather than assumed healthy.

How to Pitch It (Stakeholders)

For executives (30 seconds): "We're seeing fake accounts and repeated free-trial signups that cost us support time, credits, and email deliverability. This is a free, MIT-licensed, drop-in Laravel package that blocks known disposable email domains at registration with about one line of validation code. It's not a fraud platform — it's a cheap first layer. I recommend a two-week, low-risk pilot behind a feature flag, measured against fake-account rate and legitimate-signup rejection rate, with a go/no-go review before we make it a permanent block."

For engineering (what they actually do):

• composer require erag/laravel-disposable-email + php artisan erag:install-disposable-email, then add disposable_email to the email field in the relevant Form Requests. Facade (Disposable::email(), Disposable::check()) and Blade (@disposableEmail) are available for softer UX.
• Configure whitelist, block_subdomains, and cache_enabled/cache_ttl in config/disposable-email.php; add project-specific domains as .txt files in storage/app/blacklist_file.
• Schedule erag:sync-disposable-email-list (daily) via Laravel's scheduler; expose disposable:stats in ops dashboards for list freshness and cache status.
• Engineering guardrails we're asking for: wrap the package behind an internal EmailRiskChecker interface to avoid vendor lock-in; pin the version; cache lookups on high-traffic paths; log blocked attempts with the matched domain and source() for the first 30 days to quantify false positives; and instrument a kill switch so we can revert to warn-only without a deploy.

For support/ops: Expect a small bump in "my email was rejected" tickets in week one. Give the team the whitelist process and a scripted response; route disputed domains to the PM for a whitelist decision.

Decision requested: approve a timeboxed pilot with defined success metrics (fake-account rate down, <1% false-positive rate on legitimate signups). If those hold, promote to enforced validation and evaluate complementary controls (email verification, rate limiting) as a separate roadmap item.