Vmail Bundle Laravel Package

Product Decisions This Supports

• Whether email hosting is a product surface or a commodity. The package encodes the "own the mailbox database" model: Postfix is configured with virtual_mailbox_domains / virtual_mailbox_maps / virtual_alias_maps backed by SQL tables that your application owns and writes to. Choosing this shape is a roadmap decision — it means your app becomes the source of truth for domains, mailboxes, quotas, and aliases, and your on-call rotation inherits mail delivery.
• Build vs. buy for multi-tenant mailbox provisioning. If a feature request is "let customers add @theirdomain.com mailboxes and aliases," this package is one candidate implementation of the CRUD + schema layer. It is a reference architecture, not a dependency: it demonstrates the minimal table set (domains, mailboxes, aliases) and the Postfix lookup contract you would need to satisfy either way.
• Data-model ownership. It forces an explicit call: do you own an identity/mailbox schema in your own DB (portable, but you maintain it), or delegate to an external provider's API (less control, but someone else owns deliverability and abuse)? That answer propagates into auth, billing (per-seat mailbox pricing), and GDPR/data-residency conversations.
• Operational tooling scope. Useful as a scoping artifact for an internal ops console — admin-only mailbox provisioning for a small number of domains — which is a far smaller commitment than a customer-facing email product.
• Migration/exit planning. Reading its schema is genuinely useful if you are moving off cPanel/PostfixAdmin/Plesk and need to map legacy mailbox rows into a new system.

Verdict for planning purposes: treat it as a design input worth ~a day of reading, not a line item in the architecture. No adoption decision should hinge on it.

When to Consider This Package

Adopt-adjacent criteria (it is a fork-and-vendor candidate at best):

• You are on Symfony — despite the brief, this is a Symfony bundle (LassoVmailBundle), not a Laravel package. If the team is Laravel-first, this is already the wrong shape.
• You run your own Postfix + Dovecot stack and want the virtual-user tables managed from your existing admin app rather than a separate tool like PostfixAdmin.
• You have a small, fixed domain count, low mailbox volume, no SLA, and an engineer who owns mail infrastructure.
• You accept that you will fork it and own it: last release 2014-07-08, 1 star, 0 dependents, no security patch path. The Symfony 2.x-era code will need porting before it runs on a supported PHP version, and anything touching mail relay is abuse- and auth-adjacent — unmaintained code there is a liability, not a shortcut.

Look elsewhere when:

• You need modern PHP 8 / Symfony 6–7 or any Laravel support.
• Deliverability, IP reputation, bounce handling, or spam filtering matter — those live in the MTA and your ops practice, not in this bundle.
• You want a vendor with an SLA, DMARC/SPF guidance, or compliance posture. Use a hosted provider (SES/Postmark/Mailgun for sending; Google Workspace, Fastmail, Migadu for mailboxes) or a maintained self-hosted suite (Mailcow, Mailu, iRedMail, PostfixAdmin) that already ships the admin UI, DKIM rotation, and quota management you would otherwise rebuild.
• Inbound email is a core product loop — parse-and-webhook services are a better build-vs-buy trade than owning an MTA.

How to Pitch It (Stakeholders)

To executives: There is a real product question behind this — should we host mailboxes ourselves? — but this package is not the answer to it. It is a 2014-era, single-star Symfony bundle with no dependents and no maintenance, so it represents roughly a day of useful reference reading, not a procurement or a dependency. Recommendation: fund a short spike to decide between (a) hosted provider for mailboxes, (b) a maintained self-hosted suite the ops team already knows, or (c) building a thin provisioning layer ourselves if mailbox control is genuinely differentiating. The cost driver in all three options is deliverability, abuse handling, and on-call — not the CRUD code this package provides.

To engineering: Treat it as a schema reference. The interesting part is the Postfix SQL lookup contract (virtual_mailbox_domains, virtual_mailbox_maps, virtual_alias_maps) and the domains/mailboxes/aliases table set; that is a couple of days to reimplement on a supported stack and removes the fork-and-maintain burden and the unpatched-code risk in a mail-relay path. If we go self-hosted, start from Mailcow or PostfixAdmin and integrate via their APIs/DB rather than resurrecting this. Flag for security review that any component in the mail path is abuse-sensitive and needs an owner.