feat: verify email addresses and recover forgotten passwords

Ekklesia could authenticate a person and, since Pass 1, send a
transactional email — but it had no way to establish that an address
belonged to whoever claimed it, and no way back in for someone who
forgot their password.

A verified address is now a precondition for holding a session. Better
Auth enforces that after the password check and before any session
exists, so an unverified sign-in returns 403 with no cookie. That is why
no "unverified principal" was needed: a correct password on an
unverified address carries exactly the authority of no password, and
/api/v1/principal is unchanged.

Better Auth keeps every token. Ekklesia adds no token table, no hashing,
and no expiry clock. It supplies a recipient, a subject, and two bodies,
and the mail provider supplies everything about SMTP.

Verification and reset links are rebuilt from a validated Dashboard
origin, taking only the token — never the URL Better Auth prebuilds from
a caller-supplied callbackURL — so no request can steer where a
recipient lands. Following a verification link mints no session, because
mail infrastructure dereferences links. Reset revokes that person's
other sessions and leaves managed devices alone.

Recovery answers identically for an address with an account, without
one, already verified, or undeliverable — including when SMTP is broken,
which is why the delivery adapter never throws.

The initial platform owner is the one exception: created already
verified by an operator command with no mail prerequisite, so a fresh
server can be signed in to before a relay exists. Migration 0007 extends
that to owners of installations that already exist. Public signup stays
disabled; verification is not a licence to self-register.

Co-Authored-By: Claude Opus 5 <[email protected]>

core/src/authorization/initial-owner.ts

@@ -14,6 +14,7 @@ export type InitialPlatformOwnerErrorCode =
   | "INITIAL_OWNER_EMAIL_INVALID"
   | "INITIAL_OWNER_IDENTITY_NOT_CREATED"
   | "INITIAL_OWNER_IDENTITY_UNUSABLE"
+  | "INITIAL_OWNER_IDENTITY_NOT_VERIFIED"
   | "INITIAL_OWNER_OWNERSHIP_GRANT_FAILED"
   | "INITIAL_OWNER_PASSWORD_TOO_LONG"
   | "INITIAL_OWNER_PASSWORD_TOO_SHORT"
@@ -28,6 +29,8 @@ const initialOwnerMessages: Readonly<Record<InitialPlatformOwnerErrorCode, strin
       "The identity system reported success but no account exists for that address. Nothing was changed; the bootstrap is still available.",
     INITIAL_OWNER_IDENTITY_UNUSABLE:
       "An account already exists for that address but has no password and could never sign in. Choose a different address, or remove that account before retrying.",
+    INITIAL_OWNER_IDENTITY_NOT_VERIFIED:
+      "The identity exists but could not be marked as a verified address, so it could not sign in. Nothing was granted; the bootstrap is still available.",
     INITIAL_OWNER_OWNERSHIP_GRANT_FAILED:
       "The identity exists but platform ownership was not granted. Bootstrap is still available: run this command again with the same email address to finish it.",
     INITIAL_OWNER_PASSWORD_TOO_LONG: "The password is longer than the identity system allows.",
@@ -131,6 +134,25 @@ async function findIdentityByEmail(
   return { hasCredential: credentials.length > 0, storedEmail: found.email, userId: found.id };
 }
 
+/**
+ * Marks one identity's address verified.
+ *
+ * A direct column update rather than an identity-system call, because the pinned release exposes no
+ * supported way to mark an address verified other than consuming a token it emailed — which is the
+ * one thing a pre-mail installation cannot do. The column is Better Auth's own `emailVerified`, the
+ * exact value its `/verify-email` endpoint writes, so the resulting row is indistinguishable from
+ * one that verified normally; nothing here invents a parallel notion of verification.
+ */
+async function markIdentityEmailVerified(
+  db: IdentityDrizzleDatabase,
+  userId: string,
+): Promise<void> {
+  await db
+    .update(ekklesiaCoreUser)
+    .set({ emailVerified: true })
+    .where(eq(ekklesiaCoreUser.id, userId));
+}
+
 function translateIdentityCreationError(error: unknown): InitialPlatformOwnerError {
   if (error instanceof BootstrapIdentityError) {
     if (error.code === "BOOTSTRAP_IDENTITY_PASSWORD_TOO_SHORT") {
@@ -252,6 +274,29 @@ export async function createInitialPlatformOwner(
       throw new InitialPlatformOwnerError("INITIAL_OWNER_IDENTITY_NOT_CREATED");
     }
 
+    /**
+     * The trusted-bootstrap verification exception (ADR 0038).
+     *
+     * Every other human account must verify its address by email before it may hold a session.
+     * This one cannot: it is created on a freshly provisioned server by an operator who already
+     * holds the database credentials, at a moment when SMTP may not be configured, may not be
+     * reachable, or may not yet have a DNS record to send from. Requiring an email round trip here
+     * would mean a working installation whose administrator can never get in — the platform's
+     * outbound mail would have to be configured and correct before anyone could sign in to
+     * configure anything.
+     *
+     * The exception is narrow and its authority is the same authority that already makes this
+     * command safe: possession of the database, not possession of the mailbox. It marks exactly one
+     * address, exactly once per installation, and it is deliberately performed **before** ownership
+     * is granted — if it fails, the sentinel and the grant roll back together and re-running the
+     * command adopts the identity and finishes, rather than leaving an owner who cannot sign in.
+     */
+    try {
+      await markIdentityEmailVerified(dependencies.identityDb, parsedUserId.data);
+    } catch {
+      throw new InitialPlatformOwnerError("INITIAL_OWNER_IDENTITY_NOT_VERIFIED");
+    }
+
     try {
       const grant =
         dependencies.grantOwnership ??

core/src/diagnostics/doctor.ts

@@ -116,6 +116,7 @@ export interface DoctorReport {
 
 export interface DoctorIdentityConfigurationOptions {
   readonly baseUrl?: string | undefined;
+  readonly dashboardOrigin?: string | undefined;
   readonly environment?: CreateIdentityConfigOptions["environment"];
   readonly publicSignupEnabled?: string | undefined;
   readonly secret?: string | undefined;
@@ -1193,7 +1194,7 @@ export async function diagnoseEkklesia(
       "skipped",
       "Outbound email not configured",
       [
-        "No EKKLESIA_SMTP_HOST is set. This is a complete deployment: nothing in the platform sends email yet.",
+        "No EKKLESIA_SMTP_HOST is set. The platform runs and the bootstrap owner can sign in, but email verification and account recovery cannot deliver.",
       ],
     );
   } else {

core/src/host/configuration.ts

@@ -26,6 +26,9 @@ export type HostEnvironmentName = "development" | "production";
  */
 export interface HostIdentityEnvironmentInput {
   readonly baseUrl: string | undefined;
+  /** Where an emailed verification or reset link sends a browser. Unset means the Dashboard is
+   * served from `baseUrl`, which is the ordinary same-origin production shape (ADR 0038). */
+  readonly dashboardOrigin: string | undefined;
   readonly publicSignupEnabled: string | undefined;
   readonly secret: string | undefined;
   readonly trustedOrigins: readonly string[] | undefined;
@@ -118,6 +121,7 @@ export function loadHostConfiguration(environment: HostEnvironment): HostConfigu
     environment: environment.NODE_ENV === "development" ? "development" : "production",
     identity: {
       baseUrl: environment.EKKLESIA_IDENTITY_BASE_URL,
+      dashboardOrigin: environment.EKKLESIA_DASHBOARD_ORIGIN,
       publicSignupEnabled: environment.EKKLESIA_PUBLIC_SIGNUP_ENABLED,
       secret: environment.EKKLESIA_IDENTITY_SECRET,
       trustedOrigins: splitList(environment.EKKLESIA_IDENTITY_TRUSTED_ORIGINS),

core/src/identity/config.ts

@@ -5,6 +5,10 @@ export type IdentityConfigErrorCode =
   | "BASE_URL_INVALID"
   | "BASE_URL_LOOPBACK_IN_PRODUCTION"
   | "BASE_URL_MISSING"
+  | "DASHBOARD_ORIGIN_INSECURE_IN_PRODUCTION"
+  | "DASHBOARD_ORIGIN_INVALID"
+  | "DASHBOARD_ORIGIN_LOOPBACK_IN_PRODUCTION"
+  | "DASHBOARD_ORIGIN_UNTRUSTED"
   | "PUBLIC_SIGNUP_ENABLED_INVALID"
   | "PUBLIC_SIGNUP_UNSUPPORTED_IN_PRODUCTION"
   | "SECRET_LOW_ENTROPY"
@@ -127,6 +131,13 @@ const errorMessages: Readonly<Record<IdentityConfigErrorCode, string>> = Object.
   BASE_URL_LOOPBACK_IN_PRODUCTION:
     "The identity base URL must not resolve to a loopback host in production.",
   BASE_URL_MISSING: "The identity base URL is required.",
+  DASHBOARD_ORIGIN_INSECURE_IN_PRODUCTION: "The Dashboard origin must use https in production.",
+  DASHBOARD_ORIGIN_INVALID:
+    "The Dashboard origin must be an absolute http or https origin with no path, query, or fragment.",
+  DASHBOARD_ORIGIN_LOOPBACK_IN_PRODUCTION:
+    "The Dashboard origin must not resolve to a loopback host in production.",
+  DASHBOARD_ORIGIN_UNTRUSTED:
+    "The Dashboard origin must also be listed as a trusted origin, or emailed links will be refused.",
   PUBLIC_SIGNUP_ENABLED_INVALID:
     'Public signup enablement must be an explicit boolean or the exact string "true"/"false".',
   PUBLIC_SIGNUP_UNSUPPORTED_IN_PRODUCTION:
@@ -163,6 +174,21 @@ export class IdentityConfigError extends Error {
 
 export interface IdentityConfig {
   readonly baseUrl: string;
+  /**
+   * The browser origin an emailed verification or password-reset link sends a person to.
+   *
+   * Defaults to `baseUrl`, which is the ordinary production shape: the Dashboard bundle and the API
+   * are served from one origin. It exists as its own value because they are not the same *concept* —
+   * `baseUrl` is where the `/api/auth` transport lives, this is where a human's browser lands — and
+   * a deployment may separate them (an API at `https://api.example.org`, the Dashboard at
+   * `https://dash.example.org`). It is deliberately **not** the public church website origin: this
+   * is the authenticated Dashboard host and nothing else.
+   *
+   * Validated to be one of `trustedOrigins` (or `baseUrl`, which Better Auth trusts implicitly), so
+   * a misconfiguration fails at startup rather than producing emailed links every recipient is
+   * refused at.
+   */
+  readonly dashboardOrigin: string;
   /** Whether `POST /api/auth/sign-up/email` accepts new accounts. Defaults to `false` (disabled) —
    * public signup never becomes reachable merely because this input was omitted, misspelled, or
    * loosely parsed. Development and test composition may enable it explicitly; production
@@ -176,6 +202,8 @@ export interface IdentityConfig {
 
 export interface IdentityConfigInput {
   readonly baseUrl?: unknown;
+  /** Optional. Absent or empty means the Dashboard is served from `baseUrl`. */
+  readonly dashboardOrigin?: unknown;
   readonly publicSignupEnabled?: unknown;
   readonly secret?: unknown;
   readonly trustedOrigins?: unknown;
@@ -261,6 +289,45 @@ function validateBaseUrl(baseUrl: unknown, environment: IdentityEnvironment): st
   return url.origin;
 }
 
+/**
+ * Resolves the origin an emailed link points a browser at.
+ *
+ * Unset falls back to the identity base URL — the same-origin production shape — rather than
+ * failing, because a deployment that has not separated its Dashboard from its API has nothing to
+ * configure. When it *is* set it is held to exactly the base URL's rules and then to one more: it
+ * must be an origin Better Auth already trusts, because Better Auth validates the emailed callback
+ * against `trustedOrigins` before redirecting. Checking it here converts a broken link every
+ * recipient would hit into a startup failure the operator sees once.
+ */
+function validateDashboardOrigin(
+  dashboardOrigin: unknown,
+  baseUrl: string,
+  trustedOrigins: readonly string[],
+  environment: IdentityEnvironment,
+): string {
+  if (dashboardOrigin === undefined || dashboardOrigin === null || dashboardOrigin === "") {
+    return baseUrl;
+  }
+  const url = parseCanonicalHttpOrigin(dashboardOrigin);
+  if (!url) {
+    throw new IdentityConfigError("DASHBOARD_ORIGIN_INVALID");
+  }
+  if (environment === "production") {
+    if (url.protocol !== "https:") {
+      throw new IdentityConfigError("DASHBOARD_ORIGIN_INSECURE_IN_PRODUCTION");
+    }
+    if (isLoopbackOrUnspecifiedHostname(url.hostname)) {
+      throw new IdentityConfigError("DASHBOARD_ORIGIN_LOOPBACK_IN_PRODUCTION");
+    }
+  }
+  // `baseUrl` is accepted without appearing in `trustedOrigins` because Better Auth itself adds the
+  // base URL's origin to its trusted set (`getTrustedOrigins`, pinned release).
+  if (url.origin !== baseUrl && !trustedOrigins.includes(url.origin)) {
+    throw new IdentityConfigError("DASHBOARD_ORIGIN_UNTRUSTED");
+  }
+  return url.origin;
+}
+
 function validateTrustedOrigin(origin: unknown, environment: IdentityEnvironment): string {
   if (typeof origin !== "string" || origin.length === 0) {
     throw new IdentityConfigError("TRUSTED_ORIGIN_INVALID");
@@ -355,7 +422,19 @@ export function createIdentityConfig(
   const secret = validateSecret(input.secret);
   const baseUrl = validateBaseUrl(input.baseUrl, environment);
   const trustedOrigins = validateTrustedOrigins(input.trustedOrigins, environment);
+  const dashboardOrigin = validateDashboardOrigin(
+    input.dashboardOrigin,
+    baseUrl,
+    trustedOrigins,
+    environment,
+  );
   const publicSignupEnabled = validatePublicSignupEnabled(input.publicSignupEnabled, environment);
 
-  return Object.freeze({ baseUrl, publicSignupEnabled, secret, trustedOrigins });
+  return Object.freeze({
+    baseUrl,
+    dashboardOrigin,
+    publicSignupEnabled,
+    secret,
+    trustedOrigins,
+  });
 }

core/src/identity/index.ts

@@ -2,4 +2,5 @@ export * from "./bootstrap-identity.js";
 export * from "./client-address.js";
 export * from "./config.js";
 export * from "./database.js";
+export * from "./notifications.js";
 export * from "./runtime.js";

core/src/identity/notifications.ts

@@ -0,0 +1,291 @@
+import { MailError, type MailProvider, validateMailMessage } from "../mail/index.js";
+
+/**
+ * The identity feature's outbound messages, and the seam between Better Auth's callbacks and the
+ * host's mail transport (ADR 0038).
+ *
+ * ## What this owns and what it deliberately does not
+ *
+ * It owns the recipient, the subject, and the two bodies. It does **not** know the SMTP host, the
+ * port, the TLS mode, a credential, or the sender: those are host configuration held by the mail
+ * provider, and there is no field on the message contract through which a caller could choose any
+ * of them (ADR 0037). Swapping SMTP for a provider HTTP API would not change a line of this file.
+ *
+ * It also does not own tokens. Better Auth mints, persists (for reset), expires, and consumes them;
+ * this receives one already-minted token and puts it in a link. There is no Ekklesia token table,
+ * no Ekklesia token hashing, and no Ekklesia expiry clock — a second implementation of any of those
+ * would be a second thing to get wrong.
+ *
+ * ## Why the link is rebuilt rather than used as given
+ *
+ * Better Auth hands these callbacks a prebuilt `url`, and that URL embeds whatever `callbackURL` or
+ * `redirectTo` the *requesting client* supplied. Better Auth does validate those against its trusted
+ * origins, and that validation is sound — but an emailed link is the one artifact a person is most
+ * likely to click without looking, so its destination is derived here from validated configuration
+ * alone and from nothing a request could influence. The token is the only value taken from Better
+ * Auth. No request parameter can steer where a recipient lands, independently of whether the origin
+ * check behaves as expected.
+ */
+
+/** What could not be delivered, for an operator — never who it was for, and never the link. */
+export type IdentityNotificationKind = "password-reset" | "email-verification";
+
+export interface IdentityNotificationFailure {
+  readonly kind: IdentityNotificationKind;
+  /** A sanitized `MailError` code, or `MAIL_SEND_FAILED` for anything unrecognized. */
+  readonly reason: string;
+}
+
+/**
+ * Where a delivery failure is reported.
+ *
+ * It exists because these callbacks must **never throw**. Better Auth's own
+ * `/send-verification-email` rethrows whatever the callback threw, and a thrown error there turns
+ * "this address has an unverified account" into a distinguishable response — an account-enumeration
+ * oracle that appears the moment SMTP breaks. So failure is swallowed at this boundary and surfaced
+ * out of band instead, where no HTTP response shape depends on it.
+ *
+ * The default implementation writes one fixed line per failure. It carries the flow and a sanitized
+ * code and nothing else: no address, no token, no URL, no provider text.
+ */
+export type IdentityNotificationReporter = (failure: IdentityNotificationFailure) => void;
+
+export interface IdentityNotificationRecipient {
+  readonly email: string;
+  readonly name?: string;
+}
+
+export interface CreateIdentityNotificationsOptions {
+  /**
+   * The host mail provider, or `undefined` when this installation has none.
+   *
+   * `undefined` is a complete deployment (ADR 0037): the platform still runs, the initial owner
+   * still signs in, and only verification and recovery are unavailable — reported as
+   * `MAIL_NOT_CONFIGURED` through the reporter, never as a different HTTP response.
+   */
+  readonly mail: MailProvider | undefined;
+  /** Where the `/api/auth` transport lives — the origin Better Auth's own endpoints are on. */
+  readonly authBaseUrl: string;
+  /** Where a human's browser lands. Validated to be a trusted origin (`./config.js`). */
+  readonly dashboardOrigin: string;
+  /** Defaults to a single fixed sanitized console line. */
+  readonly report?: IdentityNotificationReporter;
+}
+
+export interface IdentityNotifications {
+  /** Shaped for Better Auth's `emailVerification.sendVerificationEmail`. Never throws. */
+  readonly sendVerificationEmail: (data: {
+    readonly user: IdentityNotificationRecipient;
+    readonly token: string;
+  }) => Promise<void>;
+  /** Shaped for Better Auth's `emailAndPassword.sendResetPassword`. Never throws. */
+  readonly sendResetPassword: (data: {
+    readonly user: IdentityNotificationRecipient;
+    readonly token: string;
+  }) => Promise<void>;
+}
+
+/**
+ * The two query values the Dashboard bundle reads to decide which host-owned auth screen to show.
+ *
+ * They are query parameters on the Dashboard's root path rather than distinct paths deliberately:
+ * the shell is a static single-page bundle, and a deep path would require every deployment's static
+ * host to rewrite unknown paths to `index.html` before an emailed link worked at all. A query
+ * parameter works on any static host, including the repository's own development server.
+ */
+export const DASHBOARD_AUTH_LANDING_PARAMETER = "ekklesia_auth";
+export const DASHBOARD_VERIFY_EMAIL_LANDING = "verify-email";
+export const DASHBOARD_RESET_PASSWORD_LANDING = "reset-password";
+
+function landingUrl(dashboardOrigin: string, landing: string): string {
+  const url = new URL(dashboardOrigin);
+  url.searchParams.set(DASHBOARD_AUTH_LANDING_PARAMETER, landing);
+  return url.href;
+}
+
+/**
+ * Better Auth's own verification URL, rebuilt from configuration.
+ *
+ * The shape is the pinned release's protocol exactly — `GET {authBase}/api/auth/verify-email?
+ * token=...&callbackURL=...` — so Better Auth remains the only thing that inspects, expires, or acts
+ * on the token. Only the destination is ours.
+ */
+function verificationUrl(options: CreateIdentityNotificationsOptions, token: string): string {
+  const callback = landingUrl(options.dashboardOrigin, DASHBOARD_VERIFY_EMAIL_LANDING);
+  return `${options.authBaseUrl}/api/auth/verify-email?token=${encodeURIComponent(
+    token,
+  )}&callbackURL=${encodeURIComponent(callback)}`;
+}
+
+/** Better Auth's reset callback, rebuilt the same way. It validates the token, then redirects the
+ * browser to the Dashboard landing with the token attached. */
+function resetUrl(options: CreateIdentityNotificationsOptions, token: string): string {
+  const callback = landingUrl(options.dashboardOrigin, DASHBOARD_RESET_PASSWORD_LANDING);
+  return `${options.authBaseUrl}/api/auth/reset-password/${encodeURIComponent(
+    token,
+  )}?callbackURL=${encodeURIComponent(callback)}`;
+}
+
+/** Escapes the four characters that could otherwise close an element or attribute in the HTML body.
+ * Only the link and the greeting name are interpolated, and the name comes from the user record. */
+function escapeHtml(value: string): string {
+  return value
+    .replaceAll("&", "&amp;")
+    .replaceAll("<", "&lt;")
+    .replaceAll(">", "&gt;")
+    .replaceAll('"', "&quot;");
+}
+
+/**
+ * The same rule `validateMailMessage` applies, expressed the same way it expresses it: a code-point
+ * scan rather than a regular expression, because a regex over a control-character range is itself
+ * something a linter (rightly) objects to.
+ */
+function hasControlCharacter(value: string): boolean {
+  for (const character of value) {
+    const codePoint = character.codePointAt(0);
+    if (codePoint === undefined || codePoint <= 0x1f || (codePoint >= 0x7f && codePoint <= 0x9f)) {
+      return true;
+    }
+  }
+  return false;
+}
+
+/**
+ * A greeting that is safe to place in a message body.
+ *
+ * A stored display name is not trusted to be free of control characters — the message validator
+ * would reject the whole message for one stray carriage return, which would turn a cosmetic problem
+ * into an undeliverable password reset. So an unusable name simply falls back to no greeting.
+ */
+function greeting(name: string | undefined): string {
+  if (typeof name !== "string") {
+    return "Hello,";
+  }
+  const trimmed = name.trim();
+  if (trimmed.length === 0 || trimmed.length > 64 || hasControlCharacter(trimmed)) {
+    return "Hello,";
+  }
+  return `Hello ${trimmed},`;
+}
+
+const EXPIRY_SENTENCE = "This link expires in one hour.";
+const UNEXPECTED_SENTENCE =
+  "If you did not expect this message, you can ignore it and nothing will change.";
+
+interface MessageBodies {
+  readonly subject: string;
+  readonly text: string;
+  readonly html: string;
+}
+
+function verificationBodies(name: string | undefined, url: string): MessageBodies {
+  const lead = greeting(name);
+  return {
+    subject: "Verify your Ekklesia email address",
+    html: [
+      `<p>${escapeHtml(lead)}</p>`,
+      "<p>Confirm this email address so it can be used to sign in to Ekklesia.</p>",
+      `<p><a href="${escapeHtml(url)}">Verify this email address</a></p>`,
+      `<p>${EXPIRY_SENTENCE} ${escapeHtml(UNEXPECTED_SENTENCE)}</p>`,
+    ].join("\n"),
+    text: [
+      lead,
+      "",
+      "Confirm this email address so it can be used to sign in to Ekklesia:",
+      "",
+      url,
+      "",
+      EXPIRY_SENTENCE,
+      UNEXPECTED_SENTENCE,
+    ].join("\n"),
+  };
+}
+
+function resetBodies(name: string | undefined, url: string): MessageBodies {
+  const lead = greeting(name);
+  const closing = `${UNEXPECTED_SENTENCE} Your current password stays in place until a new one is chosen.`;
+  return {
+    subject: "Reset your Ekklesia password",
+    html: [
+      `<p>${escapeHtml(lead)}</p>`,
+      "<p>Someone asked to reset the password for this Ekklesia account.</p>",
+      `<p><a href="${escapeHtml(url)}">Choose a new password</a></p>`,
+      `<p>${EXPIRY_SENTENCE} ${escapeHtml(closing)}</p>`,
+    ].join("\n"),
+    text: [
+      lead,
+      "",
+      "Someone asked to reset the password for this Ekklesia account. Choose a new one here:",
+      "",
+      url,
+      "",
+      EXPIRY_SENTENCE,
+      closing,
+    ].join("\n"),
+  };
+}
+
+function defaultReporter(failure: IdentityNotificationFailure): void {
+  // One fixed line. The flow and a sanitized code are exactly what an operator needs in order to go
+  // look at `pnpm doctor`; the address, the token, and the link are exactly what must never be here.
+  console.error(`[identity] ${failure.kind} email was not delivered: ${failure.reason}`);
+}
+
+function failureReason(error: unknown): string {
+  return error instanceof MailError ? error.code : "MAIL_SEND_FAILED";
+}
+
+/**
+ * Builds the two Better Auth callbacks.
+ *
+ * Neither rejects. A delivery failure is reported through `report` and the callback resolves, so the
+ * HTTP response an unauthenticated caller sees is identical whether the address exists, whether it
+ * was already verified, and whether the relay was reachable.
+ */
+export function createIdentityNotifications(
+  options: CreateIdentityNotificationsOptions,
+): IdentityNotifications {
+  const report = options.report ?? defaultReporter;
+
+  const deliver = async (
+    kind: IdentityNotificationKind,
+    recipient: IdentityNotificationRecipient,
+    bodies: MessageBodies,
+  ): Promise<void> => {
+    if (!options.mail) {
+      report({ kind, reason: "MAIL_NOT_CONFIGURED" });
+      return;
+    }
+    try {
+      await options.mail.send(
+        validateMailMessage({
+          html: bodies.html,
+          subject: bodies.subject,
+          text: bodies.text,
+          to: recipient.email,
+        }),
+      );
+    } catch (error) {
+      report({ kind, reason: failureReason(error) });
+    }
+  };
+
+  const notifications: IdentityNotifications = {
+    sendResetPassword: async (data) => {
+      await deliver(
+        "password-reset",
+        data.user,
+        resetBodies(data.user.name, resetUrl(options, data.token)),
+      );
+    },
+    sendVerificationEmail: async (data) => {
+      await deliver(
+        "email-verification",
+        data.user,
+        verificationBodies(data.user.name, verificationUrl(options, data.token)),
+      );
+    },
+  };
+  return Object.freeze(notifications);
+}

core/src/identity/runtime.ts

@@ -9,6 +9,7 @@ import { getCookies } from "better-auth/cookies";
 import { sql } from "drizzle-orm";
 import type { IdentityConfig } from "./config.js";
 import type { IdentityDrizzleDatabase } from "./database.js";
+import type { IdentityNotifications } from "./notifications.js";
 import { ekklesiaCoreSession, identityAdapterSchema } from "./schema.js";
 
 export type IdentityRuntimeErrorCode =
@@ -46,6 +47,16 @@ export const TRUSTED_CLIENT_ADDRESS_HEADER = "x-ekklesia-client-address";
  */
 const sanitizedBetterAuthLogMessage = "[identity] Better Auth reported an error.";
 
+/**
+ * One hour for both, matching the pinned release's own defaults but stated rather than inherited.
+ *
+ * Short enough that a link sitting in a forwarded or archived mailbox stops working, long enough
+ * that someone who reads their mail after lunch is not sent back to the start. The message bodies
+ * state the same hour, so the two can be checked against each other.
+ */
+const EMAIL_VERIFICATION_TOKEN_TTL_SECONDS = 3600;
+const RESET_PASSWORD_TOKEN_TTL_SECONDS = 3600;
+
 /**
  * Explicitly replaces Better Auth's default logger so its own message text and arguments — which
  * may include a raw exception, SQL, a connection string, a host/port, a filesystem path, a
@@ -82,10 +93,29 @@ export interface CreateIdentityRuntimeOptions {
   readonly config: IdentityConfig;
   readonly db: IdentityDrizzleDatabase;
   /**
-   * A narrow, explicit override for the sign-in/sign-up rate-limit window used only by test
-   * composition that issues many such requests quickly. Rate limiting itself is always enabled;
-   * production composition must leave this unset so Better Auth's own strict built-in default
-   * (3 requests / 10 seconds on sign-in and sign-up) applies unmodified.
+   * How verification and password-reset messages are delivered.
+   *
+   * Injected rather than constructed here, for the same reason the database is: this file composes
+   * Better Auth and must not decide what a message says or how it travels. Omitting it is a
+   * complete, valid deployment — email verification and password recovery are then configured
+   * exactly as they otherwise are, and each attempt reports `MAIL_NOT_CONFIGURED` out of band while
+   * every HTTP response keeps its usual shape (ADR 0038).
+   *
+   * Note what omitting it does **not** do: it does not relax `requireEmailVerification`. An
+   * installation with no mail cannot verify a new account, which is why the initial platform owner
+   * is created already verified by a trusted operator command rather than by an email round trip.
+   */
+  readonly notifications?: IdentityNotifications;
+  /**
+   * A narrow, explicit override for the rate-limit windows on the four paths Better Auth treats
+   * more strictly than its global default, used only by test composition that issues many such
+   * requests quickly. Rate limiting itself is always enabled; production composition must leave this
+   * unset so Better Auth's own built-in defaults apply unmodified — 3 requests / 10 seconds on
+   * sign-in and sign-up, and 3 requests / 60 seconds on password-reset requests and verification
+   * resends, which are the two paths an attacker could otherwise use to send mail repeatedly.
+   *
+   * That limiter is per-process and in-memory (ADR 0038): it is a real abuse control for a single
+   * deployment and is deliberately **not** claimed to be a distributed one.
    */
   readonly rateLimitOverride?: IdentityRateLimitOverride;
 }
@@ -264,9 +294,81 @@ export function createIdentityRuntime(
       enabled: true,
       // Pinned explicitly rather than left on Better Auth's fallback default (`|| 8` / `|| 128`
       // in the pinned release): an implicit default can change silently on a future Better Auth
-      // upgrade, and Ekklesia's own tests assert this exact 8–128 boundary.
+      // upgrade, and Ekklesia's own tests assert this exact 8–128 boundary. The reset endpoint
+      // enforces the identical pair from the same configuration, so there is deliberately no
+      // separate reset-time password policy.
       maxPasswordLength: 128,
       minPasswordLength: 8,
+      /**
+       * A person may not hold a session until their address is verified (ADR 0038).
+       *
+       * In the pinned release this is enforced *after* the password is checked and *before* any
+       * session is created: the attempt fails with `403 EMAIL_NOT_VERIFIED` and no cookie is set.
+       * That is the whole reason no "unverified principal" exists anywhere in this platform — a
+       * correct password on an unverified account produces no session at all, so there is no
+       * half-authenticated state for the Dashboard to misread. `/api/v1/principal` continues to
+       * describe only anonymous, authenticated human, and device.
+       */
+      requireEmailVerification: true,
+      /** Pinned rather than left on the release's `|| 3600` fallback, for the same reason the
+       * password bounds are pinned. */
+      resetPasswordTokenExpiresIn: RESET_PASSWORD_TOKEN_TTL_SECONDS,
+      /**
+       * Every existing session for that account is deleted when its password is reset.
+       *
+       * Password reset is the recovery path someone uses precisely when they suspect their
+       * credential is compromised, and leaving the attacker's session alive would make the recovery
+       * cosmetic. This is Better Auth's own supported option (`deleteUserSessions` in the pinned
+       * release), not a Core reach into the session table.
+       *
+       * It deletes *all* of that human's sessions, including the browser that performed the reset —
+       * so the completion state returns to the sign-in form rather than pretending to be signed in.
+       * Managed device sessions are a separate Ekklesia store keyed by device, hold no email and no
+       * password, and are entirely unaffected (ADR 0036).
+       */
+      revokeSessionsOnPasswordReset: true,
+      ...(options.notifications
+        ? { sendResetPassword: options.notifications.sendResetPassword }
+        : {}),
+    },
+    /**
+     * Verification is configured identically whether or not mail is deliverable, so the policy an
+     * installation enforces never depends on the state of its relay.
+     */
+    emailVerification: {
+      /**
+       * No session is minted from following an emailed link.
+       *
+       * A verification URL travels through mail infrastructure and is routinely fetched by things
+       * that are not the recipient — link scanners, prefetchers, corporate mail gateways. Turning
+       * that GET into a logged-in browser session would hand a session to whoever, or whatever,
+       * dereferenced the link. Verification therefore only flips the flag, and the person signs in
+       * afterwards through the ordinary form.
+       */
+      autoSignInAfterVerification: false,
+      /** Pinned rather than left on the release's `|| 3600` fallback. */
+      expiresIn: EMAIL_VERIFICATION_TOKEN_TTL_SECONDS,
+      /**
+       * A sign-in attempt against an unverified account re-sends the verification message.
+       *
+       * This is the resend path that costs nothing to secure: reaching it requires the correct
+       * password, so it reveals nothing an attacker did not already know, and it means the common
+       * case — the first link expired — is handled by the thing the person was already trying to do.
+       * The standalone `/send-verification-email` endpoint remains available for the case where they
+       * would rather not retype a password, and is enumeration-safe on its own.
+       */
+      sendOnSignIn: true,
+      /**
+       * Pinned rather than left on the release's "follow `requireEmailVerification`" fallback.
+       *
+       * It reaches nothing in production, where signup is refused outright — but stating it means a
+       * development or test deployment that does enable signup behaves the way this platform
+       * intends, rather than the way an inherited default happens to.
+       */
+      sendOnSignUp: true,
+      ...(options.notifications
+        ? { sendVerificationEmail: options.notifications.sendVerificationEmail }
+        : {}),
     },
     logger: {
       disabled: false,
@@ -293,6 +395,18 @@ export function createIdentityRuntime(
       ...(rateLimitOverride
         ? {
             customRules: {
+              // The four paths Better Auth applies a stricter-than-global default to. Production
+              // composition never sets this override, so those defaults — 3 requests / 10 seconds
+              // on sign-in and sign-up, 3 requests / 60 seconds on the two paths that trigger an
+              // email — remain in force there, unmodified.
+              "/request-password-reset": {
+                max: rateLimitOverride.max ?? 100,
+                window: rateLimitOverride.window ?? 10,
+              },
+              "/send-verification-email": {
+                max: rateLimitOverride.max ?? 100,
+                window: rateLimitOverride.window ?? 10,
+              },
               "/sign-in/email": {
                 max: rateLimitOverride.max ?? 100,
                 window: rateLimitOverride.window ?? 10,