Laravel Mail Aliyun Laravel Package

Product Decisions This Supports

• Platform modernization: Confirms the package is now aligned with PHP 8.3+ and Laravel 13, so it supports a roadmap decision to keep DirectMail delivery on the modern Laravel stack rather than maintaining a custom transport.
• Build vs. buy: Favors using/maintaining this package for DirectMail API delivery where requirements fit, instead of building in-house Symfony Mailer transport plumbing. Re-evaluate if BCC, attachments, hidden envelope-only recipients, or raw MIME messages are product requirements.
• Feature scope clarity: Supported DirectMail use cases now include signed requests, Unicode tags, text/HTML alternatives, and supported envelope recipients. Product should not promise BCC, attachments, hidden recipients, or unstructured raw messages through this transport; those must route through SMTP or another provider path.
• Release/upgrade planning: 4.0.0 is a breaking upgrade. Teams on older Laravel/PHP versions should plan a coordinated platform upgrade or defer. Teams already on Laravel 13/PHP 8.3+ can adopt, but must budget for transport contract and extension-point changes.
• Operational risk reduction: Explicit failures for unsupported mail features are better than silent omission or recipient exposure. This supports compliance, privacy, and supportability decisions, provided product flows are audited for unsupported mail patterns.

When to Consider This Package

• Consider it when the application is on PHP 8.3+ and Laravel 13, uses DirectMail as a strategic delivery provider, and needs first-party Laravel mail transport integration.
• Consider it when the team wants maintained DirectMail delivery on modern Laravel and can accept the documented feature boundary: no BCC, no attachments, no hidden envelope-only recipients, and no unstructured raw messages through this transport.
• Consider it when the team can follow UPGRADING.md, test extension points/tag callbacks migrated to withSymfonyMessage, and validate in staging before production.
• Look elsewhere or use DirectMail SMTP when product requirements include BCC, attachments, hidden envelope-only recipients, raw MIME messages, or a broader feature set than the API transport supports.
• Look elsewhere or defer if the platform is below PHP 8.3/Laravel 13, if the team cannot absorb a breaking Symfony Mailer migration, or if the release’s mocked validation is insufficient without a live staging/canary test.

How to Pitch It (Stakeholders)

This release restores working DirectMail delivery on modern Laravel and moves the package from SwiftMailer to Symfony Mailer, keeping it relevant for PHP 8.3+/Laravel 13 applications. For engineering, it is a breaking upgrade with transport contract and extension-point changes, so UPGRADING.md and regression testing are mandatory. For executives, the value is lower custom-integration risk and clearer compliance behavior: unsupported mail features now fail explicitly instead of silently dropping data or exposing recipients. The trade-off is narrower scope—BCC, attachments, hidden envelope-only recipients, and raw messages require SMTP or another delivery path. Adopt with an upgrade plan and staging validation; do not position it as a full-featured mail transport.