Document the email-verification flag where SMTP is configured (relay#40) #113

2026-09-04T22:19:41Z

paulhitt commented

2026-09-04 22:19:41 +00:00

(Migrated from gitlab.com)

The issue asked to confirm whether email is ever verified. It is: the
feature is built, and it gates issuing a TOKEN rather than signing up —
which is exactly the 'verify to send, not to sign up' trade the issue
proposed.

Measured on production: all 6 accounts arrive via the shared FlameNet
service, ZERO have a local email, and the relay has no SMTP configured at
all. So the exposure described — a reset path aimed at an address nobody
owns — does not exist here. It is a self-hosting concern, and for
self-hosters the feature already exists behind
FN_EMAIL_VERIFICATION_REQUIRED.

The one real gap was where it was written down. docs/CONFIGURATION.md
describes it accurately; .env.example did not mention it, and
.env.example is where somebody configuring SMTP actually looks —
which is the same person who has just become able to turn it on.

Placed inside the SMTP block on purpose: enforcement is
required AND canSendMail, so setting it on a relay with no mail does
nothing. That is deliberate — an account that cannot be sent a code could
never spend one — but it is the kind of silent no-op somebody should meet
in the comment rather than in production.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

The issue asked to confirm whether email is ever verified. It is: the feature is built, and it gates issuing a TOKEN rather than signing up — which is exactly the 'verify to send, not to sign up' trade the issue proposed. Measured on production: all 6 accounts arrive via the shared FlameNet service, ZERO have a local email, and the relay has no SMTP configured at all. So the exposure described — a reset path aimed at an address nobody owns — does not exist here. It is a self-hosting concern, and for self-hosters the feature already exists behind FN_EMAIL_VERIFICATION_REQUIRED. The one real gap was where it was written down. `docs/CONFIGURATION.md` describes it accurately; `.env.example` did not mention it, and `.env.example` is where somebody configuring SMTP actually looks — which is the same person who has just become able to turn it on. Placed inside the SMTP block on purpose: enforcement is `required AND canSendMail`, so setting it on a relay with no mail does nothing. That is deliberate — an account that cannot be sent a code could never spend one — but it is the kind of silent no-op somebody should meet in the comment rather than in production. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

paulhitt commented

2026-09-04 22:19:41 +00:00

(Migrated from gitlab.com)

assigned to @paulhitt

paulhitt (Migrated from gitlab.com) merged commit 07408fd400 into main

2026-09-04 22:20:05 +00:00

paulhitt commented

2026-09-04 22:20:06 +00:00

(Migrated from gitlab.com)

mentioned in issue #40

paulhitt commented

2026-09-04 22:20:06 +00:00

(Migrated from gitlab.com)

mentioned in commit 07408fd400

mentioned in commit 07408fd400feccf14638d44e0315fdd985ecbc41

paulhitt commented

2026-09-09 18:58:59 +00:00

(Migrated from gitlab.com)

changed the description

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: extant2000/flamenet-relay#113