# Tenant email SES spike

> **For agentic workers:** this is a spike, not a build. Its output is
> four answers written back into the spec, and throwaway AWS resources
> deleted at the end. Do not keep the code.

**Goal:** Answer the four AWS questions the sender design depends on,
against the Tito deployment's real SES account, before any plan is
written for steps 2 and 3.

**Spec:** `docs/superpowers/specs/2026-09-15-tenant-email-senders-design.md` §4

**Tech stack:** `aws` CLI (SES v2, IAM), a throwaway domain the Tito
deployment already controls, Python `smtplib` for the SMTP sends.

## Global constraints

- Region `eu-west-1`, AWS account 665106592142 (the Tito deployment).
- **Never touch `tito.io`, `mail.tito.io`, or any identity Classic
  owns.** The spike's identity is a fresh subdomain created for it.
- `aws --profile` for assumed roles needs `~/.aws/cli/cache`, which the
  sandbox blocks — run those commands with the sandbox off.
- The SES control plane is throttled to one request per second; space
  the calls.
- Everything created here is deleted in step 5, including the IAM user
  and its access key.

## Setup

- [ ] **Create the throwaway identity.** A subdomain of a domain the
  deployment controls, e.g. `spike.<a domain you own>`. Verify DKIM the
  normal way and wait for `GetEmailIdentity` to report
  `DkimAttributes.Status = SUCCESS`. Do **not** set a custom MAIL FROM:
  the spike needs an identity shaped like `tito.io`, which has none.
- [ ] **Create two configuration sets**, `spike-owned` and `spike-other`,
  each with an SNS event destination on a throwaway topic you can read.
- [ ] **Bind `spike-other` as the identity's default configuration set**
  with `PutEmailIdentityConfigurationSetAttributes`. This models
  Classic's set: one CARLOS is not allowed to change.
- [ ] **Create a tenant** `spike-tenant` with `CreateTenant`; record
  `TenantArn`. Associate the identity and `spike-owned` with it using
  `CreateTenantResourceAssociation`. Do **not** associate `spike-other`.
- [ ] **Create an IAM user** with one inline policy, one access key, and
  derive its SMTP password (the repo's `SMTPPassword` is
  `internal/mail/smtppass.go:37`; a small Go program calling it is the
  quickest route). Policy:

```json
{"Version":"2012-10-17","Statement":[{"Effect":"Allow",
 "Action":"ses:SendRawEmail",
 "Resource":["<identity ARN>","<spike-owned config set ARN>"],
 "Condition":{"StringEquals":{"ses:TenantName":"spike-tenant"}}}]}
```

## Question 1: is `ses:TenantName` enforced over SMTP?

- [ ] **Send over SMTP with both headers** — `X-SES-TENANT: spike-tenant`
  and `X-SES-CONFIGURATION-SET: spike-owned`. Record accepted or
  refused, and the exact SMTP error if refused.
- [ ] **Send over SMTP with neither header.** Record the same.
- [ ] **Write down which of the three outcomes happened:**
  1. Both accepted — the key is not populated for SMTP; the tenant
     condition buys nothing and comes out of the policy.
  2. Tagged accepted, untagged refused — the design works as written.
  3. Both refused — SES never populates the key; the condition denies
     everything and must come out of the policy.

## Question 2: does a tenant apply its configuration set on its own?

- [ ] **Send with `X-SES-TENANT` but no `X-SES-CONFIGURATION-SET`.**
  The identity's default is `spike-other`, which is not associated with
  the tenant. Record whether the send is refused (the documented
  behaviour) or accepted.
- [ ] **If accepted, check which topic the events arrived on.** That
  tells you whether events would reach CARLOS or the identity owner.
- [ ] **Send with both headers and confirm the event arrives on
  `spike-owned`'s topic**, carrying `ses:caller-identity` with the IAM
  user's name — §8's attribution depends on that tag being present.

## Question 3: is an associated identity left alone, and are its other senders?

- [ ] **Record `GetEmailIdentity` before and after the association** and
  diff: DKIM tokens, `MailFromAttributes`, and
  `ConfigurationSetName`. Nothing should change.
- [ ] **Send on the identity with no tenant header at all**, using a
  second IAM user whose policy has no tenant condition. This is
  Classic's traffic. Confirm it still sends, and that its events go to
  `spike-other` as before.
- [ ] **Confirm `DeleteEmailIdentity` is refused** while the association
  exists, then re-associate. This is the cross-team contract §7 records:
  Classic loses the ability to delete the identity.

## Question 4: can a tenant be paused directly?

- [ ] **Pause it** with `UpdateReputationEntityCustomerManagedStatus`
  (`ReputationEntityType=RESOURCE`, the tenant ARN,
  `SendingStatus=DISABLED`).
- [ ] **Send with both headers** and confirm the send is refused.
- [ ] **Read `GetTenant`** and record where the paused state appears, so
  §8 knows what status to display.
- [ ] **Re-enable** with `SendingStatus=ENABLED` and confirm sending
  resumes.
- [ ] **Record the tenant's reputation policy** as created — the default
  is Standard, which auto-pauses — so §8 can decide between adopting
  SES's pause and setting the policy to `None`.

## Finish

- [ ] **Write the four answers into the spec** as a new "§4 results"
  subsection: outcome number for question 1, refused-or-accepted for
  question 2, the before/after diff for question 3, and the pause verb
  and status field for question 4. Say plainly what each one changes.
- [ ] **Delete everything**: both IAM users and their keys, the tenant
  and its associations, both configuration sets, the SNS topic, and the
  identity. `ListTenantResources` before deleting the tenant, since an
  identity cannot be deleted while associated.
- [ ] **Commit the spec change** on this branch. No other code lands.