Mail Storage Bundle Laravel Package

Product Decisions This Supports

• Email audit trail / "did we send that?" support workflow — the core value is persisting outbound mail so support and success teams can reconstruct what a customer actually received, when, and with what content. That's a recurring support cost line and a trust issue in disputes.
• Build vs. buy for transactional email logging — this is the decision this package most directly informs. Do we (a) adopt a small open-source bundle, (b) wire up a mailer event listener in-house (~1–2 days of engineering), or (c) buy a transactional email platform with built-in event retention (SendGrid/Mailgun/Postmark activity APIs or a logging SaaS)?
• Compliance and retention roadmap input — if legal or a customer contract requires an outbound-communication record (eDiscovery, regulated industries, contract disputes), an audit store becomes a scoped requirement rather than a nice-to-have. It shapes retention windows, PII handling, and deletion-on-request obligations under GDPR.
• Scope call on what gets stored — full MIME body and attachments vs. metadata only is a product decision with cost, privacy, and storage implications. Any storage tool forces that conversation early, which is useful.
• De-risking a legacy Symfony estate — worth flagging: despite the framing, this is a Symfony bundle, not a Laravel package. If the roadmap is Laravel-first, this is not a candidate at all, and that's a fast no.

When to Consider This Package

Consider it only when all of the following hold:

• The application is Symfony and still on the Swiftmailer mailer stack (the bundle predates and does not target Symfony Mailer). On a modern Symfony app, this is likely non-functional without a fork.
• You need a quick internal audit log, not a customer-facing feature, and metadata-plus-body storage is acceptable.
• You are prepared to vendor the code into your repo and own it. With zero stars, zero dependents, and no visible community, treat this as a code sample to copy, not a dependency to install.
• Volume is modest and you can tolerate the storage backend it offers without needing retention policies, encryption at rest, or multi-tenant partitioning out of the box.

Look elsewhere — or build — when:

• Any Laravel requirement exists. Wrong framework; not applicable.
• You need retention/deletion policy enforcement, PII redaction, encryption, or access controls on stored mail. These are compliance requirements, not enhancements, and shouldn't be bolted onto an unmaintained bundle.
• You want deliverability analytics (bounces, opens, complaints) — that's an ESP/event-webhook problem, not a storage bundle.
• You need scale or multi-tenancy; a single-vendor, near-zero-adoption bundle is a poor foundation.
• Your team cannot absorb long-term maintenance of an effectively unmaintained dependency. Security review of code that handles message bodies and attachments is non-trivial.

PM recommendation: do not adopt as a dependency. The honest comparison is "spike/copy the pattern" vs. "50–150 lines in-house listening to the mailer send event and persisting to our own table." The in-house option is usually cheaper over 12 months, is testable, and sits behind our own retention controls.

How to Pitch It (Stakeholders)

To executives: We evaluated a small open-source component for logging outbound email. It's free and MIT-licensed, but it's a Symfony-era tool with essentially no adoption (0 stars, 0 downstream users) and no maintainer activity — so it isn't a safe production dependency. The underlying need is real and cheap to meet: an outbound-email record cuts support time spent reconstructing "what did we actually send this customer" and gives us evidence in disputes. My recommendation is to not adopt the package and instead fund a small in-house implementation behind our own retention and privacy rules — roughly a few days of engineering, lower long-term risk, and it keeps us compliant with deletion requests. If the need turns out to be analytics (bounces, opens) rather than audit, that's a different buy: an email provider with event retention.

To engineering: treat nuxia/mail-storage-bundle as reference material, not a dependency. It's a Symfony bundle targeting the Swiftmailer stack — irrelevant if we're on Laravel or Symfony Mailer. If we want the capability, implement a listener on the mail-send event that persists message metadata plus body to our own store, with an explicit schema decision (metadata-only vs. full MIME + attachments), redaction rules, and a retention job. That gives us testability, a clear owner, and no supply-chain exposure to an unmaintained package.