Mailbox Bundle Laravel Package

Product Decisions This Supports

• Whether "email-in" is a real product surface or a nice-to-have. A mailbox poller is the cheapest way to validate demand for features like: shared-inbox-to-ticket, lead capture from an sales@ alias, invoice/receipt ingestion, vendor document intake, bounce/abuse triage, and email-to-record creation. A spike here answers "do users actually forward us things?" before anyone commits to a real inbound-email platform.
• Build vs. buy vs. spike. The honest finding is that this package is not a build-vs-buy decision at all — it is a thin Symfony DI wrapper around the PHP IMAP library. The real decision is one layer down: poll an IMAP mailbox vs. consume an email provider's inbound webhook (Postmark, SendGrid, Mailgun, SES, Gmail/Graph push). Framing the choice at the wrapper level would mislead the roadmap.
• Roadmap sequencing for the transport layer. If inbound email is on the roadmap, this package confirms the shape of the MVP (connect → list unseen → fetch → parse MIME/attachments → mark seen) but should not be treated as the foundation. The build estimate should be scoped against a maintained library or provider API, not this one.
• Cost-of-ownership sizing. Zero stars, zero dependents, zero maintainers is a direct, quantifiable signal: no CVE response, no PHP version bumps, no OAuth support. That is the input to "is this a one-day spike or a three-quarter liability?"
• Not a Laravel decision at all. This is a Symfony bundle (knyk/mailbox-bundle) with no Laravel service provider, no facade, no config publishing. In a Laravel codebase it contributes nothing you wouldn't get from composer require php-imap/php-imap directly. It should not appear in a Laravel dependency review as a candidate.
• Architectural risk callout for leadership: the underlying approach depends on ext-imap, which was unbundled from PHP core in 8.4, and on IMAP Basic Auth, which Microsoft disabled for Exchange Online in 2022 and which Google is steadily constraining. Any product bet on password-based IMAP polling has a shrinking runway.

When to Consider This Package

Consider it (narrowly):

• You are on a legacy Symfony 2/3/4 app, PHP ≤ 8.1, with ext-imap compiled in, and you want the mailbox wired as a container service in under an hour.
• You need a throwaway spike or internal tool — one mailbox, low volume, an on-prem Dovecot/Postfix or a provider app-password, no OAuth, no multi-tenancy, no audit trail.
• You want reference material for how to structure a mailbox service and config schema before writing your own — read it, don't depend on it.

Look elsewhere when:

• You're on Laravel. Use webklex/php-imap (pure PHP, no ext-imap, actively maintained, Laravel-friendly) or a provider SDK. This bundle is the wrong ecosystem.
• You need OAuth2 / modern auth. Gmail and Microsoft 365 both require OAuth flows for mailbox access; password-based IMAP is a dead end for the two providers most customers actually use. Go to the Graph API or Gmail API directly, or use a provider that brokers OAuth for you.
• You need webhooks or IMAP IDLE. Polling means latency and wasted cycles. Inbound-email webhooks give you sub-second delivery, retries, and delivery guarantees for free.
• You need scale or multi-tenancy. Hundreds of mailboxes × polling intervals × attachment parsing is an operational problem, not a library problem.
• You need maintenance guarantees. Zero stars, zero dependents, no recent activity means no security patching. If inbound email is customer-facing, that's an unacceptable supply-chain risk regardless of the MIT license.
• You need auditability, retention, or compliance. A polling wrapper gives you none of the delivery metadata, DKIM/SPF results, or retention controls that a provider surfaces.
• You're on PHP 8.4+. The ext-imap dependency is the first thing to break.

How to Pitch It (Stakeholders)

To executives: We evaluated a package for reading inbound email into the product and are recommending against adopting it. It's a small, unmaintained Symfony wrapper — zero stars, zero downstream users, no recent activity — around a library that depends on a PHP extension that was removed from core in 8.4 and on a mail authentication method Microsoft retired in 2022. Adopting it would mean inheriting a component nobody patches, on an integration path our customers' email providers are actively shutting down. The capability it points at — turning shared inboxes into structured records — is still worth validating, and we can do that in roughly a one-day spike using a maintained library or an inbound-email webhook provider. The decision ask is a small spike budget, not a dependency commitment.

To engineering: Treat this as a pattern reference, not a dependency. It shows the minimal wiring for a mailbox service; it does not give us a Laravel service provider, OAuth, webhook delivery, retries, or multi-mailbox support, and it will not survive a PHP upgrade. If we build inbound email, we should either (a) use webklex/php-imap for pure-PHP IMAP polling, or better (b) use an inbound-email webhook provider and skip polling entirely. Recommendation: do not add knyk/mailbox-bundle to composer.json; run a timeboxed spike on the provider route and bring back a build-vs-buy comparison. Flag the ext-imap sunset and Basic Auth deprecation in the spike write-up so the choice is documented rather than rediscovered later.