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](email-connect-smtp-foundation-review-2026-10-31.md).
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](credential-change-approval.md)
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.