You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SMTP callers need to know what the server accepted, when a retry could duplicate mail, and what happened when a connection failed. This tracks the independently reviewable improvements in 03_SMTP_ROBUSTNESS_IMPROVEMENT_PLAN.
The project builds on the 10.0.0 submission receipts (#710), terminal observer (#712), and exact EML support (#713). It does not add automatic retries, a durable spool, or mailbox-delivery guarantees.
Phases 1, 2 and 3 are complete and accepted. Phase 4 now has its DSN and REQUIRETLS steps complete: per-attempt ENVID correlation (#736), recipient NOTIFY with automatic ORCPT (#738), and per-email onward delivery TLS requirements (#741). The related DKIM/S/MIME Email-policy consolidation (#737) is also complete. Code and matching website documentation are committed and pushed to the 10.0.0 development branches; none of this is a 10.0.0 release. Phase 1's leftover open issue (#723) has been reconciled with its previously pushed implementation.
Progress: 7 of the 10 original steps complete (70% by step count, not an estimate of effort). Three of five phases are complete. Phase 4 has DSN and REQUIRETLS done, with explicit SMTPUTF8/8BITMIME requirements and finalized SIZE handling still to do. Phase 5's conformance suite also remains. Execution views (#734) and the configuration/recipient refinements (#737/#738) are additional child issues, not additional original steps. Ten child issues are complete. Step 8 is active under #742; Steps 9 and 10 do not yet have child issues.
Current send architecture
This maps the accepted pooled asynchronous send path, including the completed #726 implementation. The layers explain responsibilities; they are not a lock-order diagram.
SMTPUTF8 and 8BITMIME requirements (characterization in progress)
9
Not created
Unscheduled
—
SIZE against finalized transmitted bytes
10
Not created
Unscheduled
—
Reproducible conformance and fault-injection tests
Each scheduled step gets its own linked sub-issue, exact release milestone, tests, documentation, and release entry. Keep this parent open until the steps are completed or explicitly moved to a successor plan. PIPELINING/CHUNKING remain parked under #699. Benchmarking is outside the current work.
Keep the overview current
The canonical image lives at docs/concurrency/assets/inside-a-mail-send.png. The concurrency catalogue uses that master, the website uses an identical copy, and this issue embeds the master through the development branch.
Every remaining step must review the pictured class names, responsibilities, transport paths, cancellation boundaries, and outcome reporting. Record either an update or why the overview remains accurate; do not add proposed behavior or expand the picture for changes that still fit its existing layers.
Phase 2: reviewed unchanged on 11 September 2026; the pictured cleanup and outcome boundaries match the completed implementation.
SMTP capability probe (Explain SMTP connection capabilities and TLS negotiation #733): reviewed unchanged at completion on 15 September 2026. Java/CLI probing and its partial-provider boundary stay outside the illustrated send, pool-lease and observer path.
Phase 3: reviewed unchanged at completion on 15 September 2026. The Reject extra properties that disable mandatory STARTTLS #735 construction-time guard runs before send-operation, proxy, lifecycle and pool setup; it adds no send owner, lock, state transition or probe-to-send dependency. The catalogue, website copy and this embed retain the approved overview.
ENVID-only slice (Add DSN envelope identifiers for send correlation #736): reviewed unchanged on 15 September 2026. A fresh per-message provider wrapper and capability check fit the existing transport layer; pool ownership, cancellation and observer ordering are unchanged. Implementation is accepted and delivered.
Per-email REQUIRETLS (Add per-email REQUIRETLS for protected onward delivery #741): reviewed unchanged at acceptance on 17 September 2026. The Email flag follows the existing preparation and provider-envelope path. Angus validates the actual TLS connection and post-TLS capability under the existing transport send monitor, then reports actual MAIL FROM use through the existing result and receipt path. No new owner, lock, worker or resource lifetime was introduced.
Phase 4: complete SMTPUTF8/8BITMIME requirements and finalized SIZE handling, reviewing the overview as each lands.
Phase 5: compare the overview with the conformance scenarios.
Before the 10.0.0 release: reconcile the implementation, catalogue, website, and this image.
When the artwork changes, update the master, website copy, and this existing embed together. Refresh the image URL's revision query to avoid a cached older image; do not add a separate competing diagram attachment.
SMTP callers need to know what the server accepted, when a retry could duplicate mail, and what happened when a connection failed. This tracks the independently reviewable improvements in
03_SMTP_ROBUSTNESS_IMPROVEMENT_PLAN.The project builds on the 10.0.0 submission receipts (#710), terminal observer (#712), and exact EML support (#713). It does not add automatic retries, a durable spool, or mailbox-delivery guarantees.
Phases 1, 2 and 3 are complete and accepted. Phase 4 now has its DSN and REQUIRETLS steps complete: per-attempt ENVID correlation (#736), recipient NOTIFY with automatic ORCPT (#738), and per-email onward delivery TLS requirements (#741). The related DKIM/S/MIME Email-policy consolidation (#737) is also complete. Code and matching website documentation are committed and pushed to the 10.0.0 development branches; none of this is a 10.0.0 release. Phase 1's leftover open issue (#723) has been reconciled with its previously pushed implementation.
Progress: 7 of the 10 original steps complete (70% by step count, not an estimate of effort). Three of five phases are complete. Phase 4 has DSN and REQUIRETLS done, with explicit SMTPUTF8/8BITMIME requirements and finalized SIZE handling still to do. Phase 5's conformance suite also remains. Execution views (#734) and the configuration/recipient refinements (#737/#738) are additional child issues, not additional original steps. Ten child issues are complete. Step 8 is active under #742; Steps 9 and 10 do not yet have child issues.
Current send architecture
This maps the accepted pooled asynchronous send path, including the completed #726 implementation. The layers explain responsibilities; they are not a lock-order diagram.
Steps
Each scheduled step gets its own linked sub-issue, exact release milestone, tests, documentation, and release entry. Keep this parent open until the steps are completed or explicitly moved to a successor plan. PIPELINING/CHUNKING remain parked under #699. Benchmarking is outside the current work.
Keep the overview current
The canonical image lives at
docs/concurrency/assets/inside-a-mail-send.png. The concurrency catalogue uses that master, the website uses an identical copy, and this issue embeds the master through the development branch.Every remaining step must review the pictured class names, responsibilities, transport paths, cancellation boundaries, and outcome reporting. Record either an update or why the overview remains accurate; do not add proposed behavior or expand the picture for changes that still fit its existing layers.
MAIL FROMuse through the existing result and receipt path. No new owner, lock, worker or resource lifetime was introduced.When the artwork changes, update the master, website copy, and this existing embed together. Refresh the image URL's revision query to avoid a cached older image; do not add a separate competing diagram attachment.