An SMTP connection becomes reusable only after security setup
Django's historical STARTTLS flaw explains why reusable SMTP state must mean security setup succeeded, even when the caller suppresses connection errors.
By 
Paul. Architecture and infrastructure
A reusable SMTP connection should mean that every required setup step succeeded. Merely having a connection object is a weaker fact. If later code treats that object as ready, suppressing an initialization error can accidentally preserve a sending path that never met the configured security requirements. Readiness needs a deliberate publication point after setup completes.
That is the durable lesson from Django's historical STARTTLS issue. Error reporting and connection validity are separate decisions. An application may choose to suppress an exception at a particular call site, but that choice must not turn incomplete setup into permission to send. Otherwise the next operation inherits a stronger claim about the connection than the previous operation established.
A failed transition can leave an object behind
The Django security release notice of 3 June 2026 describes CVE-2026-7666. With EMAIL_USE_TLS, failed STARTTLS negotiation could leave a partial connection available for later unencrypted sending, including when fail_silently=True was used. The notice excludes connections configured with EMAIL_USE_SSL from this specific issue.
The failure is best understood as a mismatch between stored state and completed work. A connection object can exist before encryption is established. If a reusable field is assigned at that earlier point, another method can infer readiness merely by checking the field. An exception may end the current operation without undoing what the field now appears to promise.
Suppressing the exception makes the mismatch easier to overlook, but suppression is not the whole design problem. The field already carries an ambiguous meaning: either “there is an object under construction” or “sending may proceed.” Callers should not need to reconstruct the last setup attempt to decide which interpretation applies.
Publish readiness after the prerequisites
The linked 5.2 branch patch makes the distinction explicit with _partial_connection. Setup works on that partial object; self.connection is assigned after the required configuration, including conditional authentication, completes. Cleanup also accounts for partial state. The implementation gives incomplete and reusable connections separate places to live.
The general design principle is stronger than adding another Boolean flag. Code that wants a reusable connection should obtain only a connection whose prerequisites have been met. Code doing initialization may need a partial resource, but that resource should not silently enter the normal sending path. Separating the two reduces the number of places that must remember which setup steps remain.
Consider an illustrative notification worker that retains its mail connection between operations. One notification encounters a setup error. A later notification should not interpret the existence of an earlier object as evidence of a successful negotiation. Each attempt must either obtain a ready connection or follow the failure policy. Reuse saves work only after the work required for safe reuse has actually completed.
This reasoning extends to optional authentication without narrowing the issue to a password failure. The relevant condition is whatever setup the configuration requires. Some deployments require authentication; others do not. A readiness contract must reflect that configuration while retaining the mandatory security transition where it applies.
Silent failure needs a bounded meaning
There can be legitimate reasons not to expose a mail exception to an end user. A background notification may be secondary to the action the user requested. That policy can decide how the application reports a failed notification. It cannot establish that a partially initialized transport is suitable for a subsequent one.
The distinction also affects operational reasoning. “The request continued” and “the notification was sent through a ready connection” are different outcomes. A system that deliberately tolerates mail failure should preserve that difference in its design. Otherwise application continuity can be mistaken for successful delivery or for satisfaction of transport requirements.
There is no universal instruction here to make every mail failure fatal. The requirement is narrower: a tolerated failure must leave the reusable state valid. Depending on the application, the next operation may attempt setup again or report another failure. It must not inherit a cleartext path merely because the previous exception was hidden.
Implicit TLS avoids this transition
The strongest counterargument is that implicit TLS avoids the specific STARTTLS upgrade sequence described in the advisory. That is a meaningful difference, and the notice's EMAIL_USE_SSL exclusion should remain intact. The same historical defect should not be attributed to every encrypted SMTP configuration.
Implicit TLS still needs correct error handling and a truthful readiness contract. Changing the connection sequence does not make every partial resource reusable. The broader principle applies wherever an object can exist before required initialization finishes, even though the exact failure path differs.
The June notice names releases 6.0.6 and 5.2.15 and patches for main, 6.1 at alpha status, 6.0 and 5.2. Those are historical scope and resolution details, not an inspection of installed applications. The patch discussed here is the 5.2 backport; it is evidence about the state transition, rather than a claim about a reader's deployment.
For software maintenance, make that transition a review target: identify the field that authorizes reuse, list its prerequisites, and confirm that failure cannot publish it early. Exception suppression may change what callers hear. It must leave the definition of a ready connection intact.