A worker opens a connection, sends, and forgets to close it. Nothing breaks for a week, then the provider starts refusing new connections and every send fails at once.
Connections are the scarce resource
Providers cap concurrent connections per account and per IP, often at a low number. A pool that grows because closed connections are not returned will hit that cap, and the failure mode is total rather than gradual: once the cap is reached, every new send blocks.
Where the leak comes from
An exception between MAIL FROM and QUIT skips the close. A timeout on DATA leaves the socket open until the OS reaps it. A retry path that creates a fresh connection without releasing the failed one doubles the count. None of these show up in a happy-path test.
The fix
Wrap the whole conversation in a context manager that guarantees QUIT, and on any exception close the socket rather than returning it to the pool — a connection in an unknown protocol state is worse than no connection. Then export the pool size as a metric and alert when it approaches the provider's cap.
One detail worth copying
Reuse connections for multiple messages to the same domain, but reset state with RSET between recipients. Reconnecting for every message is slow and looks like abuse to the receiver; not resetting leaks the previous envelope into the next send.
Volanea manages the SMTP session per domain and exposes connection and deferral counters next to the send log.
Top comments (0)