Mail Extra Bundle Laravel Package

Getting Started

Before anything else: this is a Symfony bundle, not a Laravel package. It wraps Swift_Mailer with plugins (redirect, logging, no-delivery) and a small email-validation helper. Last release was 2015 and SwiftMailer reached end-of-life in 2021, so in a modern Laravel app you will almost never install it directly — you'll either run it inside a legacy Symfony 2/3 service, or copy the patterns into Laravel's Mail facade / Symfony Mailer. Treat this assessment as "how to use it where it still runs, and what to replicate elsewhere."

Minimal steps for a legacy Symfony app:

1. composer require rezzza/mail-extra-bundle (pin to the 2015 tag; it expects Symfony 2.x/3.x and SwiftMailer 5.x).
2. Register new Rezzza\MailExtraBundle\RezzzaMailExtraBundle() in AppKernel.
3. Enable the features you actually need in config.yml — typically redirect + logger in dev/staging, no-delivery in test:

# config_dev.yml
rezzza_mail_extra:
    redirect:
        enabled: true
        to: [email protected]
    logger:
        enabled: true
        file: "%kernel.logs_dir%/mail.log"

4. Inject the bundle's decorated mailer service (not the raw mailer) wherever mail is sent.

Where to look first: DependencyInjection/Configuration.php (the real, authoritative config reference), Resources/config/services.xml (service ids and which Swift_Plugins_* get wired), then the README — README and code drift on a package this old.

First use case: kill accidental customer email from staging. Enable the redirect plugin, point at a shared inbox, and enable the logger so you can confirm what would have gone out and to whom.

Implementation Patterns

Environment-scoped redirect. The highest-value use is a redirecting plugin that rewrites every To/Cc/Bcc to a safe address while preserving the original recipients in a header (Swift's Swift_Plugins_RedirectingPlugin does this). Drive it per-environment so production is untouched:

# config_prod.yml
rezzza_mail_extra:
    redirect: { enabled: false }

Whitelist instead of blanket redirect. If your team still needs real delivery to internal domains, configure the redirect plugin's recipient allow-list rather than redirecting everything — otherwise QA can't test real inbox rendering.

No-delivery for tests. In the test environment, enable no-delivery so send() is a no-op but the transport call path still executes. Assert on the logger output or a Swift_Events_SendListener rather than on the transport.

Always send through the decorated service. The plugins only apply to mail sent via the bundle's wrapper. Any code that grabs swiftmailer.mailer directly bypasses redirect/logging. Audit with grep -r "swiftmailer.mailer" and replace with the wrapper service id.

Logging as a verification loop. The logger plugin appends each message (headers + body) to a file. Use it as a poor-man's mail catcher: tail -f var/logs/mail.log while clicking through a flow tells you exactly what the app tried to send — useful when a spool or transport silently drops messages.

Validation before send. For user-supplied recipient addresses, run the bundle's email validator (or Symfony's Email constraint with checkMX) before queueing. The bundle's disposable/free-provider checks are list-based and stale — use them as a soft signal for signup forms, never as an authorization control.

Custom plugin for metrics. Extension point is Swift's own plugin system: implement Swift_Events_SendListener, register it on the decorated mailer, and emit counters (sent, redirected, failed). This is a cleaner long-term investment than the bundle's file logger.

Porting the pattern to Laravel (the realistic path). Don't install the bundle — replicate:

• Redirect: Mail::alwaysTo('[email protected]') in a non-production service provider.
• Logging: a MessageSending/MessageSent event listener, or log mailer driver.
• No-delivery: MAIL_MAILER=log or array in phpunit.xml.
• Validation: Validator::make(['email' => $addr], ['email' => 'email:rfc,dns']).

Gotchas and Tips

• Compatibility cliff. PSR-0 autoloading, Symfony 2/3 bundle conventions, and Swift_* class references mean it will not boot on Symfony 4+ without a fork, and it has no relationship to Laravel's Symfony Mailer stack. Assume "read the source, port the idea" rather than "composer require".
• Plugin ordering matters. Redirect before logger gives you logs of the rewritten message; logger before redirect gives you the original recipients. Decide which you need for auditing.
• Spool interaction. If mail is spooled, plugins fire at send() time but the transport runs later via swiftmailer:spool:send. A no-delivery or redirect plugin wired only into the web request path will not cover the spool consumer — verify the same decorator is used in the console/worker context.
• CLI and queue paths bypass the web container config. Symfony environment config is per-kernel; a worker booted in prod won't pick up config_dev.yml redirects even if it's "a dev machine." Set the environment explicitly on worker commands.
• Logger leaks PII. Bodies, reset links, and attachments land in plaintext files. Rotate, gitignore, and never enable in production without a retention policy.
• Config key drift. On a 2015 bundle the README often documents keys that were renamed or removed. Trust Configuration.php over the docs; run config:dump-reference rezzza_mail_extra in Symfony to see what's actually accepted.
• Redirect doesn't rewrite headers. Original recipients often survive in X-Swift-To/X-Swift-Cc headers — useful for debugging, but don't forward those messages outside the team.
• Validation is best-effort. MX/disposable checks are inherently flaky and the bundled lists are frozen at 2015. Wrap in a timeout and fall back to "allow" rather than blocking sends when DNS is unavailable.
• Extension point is Swift, not the bundle. If you need behavior the bundle doesn't offer, write a Swift_Events_* plugin and register it on the decorated mailer; don't fork the bundle.
• Debugging checklist: confirm which service id is injected → confirm the plugin is registered on that exact Swift_Mailer instance → confirm the message actually calls send() (not send() via a different mailer) → confirm the environment config was loaded. Most "it isn't redirecting" bugs are the first two.