ops: set an explicit SMTP connect/read timeout instead of trusting lettre defaults #163

New issue

Closed

opened 2026-08-09 18:23:03 +00:00 by rosa · 0 comments

rosa commented

2026-08-09 18:23:03 +00:00

Owner

Found during an operational-resilience review (Release It! stability rules).

Location: crates/infra/src/jobs/mailer.rs:37
Severity: Medium — unbounded wait (Timeouts)

Problem

The lettre SMTP transport is built without an explicit connect/read timeout, so it relies on lettre's / the OS's defaults, which may be effectively unbounded. A hung or half-open SMTP relay can park a mailer worker on a single send for a very long time, consuming worker capacity that healthy mail jobs need.

Unlike the webmention client (webmention.rs), which sets explicit 30s request / 5s connect timeouts, the mail path has no bound the code guarantees.

Suggested fix

Set an explicit timeout on the SMTP transport builder so every send has a bounded wait, matching the discipline already applied to the webmention client.

Found during an operational-resilience review (Release It! stability rules). **Location:** `crates/infra/src/jobs/mailer.rs:37` **Severity:** Medium — unbounded wait (Timeouts) ## Problem The lettre SMTP transport is built without an explicit connect/read timeout, so it relies on lettre's / the OS's defaults, which may be effectively unbounded. A hung or half-open SMTP relay can park a mailer worker on a single `send` for a very long time, consuming worker capacity that healthy mail jobs need. Unlike the webmention client (`webmention.rs`), which sets explicit 30s request / 5s connect timeouts, the mail path has no bound the code guarantees. ## Suggested fix Set an explicit timeout on the SMTP transport builder so every `send` has a bounded wait, matching the discipline already applied to the webmention client.

rosa added the

labels

2026-08-09 18:23:16 +00:00

rosa referenced this issue from a commit

2026-08-12 01:50:05 +00:00

fix: bound SMTP sends with explicit connect and send timeouts

rosa referenced this issue from a pull request that will close it,

2026-08-12 01:50:42 +00:00