- How do I install holzweg/bounce-mail-handler in a Laravel application?
- Install it with Composer using composer require holzweg/bounce-mail-handler, but first verify its PHP and extension constraints against your app. The package is not Laravel-native and does not ship a service provider, facade, or publishable config, so you will likely need to wire it manually or isolate it behind your own interface. Run a Docker spike on your target PHP version before adopting it in production.
- Does holzweg/bounce-mail-handler support Laravel 10 and 11?
- There is no official Laravel 10 or 11 integration; the package targets PHP 5.x and is PSR-0 era. Laravel 10 and 11 typically run PHP 8.1 or 8.2+, and runtime behavior on PHP 8.2 is unproven, with likely issues around removed functions, PSR-0 assumptions, or dependency conflicts. Treat Laravel 10/11 support as something you must validate in a time-boxed spike rather than assume.
- What PHP version and extensions does holzweg/bounce-mail-handler require?
- The package explicitly targets PHP 5.x and uses PSR-0 naming conventions. It likely requires ext-imap, mbstring, and possibly iconv for mailbox access and MIME parsing. Exact Composer constraints are unclear from the overview, so check Packagist and composer.json before planning an install.
- How does it distinguish hard bounces from soft bounces?
- It parses inbound bounce messages and classifies failures as hard or soft based on the bounce content and DSN-style metadata. Hard failures typically mean the address is undeliverable and should be suppressed, while soft failures may be temporary and warrant retries. The package is best treated as a reference implementation for classification rules because provider formats vary and test coverage is unclear.
- Can holzweg/bounce-mail-handler connect to Gmail or Microsoft 365 with OAuth2?
- The overview describes a PHP 5.x-era IMAP-style mailbox handler and does not mention OAuth2 support. Modern Gmail and Microsoft 365 mailbox access often requires OAuth2 rather than basic auth, so verify this before relying on it. If OAuth2 is required, a maintained IMAP library or provider webhooks are safer choices.
- Does the package delete or move emails after processing bounces?
- Mailbox-mutating behavior such as delete or move creates data-loss risk unless it is disabled or tightly controlled. The overview does not specify the default, so inspect the configuration and source before running it against a real mailbox. For production, prefer read-only processing and idempotent handling so reprocessing does not lose messages.
- Is there a Laravel service provider, config file, or queue integration?
- No. The technical assessment notes that the package lacks a service provider, facade, publishable config, DI-friendly contracts, events, and queue integration. You would need to wrap it in your own Laravel service, job, or command and manage configuration yourself. That wrapper also gives you a clean boundary to replace it with webhook-based ingestion later.
- How should I test bounce classification for different email providers?
- Build a fixture corpus of real bounce messages from your actual provider, including Exchange/Microsoft 365, Gmail, Amazon SES, SendGrid, and Mailgun formats. Run the package against those fixtures in a Docker spike on PHP 5.6, 7.4, and 8.2 to see what parses correctly. Also test encodings, attachments, large messages, and malformed MIME, because those are common failure points.
- What are better alternatives to holzweg/bounce-mail-handler for Laravel?
- For modern Laravel apps, webhook-based bounce ingestion from SES/SNS, SendGrid, Mailgun, or Postmark aligns better with HTTP, queue, and scheduler patterns. You can also use a maintained IMAP library behind an application-owned BounceProcessor interface and port only the classification rules you need. The package is most useful as a reference for bounce-classification logic, not as a direct production dependency.
- Is holzweg/bounce-mail-handler maintained and safe for production?
- Adoption signals are weak: the assessment cites 1 star, 0 dependents, and a low score, with PHP 5.x end-of-life security exposure. Maintenance cadence, CI coverage, license, and PHPMailer dependency version are unclear, so a fork-and-own plan is required if you proceed. The recommendation is to time-box a feasibility spike and default to no-go for direct production use unless it runs cleanly on PHP 8.2 and passes fixture tests.