Net Smtp Laravel Package

Technical Evaluation

Architecture fit. pear/net_smtp is not a Laravel package — it is a legacy PEAR component. It exposes global, non-namespaced classes (Net_SMTP), returns PEAR_Error objects instead of throwing exceptions, and depends transitively on pear/net_socket and PEAR core for error handling and socket abstraction. Laravel's mail stack expects PSR-4 autoloading, container-resolved contracts, typed exceptions, and PSR-3 logging. Nothing here drops in; every integration point requires an adapter.

Integration feasibility. Technically achievable but structurally awkward. In Laravel 9+ the path is a custom Symfony TransportInterface implementation wrapping Net_SMTP, registered through Mail::extend() and wired into config/mail.php. That is roughly 1–2 sprints of work including tests, retry semantics, and failure mapping — for a capability the framework already ships.

Technical risk.

• Duplicative capability. Laravel's default Symfony\Component\Mailer\Transport\Smtp\EsmtpTransport already covers SMTP, STARTTLS, and PLAIN/LOGIN/CRAM-MD5/XOAUTH2 auth. Adopting Net_SMTP only makes sense for a specific gap (e.g., NTLM, DIGEST-MD5, or an exotic relay quirk) or for legacy parity.
• Ecosystem decay. PEAR is in long-term decline; documentation lives on pear.php.net, and community answers are stale. Bus factor is effectively one maintainer.
• Error model mismatch. Unchecked PEAR_Error returns fail silently — a well-known source of "mail reported sent, nothing arrived" incidents. Every call site needs explicit guarding.
• Security defaults to verify. TLS certificate verification, STARTTLS enforcement versus opportunistic upgrade, and auth-mechanism fallback behavior are all configuration-sensitive and must be explicitly proven, not assumed.
• Dependency surface. Pulling PEAR core and net_socket into vendor/ adds unaudited legacy code to the supply-chain review for a small functional gain.

Key questions.

1. Does the 2026-01-04 release carry a PHP 8.3/8.4 support statement, or is it a compatibility patch?
2. What are the actual defaults for certificate verification and STARTTLS downgrade?
3. Which auth mechanisms are implemented, and is XOAUTH2 present and modern (token refresh, not just bearer passthrough)?
4. Are there documented timeout, retry, and connection-reset semantics we can map onto Laravel queue retries?
5. What specific behavior does Net_SMTP provide that EsmtpTransport does not — and is that behavior load-bearing for us?
6. Who is the upstream maintainer, and what is the stated support horizon?

Integration Approach

Stack fit. Poor as a default, acceptable as a narrow exception handler. The correct framing for stakeholders: this is a low-level library, not a Laravel integration. Treat it as infrastructure plumbing behind an interface we own.

Migration path. Only justify adoption in two scenarios: (a) an in-flight migration off a legacy PEAR-based application where preserving exact SMTP behavior de-risks cutover, or (b) a proven functional gap in Symfony Mailer. For greenfield or already-modernized services, the recommendation is to stay on EsmtpTransport and avoid the dependency entirely.

Compatibility.

• Require via Composer (pear/net_smtp), confirm the transitive PEAR packages pin cleanly.
• Verify PHP version constraints against the target runtime before committing.
• Exclude PEAR sources from strict static analysis (PHPStan/Psalm) rather than suppressing globally.
• Confirm the classmap autoload does not collide with any in-house PEAR-era code still resident in the monorepo.

Sequencing.

1. Spike (3–5 days). Stand up Net_SMTP against a test relay; document auth, TLS, timeout, and error behavior in writing.
2. Adapter. Implement a Symfony TransportInterface wrapper translating PEAR_Error into TransportException with retryable/non-retryable classification.
3. Parity harness. Run identical message sets through EsmtpTransport and the adapter; diff delivery, headers, encoding, and failure codes.
4. Configuration surface. Expose host/port/encryption/auth/timeout through config/mail.php and .env; no hardcoded credentials, no secrets in logs.
5. Canary. Route one low-volume, non-transactional mail stream (internal notifications) through the adapter behind a feature flag.
6. Exit criteria. Written thresholds for delivery success rate, latency, and error rate; a documented rollback to EsmtpTransport.

Operational Impact

Maintenance. Low release velocity with a single-maintainer profile. BSD-2-Clause permits forking, which should be the explicit contingency: if upstream goes dark, we vendor and patch. Budget a standing line item for dependency review each PHP minor release.

Support. No Laravel community mindshare — 26 stars means no Stack Overflow corpus, no Slack/Discord answers, no blog coverage. Internal runbook ownership is mandatory before go-live. Escalation path terminates with our own engineers.

Scaling. Synchronous, blocking sockets with no connection pooling; each message pays a fresh TCP and TLS handshake. Acceptable for low-volume internal mail; unsuitable as a primary transactional path. Above roughly 10k messages/day, route through a provider API or a pooled relay rather than raw SMTP from application workers. Always dispatch from queue workers, never inline in a request.

Failure modes.

• Silent failure from unguarded PEAR_Error returns — the highest-probability incident.
• Blocking connect/read hangs occupying queue workers until timeout; must set aggressive timeouts and cap worker concurrency.
• Opportunistic TLS downgrade or skipped certificate verification sending credentials in the clear.
• Auth mechanism fallback to PLAIN against a relay that rejects it, producing opaque 5xx errors.
• Credential leakage via verbose SMTP dialogue logs — scrub before logging.

Ramp-up. One to two days for a mid-level PHP engineer to become productive, most of it spent on PEAR idioms (PEAR_Error checking, include-path conventions, no type hints) rather than SMTP itself. Add half a day of onboarding for the runbook and the adapter's error taxonomy. Plan for the knowledge to be concentrated in one or two people — a documentation obligation, not an optional one.