tegwick
48823c8182
Assistant: codex Assistant-Model: gpt-6.1-sol Assistant-Session: 01a119cf-56d0-7fa3-840b-eb8732e1db0b
5.5 KiB
Scoped transactional callers — source review, 2026-10-08
The receiver can isolate explicitly admitted callers while retaining the existing single-caller startup path until deployment admission. The initial source increment changed no runtime. The tested image is now deployed in the existing single-caller mode; see caller-deployment-2026-10-08.md. Scoped policy admission and new caller activation remain separate.
Set EMAIL_CONNECT_CALLERS_FILE to an owner-controlled read-only JSON policy file. If present, invalid policy fails startup before ledger migration; there is no fallback to EMAIL_CONNECT_INGEST_TOKEN. Schema version1 has a callers list (1–32). Each entry needs caller_id, source, absolute token_file, bindings (exact [tenant, client] pairs), operations, templates, rate_per_minute, burst and max_payload_bytes. Credentials are independently delivered files; inline tokens, shared tokens and duplicate caller IDs are rejected. Tokens never enter policy receipts or repr output. Limits are positive integers: rate <=6000/minute, burst <=600 requests, payload <=128KiB. These are implementation ceilings, not approved runtime quotas.
Operations: send, delivery-status, status, verify, consume, cancel, suppress, unsuppress. Send templates are only family_member.invited and family_invitation.resent. Payload source must match the authenticated policy; verification and invitation tenant/client pairs must be explicitly admitted. Each caller's invitation IDs, verification reservations and handles are isolated. An event's immutable payload cannot change on retry. Status exposes a caller-local opaque reference and transport evidence, never raw provider diagnostics. Confirmed temporary non-acceptance can retry; permanent rejection is terminal; uncertain acceptance remains terminal for automatic retry across restart. Historical failed invitations lacking retry evidence also remain terminal.
A persisted atomic SQLite token bucket counts authorized requests, including status, validation failures and duplicates. Concurrent connections and restarts share its allowance. Changing caller identity resets its budget; admission must treat that as a quota/security change. Backward wall-clock movement grants no extra tokens. Oversized requests are rejected before reading their bodies. Public health only proves receiver liveness; authenticated status is separately admitted and consumes allowance.
Suppression is global recipient protection. suppress/unsuppress are privileged platform operations, to admit only for a named operations owner, never generic application callers. They do not inspect mailboxes or automatically classify bounces. Sender identity/TLS remain governed by the existing SMTP provider; caller policy does not grant arbitrary subjects/bodies/From or a bulk-mail API.
Existing original caller and rollback
Only caller_id/source user-engine may explicitly adopt legacy verification rows (adopt_legacy_verifications=true). Its granted binding pairs still constrain consume/cancel. legacy_invitation_binding may explicitly admit one binding for old invitation payloads lacking tenant/client, and preserves old event keys and accepted receipts. Reserved ec2_ input IDs cannot collide with scoped storage IDs. There is no inferred legacy adoption. Removing or narrowing a policy immediately denies its operations without deleting transport/idempotency evidence.
Startup adds caller_id to verification rows, error/retryable to send_attempts, and caller_buckets. Capture fingerprints include all six tables; old five-table captures remain readable. Rehearsal source preserves scoped accepted/uncertain verification reservations and budgets without provider calls. Capture/rehearsal helper source pins are repinned together to the deployed eb3e7b68 immutable image. Their current guarded capture still requires explicit archive admission; scoped policy activation remains a separate operation. Do not downgrade after new-schema rows exist without an admitted compatible recovery plan; old receiver code can lose retry restrictions or fail inserts.
Validation and outstanding admission
Synthetic caller/legacy tests:66 passed, zero skips, network-denied app gate. Full owner suite including loopback GreenMail and scoped ledger rehearsal: 148 passed, zero skips. Receiver/caller module and caller-test Ruff checks pass. No live recipient, identity, token, handle or message body is a fixture.
EMAIL-WP-0008-T03 retains admission: choose actual caller/binding/template and operation sets, quotas, separate token custody/delivery, original-user-engine transition, platform sender/reply/bounce responsibilities, exact image/schema rollout and rollback, and independent ledger offsite recovery. Existing live EMAIL-WP-0007-T03/T04 and RPF-WP-0053-T05/T06 retain archive admission and atomic credential-pair custody. CSOC-WP-0015-T01/T02/T04 retain productive flow and owner-spanning browser acceptance. Source checks alone close none of these gates.
Original product-workplan closure — 2026-10-08
The user explicitly closed CSOC-WP-0008 and CSOC-WP-0010 after registering residual workplans. They are finished historical records, no longer acceptance trackers. Product communication execution and acceptance now belong to CSOC-WP-0015; EMAIL-WP-0008-T03, EMAIL-WP-0007 and RPF-WP-0053 retain their canonical runtime/custody tasks. Existing personal recovery acceptance and the receiver revision7 deployment remain evidenced. No pending owner requirement is waived or marked satisfied by the original workplans' administrative closure.