Make company email sign-in, encryption and recovery declarative

🤖 Generated by the Agentic Engineer

Problem

The maintainer wants company email sign-in integrated with the existing identity provider, mailbox encryption at rest, and a service that can be rebuilt from reviewed configuration after an incident. The Homepage must list Stalwart with its logo under the Email section.

Expected outcome

Use the maintainer's existing mailbox for normal administration when supported, with a tested recovery path before retiring a separate administrator. Manage supported settings declaratively and retain required private keys and recovery material in approved private custody.

Acceptance criteria

The Stalwart entry appears with its logo in the declared Email section, with matching dashboard admission rules and observed browser navigation.
Dedicated OIDC client and native mail authentication configuration are declarative. Verify issuer, audience, identity mapping and denied identities; observe the maintainer's real sign-in without reading tokens or credentials into chat or logs.
The maintainer's mailbox can administer the server. Decide the separate administrator's lifecycle from tested normal and recovery access, preserving automation privileges and the restricted agent account.
Encrypt the persistent server storage for company email while ordinary mail clients read messages normally, without requiring per-client S/MIME identities. Manage operational encryption keys through approved private custody and verify safe migration of existing data, new delivery and actual backup restoration. Document the exact protection, limitations and independent bootstrap needed to recover the secrets service.
Move the three durable credentials into infrastructure/email/... in OpenBao through reviewed configuration. Copy and compare the current values before switching consumers; retain recovery history and refuse conflicting destination values. Use company email wording in operator documentation without replacing retained mailbox storage.
Reapply desired state without duplicating accounts or erasing mailbox history, personal keys, app credentials or unrelated data. Rebuild and restore from the declared configuration plus approved recovery material; verify readback and fail on drift.
Pass current-head validation, substantive review, protected merge and deployed checks. No click-based configuration or secrets in public artifacts.

Part of #5030.

References

🔗 Related PRs

#5388 - feat(email): prepare Email credential custody and recovery [merged]
#5533 - feat(email): move active credentials and recovery to infrastructure [merged]
#5503 - fix(email): preserve client credentials during configuration replay [merged]
#5493 - fix(email): verify backups using the declared credential format [merged]
#5351 - feat(mail): activate Stalwart administration and Homepage entry [merged]
#5482 - fix(homepage): show Stalwart with its logo under Email [merged]

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

Create Plan

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

chore: agent-claim #5387 nonce=19ac629cf9b03f852fddc03f94f0f00b

fix(mail): declare the authentication recovery baseline

feat(email): name company email consistently on Homepage

feat(email): prepare durable credential relocation

🤖 Generated by the Agentic Engineer

Recovery acceptance now explicitly includes the maintainer's requirement that Email encryption identities and their unlocking material remain recoverable without the original client computer or cluster. A local keychain alone is insufficient. Preserve the original identity and historical decryption keys; generating a replacement does not prove recovery.

The original identity's client import and a synthetic encrypted-message decryption have been observed. Independent retrieval of the encrypted package and its unlocking material still needs confirmation before encryption activation or any retirement of existing access. Keep secret values, private storage references and recovery material out of this issue.

🤖 Generated by the Agentic Engineer

The maintainer clarified the intended behavior: encrypt server storage while ordinary mail clients read messages normally, without installing per-client decryption identities. Recovery records should have their canonical home in OpenBao.

Stalwart's per-account S/MIME feature does not provide that experience: it stores encrypted messages that require the matching private key in each client. Do not activate that feature as the implementation of this requirement. The completed local identity round-trip is therefore preparation evidence, not acceptance of the requested storage encryption.

Continue with declarative transparent storage encryption, preserve existing data through migration, and prove restore before retiring the old copies. Operational recovery records belong in OpenBao; the independent bootstrap needed to recover OpenBao itself must remain recoverable outside that service.

chore: agent-claim #5387 nonce=69e36ed5a0ecfd6e4d1e6eb2dd760de8

chore: agent-claim #5387 nonce=7d43aa2f44f1d2e7679ce0291fe2928a

chore: agent-claim #5387 nonce=1dee9feba7d8dbff5d97c8882fd40625

chore: agent-claim #5387 nonce=29feebcadf52ab3eef6ad78a8bf6542a

chore: agent-claim #5387 nonce=d781f4617dd39f545771d3703eeb6622

test(email): use a non-secret readback fixture identifier

🤖 Generated by the Agentic Engineer

A fresh live WebUI sign-in with the existing maintainer account succeeded through the public Email URL, using its current credential from approved custody without exposing it. The account menu identified the maintainer and the account settings page rendered. The separate management route redirected to account settings, and only the Account section was available. This proves normal account sign-in; maintainer administration and the dedicated identity-provider rollout remain unverified. Preserve the separate administrator and recovery access until that replacement path passes.

The per-account encryption setting was observed Disabled, as expected for the chosen transparent server-storage design. No account or encryption settings were changed. Encrypted serving-storage activation remains held on the mailbox recovery evidence in #5578. The existing serving instance remained ready with zero restarts during this observation. This is one authenticated client path, not the complete transport or independent-client acceptance.

🤖 Generated by the Agentic Engineer

The retained administrator path was also exercised successfully: existing-custody sign-in completed, the Management section was available, and the user-management page rendered. Read-only account inspection is consistent with the maintainer currently having ordinary mailbox access. No account, credential, role or encryption configuration was edited. Keep this administrator path until the maintainer's replacement administration and recovery checks pass.

This supplements the maintainer sign-in observation; dedicated identity-provider activation, encrypted serving-storage recovery and full mail transport acceptance remain open.

Navigation Menu

Repository navigation

Make company email sign-in, encryption and recovery declarative #5387

Problem

Expected outcome

Acceptance criteria

References

26 remaining items

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Make company email sign-in, encryption and recovery declarative #5387

Description

Problem

Expected outcome

Acceptance criteria

References

Activity

coderabbitai commented on Oct 26, 2026

devantler commented on Oct 27, 2026

devantler commented on Oct 27, 2026

26 remaining items

devantler commented on Nov 3, 2026

devantler commented on Nov 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions