Notification email

Email here reports; it never signs anybody in. There is no magic link, no emailed code, no reset. The one message that carries a link is the invitation: single use, expiring, and good only for registering the first passkey of an account that has none, sent to the address an administrator set. A message tells somebody that a passkey was registered or revoked, that a recovery code was used, that a recovery was approved, or that they have been invited, and if any of that is a surprise to them, they have been told in time to say so.

The same relay carries the administrator alerts, which tell every administrator when the directory changes in ways that matter. With mail off, those are held until it returns.

That restraint is the whole design. An identity provider whose recovery path runs through email has made the mail provider the real identity provider.

Configuring it

cardinal mail settings                        # how this deployment sends
cardinal mail set -host smtp.internal -port 587 -from cardinal@example.com -tls starttls
cardinal mail test -to you@example.com        # send one, print what the relay said
cardinal mail status                          # what is queued, what is failing
cardinal mail templates -show passkey.registered
cardinal mail templates -reset

mail set leaves omitted fields alone, and does not change the password unless one is given.

mail settings says whether a relay password is stored, never what it is, and distinguishes the case that matters: a relay configured with a username and no password, which fails to authenticate and used to be reported the same way as one that was set.

Settings live in the database, not the configuration file. A deployment running the published container image can change how it sends mail without rebuilding anything or restarting. The single exception is mail.encryption_key, which is in the file because it protects the relay password stored beside everything else: a key stored next to what it encrypts protects nothing.

mail test prints what the relay actually said. An SMTP failure that surfaces as "could not send" is a support ticket; the relay's own sentence is usually the answer.

In the console

Administration → Notifications is the same settings, the same test send, and the queue. Template wording can be viewed and overridden there.

Both paths write to the same rows. This is one of the places where console and CLI genuinely are equivalent.

Best for

• Telling people that something changed on their account, which is most of what detects a compromise early.
• Deployments where the operator is not the person who built the container image, and settings therefore cannot live in a file.

The trade-off

Queued mail is state, and a relay that has been quietly failing looks exactly like a quiet week. mail status and the console queue exist because of that, but somebody has to look: nothing alerts.

Limits

• Notification only. No email-based sign-in, recovery or verification, and none planned.
• SMTP only. No provider APIs.
• No per-person preferences. Notifications are on for the events Cardinal sends; there is no opt-out UI.
• No alerting on a failing queue. It is visible, not noisy.