Mail Extra Bundle Laravel Package

Product Decisions This Supports

• Feature decision — "safe mail" in non-production environments. The persistent need behind this bundle is preventing a staging/demo/QA environment from emailing real customers. Typical capabilities: redirect all outbound mail to a single sink inbox, globally disable delivery, prefix subjects with the environment name, and log what would have been sent. Treat this as a launch-readiness / compliance checklist item, not a nice-to-have: one misconfigured cron job on a staging box that shares production data is a customer-trust incident.
• Build vs. buy — the answer here is "neither." The package scores 0.22 on viability (6 stars, 0 dependents, last release Dec 2015) while the underlying opportunity scores 0.8. That gap is the decision: the problem is evergreen, the implementation is obsolete. Build the capability in-house (~a day of engineering) and use this repo only as a reference implementation / pattern source, not a dependency.
• Roadmap / tech-debt input. If any legacy Symfony 2/3 service still runs swiftmailer-bundle, this bundle is a signal that (a) those services need a mail-stack migration to Symfony Mailer, and (b) the redirect/disable logic must be re-implemented, not ported. Slot it into the platform modernization epic rather than the feature backlog.
• Stack decision — framework fit. Despite being filed as a "Laravel/PHP package," this is a Symfony bundle for Swift Mailer with no Laravel integration. It should not influence Laravel mail architecture at all; its presence in an evaluation list is a metadata error, and that's worth correcting so it doesn't pollute future buy-vs-build comparisons.
• Use cases it validates for our own spec: staging QA with production-like data; sales demos; load/soak tests that trigger notification paths; onboarding new engineers who run the app locally; any environment where a queue worker replays real jobs.

When to Consider This Package

Adopt only if all of the following are true:

• You are on Symfony 2.x/3.x with Swift Mailer and already committed to symfony/swiftmailer-bundle.
• You cannot touch framework config — i.e., you need the redirect/disable behavior as a decorator around an existing Swift_Mailer service rather than via configuration.
• You have accepted that you are vendoring a 2015, unmaintained, near-zero-adoption library, and your security process explicitly allows unpatchable transitive dependencies.
• You have verified it doesn't duplicate something already free in the framework.

Look elsewhere — i.e., in almost every other case:

• Laravel: you do not need this. Use MAIL_MAILER=log|array, Mailpit/MailHog locally, Mail::fake() in tests, and Mail::alwaysTo() for a global redirect. Zero dependencies, first-party, maintained.
• Symfony 4.4+ / 5 / 6 / 7: use Symfony Mailer with an event listener/subscriber on MessageEvent to rewrite the envelope, plus framework.mailer.dsn and disable_delivery. The WebProfiler mailer panel already covers the "see what would be sent" need.
• The framework already covers most of it. Symfony's swiftmailer.disable_delivery and the profiler's mailer interception existed alongside this bundle; if the only thing you want is "don't send," the bundle is redundant.
• Any team without spare capacity for abandoned code. 6 stars and 0 dependents means no community, no security advisories, no CVE response, and no one to ask when it breaks on a PHP upgrade.
• Swift Mailer itself is EOL (deprecated in favor of Symfony Mailer). Adding a wrapper around a dead transport couples you to a second dead thing.

Adoption cost if you proceed anyway: trivial install, but an ongoing tax — an unmaintained package pinned in composer.json, a blocker on the PHP/Symfony upgrade path, and an explicit exception in your dependency policy.

How to Pitch It (Stakeholders)

For executives (30 seconds): We evaluated a library that stops non-production environments from emailing real customers — a real risk with real reputational cost, and one we should close. The library itself is not adoptable: it was last released in 2015, has six stars, no downstream users, and wraps Swift Mailer, which the PHP ecosystem has retired. Recommendation: do not add the dependency. The same protection is roughly one engineering day using first-party framework features (Symfony Mailer event listeners; Laravel's mail redirect and log drivers). We get the risk reduction with no supply-chain exposure and no upgrade blocker. I'd like the "safe mail" guardrail added to the pre-launch checklist for every environment.

For engineering (the ask): Read rezzza/MailExtraBundle as a spec, not as a dependency. Our implementation should mirror its intent — a mailer decorator that (1) rewrites all recipients to a configured sink address outside production, (2) supports an explicit disable_delivery toggle, (3) prefixes subjects with the environment, and (4) logs the original recipients for debugging. On Symfony, wire it as a MessageEvent listener on the Mailer component; on Laravel, a Mail::alwaysTo() call plus driver config. Ship it as shared platform config so no product team has to think about it again, and add a test asserting that a production-like config with a non-production environment variable cannot deliver to a real domain.