Version

• /listmonk # ./listmonk --version
  v5.0.1 (dc466fc 2025-05-25T09:50:56Z, linux/amd64)
• /listmonk # uname -a
  Linux ... 6.12.29-1-lts ... SMP PREEMPT_DYNAMIC Sun, 18 May 2025 08:31:54 +0000 x86_64 Linux
• grep image compose.yaml
  image: "listmonk/listmonk:latest"
• docker images | grep listmonk
  listmonk/listmonk latest 3906704ac0da 3 weeks ago 30.6MB

Description of the bug and steps to reproduce

When an SMTP authentication error occurs during subscription to a double opt-in list, Listmonk incorrectly displays the OptinPage (public.subConfirmed) instead of the expected public.subOptinPending message.

Restoring correct SMTP credentials immediately resolves the issue, and the expected workflow resumes.

To reproduce:

1. Intentionally set an invalid SMTP username or password.
2. Submit the /subscription/form with at least one double opt-in list.
3. You'll see the public.subConfirmed string
4. You’ll see a log entry like this:

subscribers.go:708: error sending opt-in e-mail for subscriber 47 (df206b23-e11a-492f-89a9-74bac5004060): 535 5.7.8 Error: authentication failed: (reason unavailable)

Expected Behavior

Possible behavior: Instead of showing the opt-in confirmation page, the system should display the message.html template with public.errorProcessingRequest or another appropriate error state.

Remark: Listmonk must queue the confirmation emails because I received them a short while after (this was during testing)

So, a better behavior could be to not display the processing error (because the subscriber does not need to be aware of housekeeping issues), but they should see the proper subscribers.sentOptinConfirm message.

But I'm wondering if Listmonk can email the admin when errors occur.

Note:

This appears to be a logic bug, hopefully this is not a misconfiguration on my part. I ran across the bug because of an SSL issue.