Auth Sasl Laravel Package

Product Decisions This Supports

• Inbound email ingestion / mailbox sync features. Any roadmap item that involves connecting to customer mailboxes over IMAP/POP3 (support ticketing ingestion, CRM email logging, e-discovery, notification parsing) needs SASL negotiation against servers with heterogeneous auth configs. This package is the mechanism layer for that.
• Outbound mail where standard Laravel mail won't authenticate. Laravel's default mail path (Symfony Mailer) covers PLAIN, LOGIN, CRAM-MD5 and XOAUTH2. If a prospect runs an on-prem Exchange, Zimbra, or ISP relay demanding DIGEST-MD5 or NTLM, this is the gap-filler.
• Build vs. buy on protocol plumbing. SASL response generation is fiddly, spec-driven, and low-differentiation. The decision this informs is "buy/wrap, don't hand-roll" — but also "don't over-invest in a single-maintainer dependency."
• Enterprise / on-prem segment qualification. Whether we can credibly sell to customers with legacy mail infrastructure is a roadmap question this package answers cheaply. It is a compatibility unlock, not a product.
• Explicit non-support decisions. Because it does not do OAuth2/XOAUTH2, it also helps you define the boundary: modern Google/Microsoft 365 tenants need a separate auth track (Graph API, league/oauth2-*, Symfony's XOAuth2 authenticator). That's a distinct roadmap line item, not something this package can absorb.

When to Consider This Package

Adopt when:

• You are building a custom IMAP/POP3/SMTP client in PHP rather than going through Symfony Mailer or a maintained mail library.
• Target servers measurably require CRAM-MD5, DIGEST-MD5, or NTLM — confirmed by a customer's actual server banner and CAPABILITY response, not by assumption.
• You can accept a PEAR-style, non-namespaced, non-PSR-4 codebase and are willing to vendor or wrap it behind your own adapter interface.
• You have a PHP 8.2/8.3 test matrix and can validate it against a real server, since the last release (Dec 2023) is a maintenance touch, not evidence of active development.
• The scope is narrow and time-boxed: a compatibility shim for a named set of accounts.

Look elsewhere when:

• Mail is sent through Laravel's standard Mail facade or Symfony Mailer — this is redundant; you already have the mechanisms you need.
• The provider is Google Workspace or Microsoft 365 — modern auth is OAuth2/XOAUTH2, which this does not implement.
• You need maintained, namespaced, tested, security-reviewed code. Eleven stars and a PEAR lineage mean no meaningful community backstop; assume you own the code if it breaks.
• The target mechanism is DIGEST-MD5 (deprecated by RFC 6331) or NTLMv1 — pushing these into a new build is a security-posture decision, not just a technical one.
• A maintained library already covers the protocol end-to-end (e.g. a modern IMAP client or Symfony's authenticators). Pulling in a mechanism-only package means you still own the session, TLS, and error handling around it.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost compatibility component that unblocks deals in the on-prem and legacy-ISP segment — customers whose mail servers use older authentication schemes our default mail stack doesn't speak. It is not a strategic bet and not a platform. Cost is measured in days, risk is contained if we isolate it, and it should be treated as a stopgap with a known exit path.

To engineering: One thin helper that generates SASL response strings for PLAIN, LOGIN, CRAM-MD5, DIGEST-MD5 and NTLM. It does not manage connections, TLS, retries, or token refresh. Integrate it behind our own SaslAuthenticator interface so the concrete library is swappable, pin the version, and cover it with integration tests against real servers rather than unit tests alone — the failure modes here are server-specific.

To the risk committee (honest version): Eleven stars, a single-maintainer PEAR lineage, and a mechanism set that includes deprecated options. We are adopting it because writing SASL by hand is worse, not because this is a healthy dependency. Set a review date, keep the surface to one adapter, and expect to replace it if the segment grows beyond a handful of accounts.