docs(mail): the Sweego key is fine — authorisation is per-domain, not per-address #382

Sammanfogat

supernaut sammanfogade 1 incheckning från docs/mail-block-tightened in i main

2026-08-05 14:41:27 +00:00

supernaut kommenterad

2026-08-05 14:39:07 +00:00

Ägare

Narrows yesterday's block (#381). The previous note speculated the API key might be bound to a sending identity and need re-scoping or re-minting. It does not — that speculation is removed rather than softened.

Authorisation is per-domain

The discriminating test is a local part that has never been used through the API, on the known-good domain:

From	result
`alerts@mail.gitborg.se` — brand-new local part	HTTP 200, sends immediately
`no-reply@email.bitborg.se`	HTTP 401 `{"detail":"Unauthorized"}`

So any address under an authorised domain works, and the only thing email.bitborg.se lacks is that authorisation. No vault edit, no new key.

Alternatives ruled out

Not ordering or rate limiting — the new domain 401s when sent first, and the old domain returns 200 mid-sequence.
Not flapping — 401 again on repeat within one run.
Not the payload — the two requests are byte-identical apart from the From address (the first probe had also varied subject and body; this one does not).

The domain is not unknown to Sweego

Only these two carry DKIM CNAMEs, each with its own account token:

email.bitborg.se   ae4a3bca-…-dkim.sweego.co.
mail.gitborg.se    d65c0acd-…-dkim.sweego.co.

A distinct token means email.bitborg.se has its own registration, so what is missing is its state, not its existence.

Corroborated by response shape: the gateway answers {"error_msg":"404 Route Not Found"} for routes that do not exist, whereas /send answers {"detail":"Unauthorized"} — the shape authenticated routes use. Sweego accepted the key and then refused the sender.

Why this stays a runbook step

There is no API surface for any of it. /domains, /senders, /sending-domains, /identities, /account, /me, /v1/domains, /domain, /sending_domains, /transac/domains — all 404. It cannot be inspected or fixed from a host, so unblocking is a dashboard action: complete the domain's validation, or confirm it lives in the same project/workspace as the key.

Narrows yesterday's block (#381). The previous note speculated the API key might be bound to a sending identity and need re-scoping or re-minting. **It does not** — that speculation is removed rather than softened. ## Authorisation is per-domain The discriminating test is a local part that has never been used through the API, on the known-good domain: | From | result | | --- | --- | | `alerts@mail.gitborg.se` — brand-new local part | **HTTP 200**, sends immediately | | `no-reply@email.bitborg.se` | **HTTP 401** `{"detail":"Unauthorized"}` | So any address under an authorised domain works, and the only thing `email.bitborg.se` lacks is that authorisation. **No vault edit, no new key.** ## Alternatives ruled out - **Not ordering or rate limiting** — the new domain 401s when sent *first*, and the old domain returns 200 mid-sequence. - **Not flapping** — 401 again on repeat within one run. - **Not the payload** — the two requests are byte-identical apart from the From address (the first probe had also varied subject and body; this one does not). ## The domain is not unknown to Sweego Only these two carry DKIM CNAMEs, each with its **own** account token: ```text email.bitborg.se ae4a3bca-…-dkim.sweego.co. mail.gitborg.se d65c0acd-…-dkim.sweego.co. ``` A distinct token means `email.bitborg.se` has its own registration, so what is missing is its **state**, not its existence. Corroborated by response shape: the gateway answers `{"error_msg":"404 Route Not Found"}` for routes that do not exist, whereas `/send` answers `{"detail":"Unauthorized"}` — the shape authenticated routes use. **Sweego accepted the key and then refused the sender.** ## Why this stays a runbook step There is no API surface for any of it. `/domains`, `/senders`, `/sending-domains`, `/identities`, `/account`, `/me`, `/v1/domains`, `/domain`, `/sending_domains`, `/transac/domains` — all 404. It cannot be inspected or fixed from a host, so unblocking is a dashboard action: complete the domain's validation, or confirm it lives in the same project/workspace as the key.

supernaut lade till 1 incheckning

2026-08-05 14:39:07 +00:00

docs(mail): the Sweego key is fine — authorisation is per-domain, not per-address

ci / ci (pull_request) Successful in 1m39s

Detaljer

915a2ea264

Narrows yesterday's block. The previous note speculated that the API key might be bound to
a sending identity and need re-scoping or re-minting. It does not, and that speculation is
removed rather than softened.

Authorisation is PER-DOMAIN. The discriminating test is a local part that has never been
used through the API, on the known-good domain:

alerts@mail.gitborg.se -> HTTP 200 (brand-new local part, sends immediately)
no-reply@email.bitborg.se -> HTTP 401 {"detail":"Unauthorized"}

So any address under an authorised domain works, and the only thing email.bitborg.se lacks
is that authorisation. Ordering, rate limiting, flapping and payload are ruled out: the new
domain 401s when sent FIRST, 401s again on repeat within one run, and the two requests are
byte-identical apart from the From address while the old domain returns 200 mid-sequence.

The domain is also not unknown to Sweego. Only mail.gitborg.se and email.bitborg.se carry
DKIM CNAMEs and each has its own account token, so the new domain has its own registration
— what is missing is its STATE, not its existence. Corroborated by the response shape: the
gateway answers {"error_msg":"404 Route Not Found"} for routes that do not exist, whereas
/send answers {"detail":"Unauthorized"}, the shape authenticated routes use. Sweego
accepted the key and then refused the sender.

Records that there is no API surface for any of this — /domains, /senders,
/sending-domains, /identities, /account, /me, /v1/domains, /domain, /sending_domains and
/transac/domains all 404 — which is why unblocking is a dashboard step in a runbook rather
than a task in this repo, and why no vault edit should be expected.

supernaut sammanfogade incheckning 0495be740a till main

2026-08-05 14:41:27 +00:00

supernaut refererade denna ändringsförfrågan från en incheckning

2026-08-05 14:41:28 +00:00

docs(mail): the Sweego key is fine — authorisation is per-domain, not per-address (#382)

supernaut refererade denna ändringsförfrågan från en incheckning

2026-10-02 17:56:57 +00:00

docs(mail): the Sweego key is fine — authorisation is per-domain, not per-address (#382)

Logga in för att delta i denna konversation.

Inga granskare