tegwick
04897a149f
Ship the railiance01 deploy package (OpenBao/ESO custody, NetworkPolicy, probes), provider failure classification and suppression, T04 unit and live proof, and non-secret NK-WP-0024 hand-back evidence. Workplan finished.
4.2 KiB
Decision Log
Auto-generated by the Custodian State Hub.
Defer daily send-quota privilege tiers (anti-spam / abuse)
Date: 2026-08-12
Decided by: human (via agent note)
Status: deferred — do not implement in EMAIL-WP-0004
Idea
Outbound email is high-abuse surface if credentials or a caller is compromised. The platform should treat daily send volume as a privilege, not an unlimited side effect of holding a send token.
Proposed daily ceilings (per sender / tenant / grant — exact subject TBD):
| Tier | Mails / day |
|---|---|
| minimal | 10 |
| low | 100 |
| standard | 1_000 |
| elevated | 10_000 |
| high | 100_000 |
| bulk-capable | 1_000_000 |
| unlimited | unlimited (explicit break-glass only) |
Default for ordinary transactional use (e.g. invitation/verification) should land at the low end of the scale until a use case justifies more.
Why not now (EMAIL-WP-0004)
Current scope is a single approved caller (user-engine), fixed templates, NetworkPolicy ingress lock, and one shared ingest bearer. Abuse surface is real but narrow. Building the full tier model inside T03 custody/deploy or T04 failure proof would delay the invitation path without a multi-tenant grant story.
Existing interim controls that stay:
- template allow-list (no arbitrary body/sender)
- NetworkPolicy: user-engine only
- bearer ingest token (OpenBao custody, CCR-2026-0010)
- idempotency on event id
When to revisit
Promote to a dedicated workplan when any of:
- a second caller / tenant may send through email-connect
- the ingest token is treated as a long-lived platform grant
- marketing-adjacent or high-volume notification use appears
- flex-auth or credential-broker can bind a send quota claim to the caller
Design sketch for later (not committed)
- Enforce in email-connect at accept time (before provider call), with a durable counter (not only in-process).
- Classify over-quota as permanent denial for the day (or retryable after window), redacted diagnostics, no SMTP detail leak.
- Bind tier via platform auth/grant (flex-auth / OpenBao policy metadata / caller registration), not a free-form request field the client can raise.
- Unlimited is operator-issued break-glass, audited, not a default.
- Coordinate with suppression/complaint handling so quota and reputation share one abuse narrative.
Home for implementation later
New workplan under email-connect (suggested slug theme:
send-quota-privilege-tiers / EMAIL-WP-00xx), with a hand-off to
flex-auth / railiance-platform if the tier is a platform grant claim rather
than a local ConfigMap.
Operate at build-stage security posture; defer production policy enforcement
Date: 2026-07-02
Decided by: human
We are in build stage with the infrastructure as a whole. We will tighten security step by step but it is not yet strictly necessary.
SECRETS-WP-0004 — approve warden-sign auth-capability lane prod apply
Date: 2026-07-02
Decided by: human
I want to move to more automation, this is one step needed to go on.
Defer consumer-side contract-parity drift mode (WHYNOT-WP-0003 T09)
Date: 2026-07-02
Decided by: human
Sufficient for now
DR-3: External identity path for business clients (lightweight vs NK-WP-0011 Keycloak)
Date: 2026-07-09
Decided by: human
We will go with A for the lightweigt version and just follow up with B if we meet actual demand later.
DR-1: Tenancy model for vergabe-teilnahme commercial offering
Date: 2026-07-09
Decided by: human
We will do C and allow for early customers to easy starting serving customere but move on to resource cost optimization early.
DR-2: coulomb.social rebuild architecture (Core Hub extension vs standalone app)
Date: 2026-07-09
Decided by: human
We will go for B as Coulomb Social is it's own Application. Managed by connecting it with our infrastructure but destinct in its purpose and operations model. It is an Application for the Binky Hedgehog GmbH as another App might be provided to other clients. It should not be relevant the the ecosystem as a whole is provided by Binky Hedgehog as the organization creating coulomb and holding the domain and forgejo repos.