## Summary / Purpose

Extend the existing SES webhook ingestion system so it can process additional SES event types using the **same unified ingestion pipeline** already used for current SES events. The system does **not** distinguish between “inbound” or “outbound” events — all SES events flow through a single lifecycle:

1. Parse the JSON payload  
2. Determine the SES event type  
3. Ignore unsupported events  
4. Validate supported events  
5. Normalize supported events into the unified schema  
6. Emit internal events  
7. Respond to SES  

This task only adds new SES event types to that pipeline. No new webhook, no new lifecycle, and no additional architectural concepts are introduced.

---

## Supported SES Event Types to Add

Extend the current allowlist by adding support for the following SES event types:

- `Send`
- `Delivery`
- `Bounce`
- `Complaint`
- `DeliveryDelay`

All other SES event types remain **ignored**, logged at debug level, and acknowledged with success.

---

## Validation Requirements (Supported Event Types Only)

For events in the allowlist above, validation rules must match the existing SES ingestion model:

- JSON must parse correctly.
- `eventType` or `notificationType` must be present.
- A `mail` object must exist and include:
  - `messageId`
  - `timestamp`
  - `source`
  - `destination[]` (non-empty)

- The corresponding SES event-specific object must exist:
  - `Send` → `send`
  - `Delivery` → `delivery`
  - `Bounce` → `bounce`
  - `Complaint` → `complaint`
  - `DeliveryDelay` → `deliveryDelay`

Failures in validation:

- Must be logged at **error** level with a reason and message ID (if available).
- Must return a **non-success** response to SES.
- Must stop all processing and emit no internal events.

Unsupported events do **not** undergo validation.

---

## Normalization Requirements

For supported and validated SES events, normalize into the existing unified internal schema:

### Core Message Fields
- `message_id`
- `from_address`
- `recipients`
- `sent_at` (parsed into a standardized timestamp format)
- `tags` (preserved exactly as SES provides them)

### Event Metadata
- `id` (feedback ID when present)
- `type` (one of: `send`, `delivery`, `bounce`, `complaint`, `delay`)
- `timestamp` (event-specific timestamp, parsed into standardized timestamp format)

### Optional Event-Type Blocks
Depending on `type`, include one of:

- `bounce`
- `complaint`
- `delivery`
- `delay`

Each block includes its expected fields exactly as defined in the normalized schema.

Normalization must be SES-agnostic — no SES field names should leak into the internal event shape.

---

## Internal Event Emission

Emit exactly one internal event for each normalized SES event:

- `type = "send"` → `EmailSent`
- `type = "delivery"` → `EmailDelivered`
- `type = "bounce"` → `EmailBounced`
- `type = "complaint"` → `EmailComplaint`
- `type = "delay"` → `EmailDelayed`

Internal events must include **only** the normalized data — never SES raw JSON.

If emission fails for any reason:

- Log the error.
- Return a **non-success** response to SES.
- Stop further processing.

---

## Logging & Response Behavior

Re-use the same semantics already implemented for SES ingestion:

### Debug Logs
- Unsupported SES event types that are ignored.

### Error Logs
- JSON parsing failures.
- Validation failures for supported events.
- Internal event emission failures.

### Response Rules
Return **success (2xx)** only when:

- JSON parsed successfully.
- All supported events validated successfully.
- All supported events normalized successfully.
- All supported events emitted successfully.
- Unsupported events were ignored without issues.

Return **non-success** otherwise.

---

## Out of Scope

- Any business logic reacting to these events.
- Storage or indexing of normalized event data.
- UI or reporting updates.
- Changes to the inbound SES behavior beyond sharing the unified pipeline.
- SES configuration, SNS topic setup, DNS, or identity management.