Claude
514d235a2f
Creates openspec/changes/email-loop-prevention/ with all artifacts: - proposal.md: Why (MAILER-DAEMON bounce loop incident), what changes (automated sender detection + message-count cap), capabilities affected - design.md: Two-layer defence rationale, detection signal table, decisions on channel/agent boundary split, 20-message cap, one-shot alert, CC-only routing; risks and trade-offs documented - specs/email-channel/spec.md: ADDED requirements for detect_automated_message(), is_automated/automated_reason message dict fields, no-reply guarantee - specs/registration-notifications/spec.md: ADDED requirements for notify_loop_escalation() — alert content, one-shot guarantee, CC-only routing, dev-mode guard - tasks.md: All 6 sections fully checked (implementation already complete) https://claude.ai/code/session_01KwvR5hDPjSuJg4kvw5b5e5
30 lines
2.1 KiB
Markdown
30 lines
2.1 KiB
Markdown
## Why
|
|
|
|
The email channel had no protection against automated message loops. When the agent sent a reply that bounced (e.g. due to an invalid recipient address or a misconfigured mail server), the bounce message arrived back in the inbox. The agent treated it as a new inbound message, generated another reply, which bounced again — creating an infinite loop.
|
|
|
|
A real incident demonstrated this: a `MAILER-DAEMON@tacitus2.sui-inter.net` bounce began accumulating replies indefinitely, consuming LLM quota and filling the inbox with noise while the agent remained unaware it was talking to an automated system.
|
|
|
|
Beyond bounce loops, any automated sender — out-of-office replies, mailing-list software, delivery status notifications — can trigger this pattern if the agent replies to them. The system needs to recognise non-human senders and refuse to reply.
|
|
|
|
A secondary risk: a legitimate but very slow conversation (or a forwarding-alias loop that bypasses simple bounce detection) could still accumulate messages indefinitely. A hard cap on conversation length provides a safety net.
|
|
|
|
## What Changes
|
|
|
|
- **Detect automated/bounce senders** before the agent replies — inspect email headers and sender address patterns to identify non-human messages
|
|
- **Skip sending any reply** to automated messages — silence breaks the loop
|
|
- **Alert the admin once** when an automated sender is detected, so a human can investigate
|
|
- **Cap conversation length** at 20 inbound messages — if a conversation has not completed after 20 user messages, stop responding and alert the admin
|
|
- **Track escalation state** per conversation so admin alerts fire at most once
|
|
|
|
### Non-Goals
|
|
|
|
- Spam filtering (automated detection is specific to loop-causing patterns, not general spam)
|
|
- Automatic unsubscribe/block of senders
|
|
- Forwarding the original problem email to the admin (admin receives only a warning notification)
|
|
|
|
## Capabilities
|
|
|
|
### Modified Capabilities
|
|
|
|
- `email-channel`: Add automated/bounce sender detection; skip replies for flagged messages
|
|
- `registration-notifications`: Add loop-escalation alert type sent to admin CC address |