Mail Parser Bundle Laravel Package

Product Decisions This Supports

• Inbound email as a feature surface. Whether to ship "email-to-ticket," "forward an email to your workspace," or attachment ingestion. This package is a reference for the minimum viable scope of that feature (header parsing, MIME multipart bodies, attachment extraction) and helps you estimate the real shape of the work before committing roadmap capacity.
• Build vs. buy (with a third option: borrow). The package is a thin Symfony bundle wrapping Zend's mail libraries. Its main PM value is as a spec, not a dependency: use it to size an in-house parser (roughly: header normalization, multipart walking, charset/encoding handling, attachment storage, malformed-email hardening) and to justify buying or adopting a maintained library instead.
• Prioritization of "email ingestion" vs. "email parsing." The parser is the commodity 20% of the feature; the product value sits in routing rules, threading/conversation matching, spam handling, attachment virus scanning, and storage. This package reinforces that parsing is a solved problem you should not own.
• Dependency-risk decisions. Zero dependents, four stars, last release July 2014, and LGPL-3.0 are all inputs to a "do we accept this into our supply chain?" decision. The answer informs your dependency governance policy, not just this one call.
• Vendor/lock-in analysis. Because it binds to a specific Symfony generation and to Zend Framework components (both EOL), it's a concrete example for your architecture review of why "framework-adjacent wrapper" packages carry disproportionate upgrade tax.

When to Consider This Package

Adoption criteria — all of these must be true, and in practice they rarely are:

• You are running a legacy Symfony 2.x application that already ships Zend Framework 2 mail components, so the marginal dependency is near-zero.
• The code is frozen: no security patching expected, no new features, internal-only exposure.
• You have a legal review clearing LGPL-3.0 for your distribution model (fine for internal SaaS, a real conversation for on-prem/shipped binaries, and worth flagging that LGPL obligations attach to the Zend-derived code you'd be linking).
• You need a one-off batch job (e.g., ingest an mbox archive) rather than a maintained production path.

Look elsewhere when:

• You are on Laravel or PHP 8. This is a Symfony bundle, not a Laravel package — integration is glue-code work, not a composer require.
• You need security maintenance. A 2014 last release means no CVE response for MIME parsing, which is a classic attack surface (parser DoS, header injection, zip-bomb attachments).
• You need IMAP/POP retrieval, streaming large mailboxes, or modern charset handling — the Zend-era stack does not cover this well.
• Modern alternatives fit the bill and are maintained: zbateson/mail-mime-parser (actively maintained MIME parser), webklex/php-imap (Laravel-native IMAP + parsing), or Symfony's own Mailer/Mime components if you're in that ecosystem.
• You care about license hygiene across a product you may someday sell or open-source.

How to Pitch It (Stakeholders)

To executives: Inbound email parsing looks like a build-vs-buy decision, but it's really a "don't build, don't buy this" decision. The specific package in front of us is a 2014-era Symfony wrapper over end-of-life Zend libraries, with no maintenance, no community, and an LGPL license that adds legal overhead. We should not adopt it. The useful output of evaluating it is a validated scope for the feature and a recommendation to use a maintained open-source parser — days of integration work instead of weeks of building and a permanent maintenance tail we'd own forever.

To engineering: Treat this repo as a reference implementation and a checklist, not a dependency. It shows the shape of the problem — MIME multipart traversal, header normalization, attachment extraction — but it's a Symfony bundle on EOL Zend components with no release since 2014, so adopting it means pinning old PHP and owning the security surface ourselves. Recommended path: zbateson/mail-mime-parser for parsing, webklex/php-imap if we need mailbox retrieval, wrapped behind our own MailParser interface so the library is a swappable detail. Budget real time for hardening (malformed input, attachment size limits, encoding edge cases) — that's where the effort actually lives.