- Is lasso/mail-parser-bundle a Laravel package?
- No. Despite being listed among Laravel/PHP packages, it is a Symfony bundle: the namespace is Lasso\MailParserBundle, it uses a Bundle extension class, and it relies on Resources/config/services.yml conventions. Laravel's package discovery has no ServiceProvider or Facade to hook into, so it will not auto-register in a Laravel application.
- How do I install lasso/mail-parser-bundle in a Laravel app?
- There is no Laravel installation path. Composer may resolve the package, but you would have to write a service provider from scratch to bind the parser and expose configuration, and you would still inherit its abandoned Zend dependencies. For a new integration, use symfony/mime, which Laravel already ships transitively, or another maintained parser instead.
- What does the Lasso Mail Parser Bundle actually do?
- It parses inbound raw email into structured data, extracting headers, bodies, and attachments so you can route messages, build ticketing workflows, or automate replies. Internally it wraps zendframework/zend-mail and zendframework/zend-mime, most likely Zend\Mail\Storage\Message plus Zend\Mime\Decode. Its output contract is a bespoke array or object rather than a documented DTO.
- Does lasso/mail-parser-bundle support PHP 8 and Laravel 10 or 11?
- No. The last release was July 2014, and Laravel 5.0 did not ship until February 2015, so it has never been tested against any Laravel version. The Zend code targets PHP 5.3 to 5.6 and predates removed curly-brace string offsets, each(), and create_function(), plus PHP 8.2 dynamic-property deprecation. Expect fatal errors or type issues under PHP 8.x.
- Are the package's dependencies still maintained?
- No. zendframework/zend-mail and zendframework/zend-mime were renamed to Laminas in 2019/2020, and the original zendframework/* packages are formally abandoned on Packagist. Composer will still install them, but you inherit the abandonment flag, an unpatched security surface, and a PHP version ceiling. That is a high-risk transitive dependency chain for any production mail path.
- What license does it use and can I use it commercially?
- It is licensed LGPL-3.0, which is unusual for PHP packages and needs legal review. The key questions are how LGPL linking and vendoring obligations apply to your deployment model, whether you distribute container images, and what relink obligations you may trigger. Do not assume it is as permissive as MIT-licensed Laravel packages.
- Does it correctly parse nested multipart emails, encoded words, and attachments?
- That is the biggest unknown. MIME handling is a moving target: nested multipart/* trees, RFC 2047 encoded-words, charset handling, and RFC 2231 parameters are all common edge cases. A 2014-era parser's coverage will not match modern mail, so validate per-part base64/quoted-printable decoding and attachment recovery with real samples before trusting it.
- What should I use instead of lasso/mail-parser-bundle in Laravel?
- Use symfony/mime first; Email::fromString() and its header parsing are already in Laravel's dependency tree via symfony/mime, with active security maintenance and zero new packages. For large attachments choose zbateson/mail-mime-parser, which streams and is memory-conscious. php-mime-mail-parser offers a higher-level API, and notably its v6+ replaced Zend with the ZBateson engine, which shows where the ecosystem went.
- Can I wrap the bundle in a Laravel service provider?
- Yes, but it is only step one. Porting the Symfony bundle means a thin container binding plus a config array, roughly half a day of work. The same sprint should replace the Zend internals with symfony/mime and pin the output contract with characterisation tests captured against the old parser. Installing the bundle directly without a provider is not possible; skipping the internal swap leaves you on abandoned dependencies.
- Is lasso/mail-parser-bundle safe for production or still maintained?
- No. It has 4 stars, 0 dependents, no releases in roughly 11 years, and a critical bus factor. Combined with abandoned Zend transitive dependencies and high PHP 8.x compatibility risk, it is not a safe production choice. Treat it as a reference implementation and re-implement the roughly 200 lines of glue against a maintained parser.