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.
129 lines
4.2 KiB
Markdown
129 lines
4.2 KiB
Markdown
# 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.
|
|
|
|
---
|