railiance-platform/docs/email-connect-smtp-admission-2026-10-31.md

Email-connect platform mailbox reader preparation

CCR-2026-0056 proposes one additional reader of the existing platform SMTP entry. RPF-WP-0068 tracks preparation, foundation/binding proof, attended admission and native consumer delivery. The parent requirement is CSOC-WP-0015-T02.

The complete controller is now prepared in the foundation packet. Its41 SMTP tests pass. Execution still awaits review/approval. The dedicated service account/store/projection have only passed server dry-run. Native binding is not confirmed, the CCR is proposed, and no new policy or role has been installed.

Exact proposed authority

The Kubernetes role and policy are email-connect-platform-smtp-eso, bound only to the same-named service account in namespace email-connect, audience openbao, TTL/max/explicit-max15m, with no default policy. The policy reads only platform/data/workloads/railiance-telemetry/smtp plus self lookup/revoke. There is no metadata, list, write, sibling-path or administrative authority.

OpenBao grants access to the exact KV record, not individual fields. The consumer ExternalSecret projects only SMTP_PASSWORD. Existing telemetry and Authelia readers remain separate and unchanged. No mailbox value is copied, created or rotated. The custody helper does not access IMAP or submit an email.

User decision9392ef52 names platform-root and Bernd as return-mail owner/operator. It is not approval of this new credential reader. The existing Authelia approval also does not grant an additional consumer. The CCR workflow requires approved requests and confirmed native bindings before apply; shared readers are outside its automatic standard-lane profile.

Implemented helper

scripts/email_connect_smtp_delivery.py defaults to an offline proposal. Its digest binds the complete functional CCR scope, exact role/policy, seven source files and observed OpenBao clusterfd28df5d. Approval comments/status and the native binding-confirmation marker do not change that functional digest; execution separately requires status approved and binding confirmed.

The helper runs silently within the existing Warden attended platform-admin login envelope. Before any mutation it requires the pinned initialized/unsealed OpenBao instance, platform-admin without root, existing exact agent denial, and nondivergent new reader targets. It snapshots the existing telemetry/Authelia roles and policies plus the agent boundary. Existing mailbox settings/password are validated privately; only fixed receipt fields and version may leave.

It reuses the existing telemetry lane for certificate-verified STARTTLS AUTH, exact role/policy admission and coding-agent denial/revocation proof. It then compares all protected metadata and complete mailbox data/version with the preimage. Drift or a failed check prevents a verified result. It does not modify the shared helper or the existing admission lanes.

The receipt is a new mode0600 JSON Lines journal in an existing caller-owned private directory. It fsyncs the initial record and directory before owner calls, then appends an admitting/unconfirmed record before the shared lane runs. Final success/failure is appended rather than overwriting prior checkpoints. A process interruption can leave an incomplete last line; inspect the last complete record and native state, not merely the process exit code. Existing receipt paths refuse. No automatic rollback or retry is attempted after an uncertain admission.

A successful custody result is reader_admitted_verified. It deliberately keeps native_consumer_auth_verified, projection_ready, kubernetes_resources_installed and application_sender_changed false: these are separate native returns, not claims inferred from role configuration. Warden must also report successful session revocation/cleanup; a successful child receipt cannot override an unconfirmed owner session.

Validation

python3 -m unittest discover -s tests -p 'test_*smtp*.py' -q passes29 tests, including15 new fixed-consumer cases. They cover contract/approval/binding/digest refusal; wrong instance/sealed/root; unchanged readers and mailbox; divergent role/policy refusal before creation; idempotent existing exact admission; private append-only receipts; interruption; silent refusal and output containment. Provider/Bao calls are synthetic; no native credential was fetched.

CCR validation passes with the intentional unconfirmed-binding warning. Default proposal and Python compilation pass. Source hashes, proposal and observation are in docs/evidence/email-connect-smtp-admission-preparation-2026-10-31.json.

Remaining sequence

1. Complete the supervised foundation/projection controller, including native identity checks, progress receipts and failure inspection. The current consumer candidate has three new objects and two later sender patches; only the first three belong to this custody workplan.
2. Present the complete scope for CCR approval. Install and verify the reviewed dedicated service account through the attended path, then confirm its native binding using the existing owner workflow.
3. After approved CCR and confirmed binding, execute this silent helper through warden access openbao-platform-admin-login --exec -- <reviewed owner command>. Use an absolute private receipt path because Warden uses an isolated HOME. Do not execute now: the guards currently refuse before owner operations.
4. Verify actual scoped login and ESO delivery, retain denied-other-consumer evidence, and record this third consumer in shared-mailbox rotation inventory.
5. The consumer owner performs its separate supervised sender rollout and productive message/inbox/return-handling acceptance under CSOC-WP-0015-T02.

No new destination approval or reapproval of platform-root ownership is needed.