Listmonk tagged-source audit · 1 Oct 2026
Listmonk v6.2.0: confirmation is not a distinct welcome send.
In the inspected v6.2.0 paths, double-opt-in confirmation changes selected list memberships to confirmed and renders a success page. It does not call a distinct welcome send. No native post-confirmation welcome was found in the checked handler, core hook, template, campaign, and transactional paths. This is a bounded source finding, not a test or proof about every customization.
The checked path
| Step | What the tagged source supports | What it does not establish |
|---|---|---|
| Submit | A public form/API submission can create an unconfirmed double-opt-in list membership. The opt-in hook sends the confirmation email and URL. | The opt-in notification is not a later welcome. A duplicate submission is not proof of a new confirmation event. |
| Confirm | The public handler selects unconfirmed memberships, invokes a membership update, then renders a page. A sequential duplicate click with no unconfirmed membership reaches the no-subscription page. | The inspected path has no subsequent welcome send or post-confirmation hook. A page saying success is not a delivery receipt. |
| Welcome | POST /api/tx can request a transactional send. A regular campaign sends to an eligible set; an optin campaign targets unconfirmed DOI memberships. | Neither is an automatic, distinct welcome for each new confirmation. The transactional handler does not check list confirmation, suppression or welcome attempts. |
Why a caller needs its own controls
The tagged subscriber API can filter a list by subscription_status=confirmed. An external caller could inspect returned global and list state, reconcile an operator-held welcome-attempt ledger, recheck suppression just before a reviewed default-mode /api/tx call, and record the response. That is a design sketch, not a safe built-in contract. fallback and external transactional modes can send without an existing subscriber, so avoid them for this job. A read/send race, concurrent workers, ambiguous API response, provider events and exactly-once outcome remain unresolved. The API response does not prove final provider delivery.
A regular campaign's recipient SQL checks confirmed DOI membership and excludes unsubscribed or blocklisted recipients, but a campaign is a finite run, not a per-confirmation journey. An external transactional caller cannot borrow that campaign selection as automatic suppression. The campaign SQL and unsubscribe handler are separate paths.
Private check, then a stop
- Pin v6.2.0 in an isolated non-public instance, use fictional
example.invaliddata and a local mail sink. Keep production credentials, real contacts, public ingress and unattended schedules out. - Observe submit, DOI message, confirmation state, duplicate click, unsubscribe-before-confirm and resubscription. Dry-run welcome candidate selection and the attempt ledger; if necessary, send only to the local sink.
- Stop before real sending if provenance, suppression, attempt reconciliation, ambiguous-response policy, provider events, recovery or a named human approval owner is missing.
The confirmation SQL does not itself predicate on unconfirmed, although the handler first selects unconfirmed memberships. A concurrent unsubscribe/confirmation race is therefore a test question, not an observed failure. No installation or mail test was performed for this report.
Version and evidence limits
The official v6.2.0 release (26 June 2026) points to commit ef0a758…5453a. The checked repository's tagged licence is AGPLv3; it says nothing about an SMTP provider, custom trigger or separate deployment contents. The tagged system-template inventory lists opt-in confirmation, not a distinct welcome. Direct local git access failed DNS and some raw/API reads failed; none of those failures is used to assert absence. This was tagged source and documentation reading, not a binary, provider, security or live workflow test.
For the broader small-list choice, read the 29 September decision and 30 September Keila follow-up. The latter leaves package, restore, disclosure and SMTP-outcome gates open. An already operated, approved manual sender remains the small-list off-ramp when it records consent, opt-outs, review and provider outcome. See the research library and evidence notes.