Postmark Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on transactional email delivery. This package is a thin Symfony 2 bundle wrapping the Postmark API — a useful data point that "integration layer" is not the hard part of email. The real decision is vendor selection (Postmark vs. SES vs. SendGrid), deliverability, and template ownership, not whether to write a 200-line client.
• Informing a deprecation/consolidation roadmap. With 14 stars, 0 dependents, no release since 2013, and an archived repo, it is a clean signal that a framework-specific wrapper for a single ESP does not sustain community interest. If your roadmap includes maintaining an in-house mailer adapter, this is the likely trajectory.
• Sourcing precedent for an anti-pattern list. It demonstrates the risk of coupling business code to a third-party SDK through a framework bundle: when the bundle dies, so does your upgrade path. That supports a decision to standardize on a mailer abstraction (Symfony Mailer / Laravel Mail) plus a maintained transport, rather than per-vendor bundles.
• Validating the "opportunity" score as a filter. The low opportunity score (1.42) and overall score (0.265) should be used to calibrate whatever dependency-scoring heuristic your team applies — this is a good negative-control example that the scoring model correctly rejects.
• Not a feature or roadmap input. There is no feature in this package you cannot get from the official Postmark client libraries; it does not unlock new product capability.

When to Consider This Package

Only ever as a historical reference — never as a dependency. Specific criteria for adoption are effectively unmet:

• Archived status is disqualifying. No security patching, no PHP 8 compatibility, no PSR-4/Composer modernization, no Symfony 5/6/7 support. It targets a PHP and Symfony generation that is long out of support.
• Zero dependents means no ecosystem validation and no one else to surface bugs or edge cases in production.
• You are on Symfony 2.x and frozen there — and even then, vendoring the three or four HTTP calls directly is cheaper than adopting an unmaintained bundle.
• You explicitly want to study the Postmark API surface (send, bounce, inbound) as a reference implementation before writing your own adapter.

Look elsewhere when: you are actually shipping transactional email. Use the official Postmark PHP client (wildbit/postmark-php), which is the maintained upstream, or the framework-native transport (Symfony Mailer's Postmark bridge, Laravel's postmark mailer driver). Those are supported, tested against current PHP, and covered by the vendor's own support commitments.

How to Pitch It (Stakeholders)

For executives: We evaluated mlpz/postmark-bundle as a candidate for transactional email integration and are recommending against adoption. It has been archived, has had no release since September 2013, and has zero downstream dependents — meaning no security maintenance and no compatibility with our current PHP/Symfony stack. The underlying capability (sending email through Postmark) is fully available from Postmark's own maintained client and from Symfony/Laravel's built-in mail transports at no cost. This is a low-effort, zero-cost substitution, and it removes an unmaintained third-party dependency from our supply chain before it becomes an upgrade blocker.

For engineering: The package is a thin Symfony 2 bundle over the Postmark API — the value is entirely in the wrapper, not the logic. Both the wrapper and its framework target are EOL. Recommended path: use the official wildbit/postmark-php client behind the framework's native mail abstraction so vendor choice stays swappable. If we ever need custom delivery behavior, we'll implement it in our own adapter with tests, not by forking a nine-year-dormant bundle.

Decision requested: Close the evaluation, record "no adoption — archived/EOL," and use it as the reference case in our dependency-scoring guidance.