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>
