Design abuse detection and prevention for outbound email

[jiashuoz]

Context

e2a currently has useful deliverability controls—send rate limits, delivery feedback, suppression lists, unsubscribe handling, outbound policies, and optional content screening—but no complete account-level abuse system.

We need a high-level design for detecting, containing, reviewing, and preventing unsolicited or abusive outbound email while minimizing false positives for legitimate agent workflows.

Goals

• Detect bulk, bursty, repetitive, or suspicious outbound behavior.
• Prevent sends to unsubscribed, complained-about, or repeatedly bouncing recipients.
• Support automatic throttling, review, and suspension.
• Make decisions durable across replicas and explainable to operators.
• Preserve legitimate transactional and agent-to-agent workflows.
• Avoid storing raw customer content in abuse telemetry.

Detection signals

Consider signals at both account and agent scope:

• Sends per minute/day and unique recipients per day.
• Rate of new recipients and recipient-domain concentration.
• Repeated sends to the same recipient within a time window.
• Bounce, complaint, block, failure, and suppression rates.
• Sudden changes in volume, recipient mix, or sending identity.
• Account age, domain verification, API-key age, and trust history.
• Consent/source metadata for imported or manually supplied recipients.
• Content and phishing signals where content screening is enabled.
• Provider reputation and feedback-loop signals.

No single signal should automatically classify an account as abusive.

Prevention and containment

Evaluate:

• Account-level quotas in addition to per-agent limits.
• Unique-recipient and per-recipient cooldown/repeat limits.
• Sending ramps for new accounts and sender domains.
• Default review or allowlist policies for new or untrusted senders.
• Fail-closed suppression and unsubscribe enforcement.
• Automatic holds on queued and future sends.
• Account states such as active, limited, review, and suspended.
• Operator override, appeal, and audit-history workflows.

Requirements

• Counters and decisions must be durable and replica-safe.
• Every automated action must record an explainable reason.
• Complaints and suppression events must be handled promptly.
• Raw bodies, subjects, recipient addresses, and customer identifiers must not appear in general metrics or public issue fixtures.
• Use synthetic .test / .invalid data in tests and examples.
• Add unit, integration, and multi-replica tests for throttling, suppression, suspension, and recovery.
• Define separate treatment for transactional, agent-to-agent, and promotional mail.

Open questions

• Which signals should be account-wide versus agent-specific?
• What thresholds should trigger throttle, review, or suspension?
• How should users provide and retain proof of recipient consent?
• Should promotional and transactional sending use separate identities or quotas?
• What operator tooling is required for investigation and appeals?
• Which controls belong in the OSS server versus hosted operations?

Proposed deliverables

1. Abuse signal and state-machine design.
2. Durable account/agent counters.
3. Policy and action evaluation layer.
4. Queue cancellation and sending kill-switch behavior.
5. Operator dashboard and alert definitions.
6. Privacy/redaction requirements.
7. Synthetic end-to-end abuse scenarios and runbook.