Listmonk v6.2.0: the private DOI and suppression test did not run.

Why the test stopped

The official v6.2.0 release points to commit ef0a758…5453a. That identifies source, not installed bytes. A workspace check found no v6.2.0 artifact or digest, Listmonk or container executable/socket, PostgreSQL executable, or local mail-sink executable. No isolated instance, network restriction, or teardown record was supplied; local Git access failed DNS. Browsing tagged source did not turn those missing controls into a runtime test. We stopped before installation or simulation.

Before the first future request, an operator must record an official artifact and immutable digest tied to this tag, a disposable private app and database, a sink-only SMTP route with outbound blocking, disabled public ingress and schedules, and a tested teardown. Do not substitute an unpinned latest image or third-party build.

What tagged code says—and does not prove

The confirmation handler selects unconfirmed list memberships, calls an update, and renders a page. A sequential duplicate click with none left reaches a no-subscription page. The confirmation SQL has no status predicate; an unsubscribe between selection and update is a plausible untested race, not an observed failure. The resubscription SQL can reset an unsubscribed membership to unconfirmed while retaining a confirmed membership. The subscriber API exposes global and per-list status and list/status filters. These support a future read-only candidate check, not authorization to send.

The inspected /api/tx handler does not establish a welcome-specific consent, suppression, or idempotency gate. Its documented fallback and external modes can weaken even the assumption that the address is a known subscriber. A response to a future call would not by itself prove provider delivery.

The unexecuted private test card

In a disposable, sink-only fixture, use a fictional example.invalid subscriber and an active double-opt-in list. Save exact configuration, HTTP responses, full subscriber and list-filtered API states, logs, and sink counts independently for submission, DOI email, confirmation, and sequential duplicate click. Repeat from clean snapshots for unsubscribe before an old confirmation link, unsubscribe after confirmation, public resubmission, duplicate submission while confirmed, and global blocklisting. A controlled unsubscribe/confirm interleaving needs reproducible database barriers; without them, leave the race unresolved. An admin-induced unsubscribe models a state change, not a subscriber's campaign-link action. The full 1 October tagged-source trace remains the baseline.

Only after those observations could an operator trial a read-only selector: require a confirmed membership on the intended list and global enabled status, record exclusions, and compare against an operator-owned attempt ledger. Any later sink-only send would need a fresh suppression read, atomic ledger claim, named human approval, and separate evidence of API acknowledgement versus sink acceptance. Those controls still cannot atomically couple the state read and send, eliminate concurrent-worker or ambiguous-response risk, or promise exactly-once delivery. No selector or ledger was run here.

Next evidence, not a launch plan

Obtain the pinned artifact and isolated fixture, then execute and preserve the card's evidence. If that is unavailable, ask a Listmonk maintainer for a v6.2.0-specific answer about supported post-confirmation events or welcome idempotency/suppression gates, and the intended outcome if unsubscribe commits between the handler's unconfirmed read and its confirmation update. Stop before any real recipient until a named sender owner has approved consent provenance, current suppression, content, bounded attempt/retry rules, ambiguous-response handling, provider outcomes, recovery, and an incident path. Keila's K1/K3/X1 gates also remain open. Read the small-list decision and Keila follow-up for those separate options.