Two defects found by reading all 684 issues in another project's tracker. Both measured here before a line was written.
The SMTP password was sent over an unverified connection
smtplib without an explicit SSL context falls back to ssl._create_stdlib_context() — which on current Python is _create_unverified_context:
ssl._create_stdlib_context is ssl._create_unverified_context → True
check_hostname=False verify_mode=0
So SMTP_USER and SMTP_PASSWORD went to whatever answered on SMTP_HOST:SMTP_PORT, presenting any certificate at all. No compromise of the real mail server needed — being on the path was enough.
Demonstrated both directions against a local server holding a self-signed certificate for an unrelated hostname. Before: it captured AUTH PLAIN with the credentials in it. After: it gets nothing.
If you run an internal mail server with a self-signed certificate, this will now fail for you. That is the correct behaviour and I am not going to pretend otherwise, but you have an escape hatch: SMTP_TLS_VERIFY=false restores the old behaviour. The failure message names it, and using it logs a line saying what it costs.
Every day-of-week schedule fired one day late
Cron counts weekdays from Sunday — 0=Sunday through 6=Saturday, with 7 a second spelling of Sunday. Python's weekday() counts from Monday. The matcher fed one straight into the other.
Measured across a full week:
0 9 * * 1 "Mondays" → fired Tuesdays
0 3 * * 0 "Sundays" → fired Mondays
0 3 * * 7 "Sundays" → fired never
The Web UI's own shipped preset "Weekly (Mondays 9 AM)" is that first expression, so anyone who picked it from the dropdown has been getting Tuesdays. And the "next 3 ticks" preview used the same function, so it confirmed the wrong day rather than catching it — which is why this survived.
Ranges and lists are covered too: 1-7 now means Monday through Sunday inclusive, rather than excluding the one day it names explicitly.
Also
A docksentry.auto, .enable or .exclude label on Docksentry's own container now says out loud that it does nothing. It genuinely has no effect there — that label tells another instance how to treat this container, and no other instance is watching — but silence was the wrong way to handle it. @LeeNX put it well: "I am not a fan of things that get ignored, it's a pattern that you don't know you might be doing something wrong and things look like they're just breaking." The silent ignore came from the fix for his own issue, which makes the point twice over.
Bind-mount propagation survives a recreate. A :rslave or :rshared bind came back as rprivate, so the container silently stopped seeing host mounts that appeared later — the classic symptom being a media stack that no longer notices a disk mounted after it started.
Upgrading is the usual docker pull ghcr.io/amayer1983/docksentry:latest, or nothing at all with auto-selfupdate on.