Swiftmailer Bundle Laravel Package

Product Decisions This Supports

• Roadmap / technical-debt triage: retire Swiftmailer, standardize on Symfony Mailer — unchanged. v3.6.0 is a single change ("Allow symfony 6 packages"), merged as PR #1 — the fork's first and only pull request. It relaxes Composer constraints; it does not change the underlying fact that swiftmailer/swiftmailer is end-of-life and receives no security fixes. This package remains a decision input — evidence that a service is running an EOL email stack — not a candidate dependency.
• Build vs. buy: buy the supported thing. The "buy" answer is symfony/mailer plus a provider bridge (SES, Postmark, Sendinblue, etc.). Building an in-house mailer abstraction is not justified; forking or pinning this package is worse than either option.
• Vendor and supply-chain risk assessment. v3.6.0 is a one-commit, one-contributor constraint relaxation with no evidence of tests, CI, release cadence, or a maintenance commitment. For a security review or SOC 2 vendor inventory this remains a "no viable upstream" finding, not an approved component. Flag explicitly that SBOM and "last updated" heuristics will now show a recent release — do not let that clear a review.
• Migration scoping and sequencing. Identify which services pin kunstmaan/swiftmailer-bundle (likely inherited from the Kunstmaan CMS bundle set), map their transports and templating (Swift_Message, Twig mailer usage), and sequence the swap to symfony/mailer + symfony/mime.
• Framework upgrade gating — revised. Previously this package was a hard Composer blocker for Symfony 6. v3.6.0 removes that dependency-resolution blocker, which is arguably a worse planning position: a loud install failure becomes a silent runtime liability on an unmaintained mail stack. Gate the migration explicitly on the Symfony 6/7 roadmap rather than relying on Composer to force it. Symfony 7 remains out of scope.
• Reference-only use case. Engineering may read the source to understand Kunstmaan's historical overrides when porting behavior to Mailer. That is a one-afternoon read, not a dependency decision.
• Ignore automated "opportunity" and "freshness" scores. Neither novelty heuristics nor a new release date reflect fitness; the EOL upstream and single-commit release history dominate any real evaluation.

When to Consider This Package

Consider it only under narrow, time-boxed conditions:

• You are running a Kunstmaan CMS/Symfony application already pinned to Swiftmailer, on Symfony 4.4/5.x, and a same-week hotfix needs the bundle's exact service wiring to keep mail flowing.
• You need byte-for-byte behavioral parity during an incremental migration and want to diff this fork against upstream symfony/swiftmailer-bundle to understand Kunstmaan's customizations.
• You are doing archaeology on a legacy app you inherited and need to explain why certain swiftmailer: config keys exist.

Look elsewhere — decisively — when:

• Any new build or greenfield service. Start on symfony/mailer.
• You need security patches or CVE response. Upstream Swiftmailer is EOL; this fork adds no security capacity. Assume no fixes ever.
• You target PHP 8.1+ or Symfony 6/7. v3.6.0 relaxes Composer constraints for Symfony 6, but the underlying library is not a supported path. Installability is not support.
• You need async/queue-based sending, DKIM signing, webhook/bounce handling, or observability hooks. Symfony Mailer plus a provider bridge covers these; this bundle does not.
• You require vendor support, an SLA, or a documented maintenance commitment. None exists; one merged community PR is not a commitment.
• Your delivery requirements are non-trivial (multi-tenant sending domains, per-tenant reputation isolation, compliance-grade audit of outbound mail) — the abstraction you want is a thin internal mail interface over Mailer, not a bundle.

Adoption checklist if you must touch it: pin the exact commit, add it to the security-exception register with an owner and removal date, and require the migration ticket to be opened in the same sprint. Do not accept v3.6.0 as a reason to defer that ticket.

How to Pitch It (Stakeholders)

Bottom line: do not adopt. Migrate off Swiftmailer to Symfony Mailer, and treat any remaining dependency on this bundle as technical debt with a dated removal plan. The v3.6.0 release only loosens Symfony version constraints; it does not restore maintenance of the underlying mail library.

For executives: the new release may look like a sign of life, but it is a single compatibility patch from a single contributor on a fork whose upstream library has been end-of-life and unpatched for years. Email is a customer-facing, revenue-adjacent path — password resets, receipts, notifications — so an unpatched mail stack is a continuity and compliance risk, not just a code-cleanliness issue. The fix remains a well-trodden migration to Symfony's supported Mailer component: engineering days, no license spend, and it removes both a predictable security-review finding and a future upgrade obstacle.

For engineering: symfony/mailer + symfony/mime is the direct successor. v3.6.0 means Composer will now let you install this bundle on Symfony 6 — treat that as a trap, not a bridge. Expect the work to concentrate in transport configuration, message construction (Swift_Message → Email), and Twig/queue integration; most call sites translate mechanically. Do the migration before, not during, a Symfony major upgrade, so the two changes don't compound.

For the security/compliance reviewer: keep the package on the disallowed-components list, with an exception process for legacy services that still reference it, each carrying an owner and a removal date. Scanner dashboards will now show a recent release for this package; document that v3.6.0 is a constraints-only patch and should not reset the risk rating, the review clock, or the removal deadline.