← Back to Research

Design note, updated 2026-07-31. Companion to CRYPTO_REVIEW.md and CODE_GRAPH.md. Status: the gateway now has durable local reputation classes (unknown, probation, trusted, blocked) and admission rate limits. The clustering, oracle, and feedback system described below remains research, not implemented behavior.

Premise

Cryptographic identity stops spoofing, not spam. A spammer can register a valid did:aftersmtp:, pay the mint cost, and sign flawless garbage — authentication tells you who, never whether the recipient wanted it. Spam is a consent problem wearing an identity problem's clothes.

What stops spam is reputation made enforceable by persistent, costly identity, scored over a constellation of signals — of which the registered DID is one input, not the whole story. The job of this layer is to resolve the abusive actor behind N synthetic-but-valid identities and act on the cluster, not the single ID.

Why AfterSMTP can do this better than legacy SMTP: proof-of-transit gives a global, tamper-evident behavioral substrate. Today every receiver sees only its own slice of sender behavior; a shared transit ledger lets reputation be computed over the whole graph. That — not "decentralization" — is the ledger's strongest justification (see the open question raised in CRYPTO_REVIEW.md).

Signal taxonomy

Reputation is a function over six signal classes. No single class is decisive; their correlation structure is the product.

A. Identity / DID reputation (first-class, but not sole)

The registered DID's own track record — the strongest single feature when history exists: - DID age and continuous-use history. - Cost sunk into the identity: PoW difficulty / stake bonded at registration. - Direct complaint rate, spamtrap hits, hard-bounce rate attributed to this DID. - Prior enforcement history (throttled / quarantined / burned).

Strong when populated; useless at cold start — which is exactly what classes B–F cover.

B. Registration & funding provenance (Sybil clustering)

From the ledger's registration extrinsics: - DIDs minted in the same batch / time window. - Common funding account or stake source. - Shared PoW-solver fingerprint. A thousand DIDs funded from one account are one actor wearing a thousand hats.

C. Transit-graph / behavioral (from proof-of-transit)

The ledger's anchored send records yield a global behavior graph: - Fan-out (recipients per unit time), send-volume ramp. - Timing cadence (machine-even intervals vs organic bursts). - Topology: star/blast vs reciprocal/organic correspondence. - Recipient-set diversity and overlap across DIDs (shared target lists ⇒ shared actor).

D. Infrastructure / network

  • Originating gateway IP / ASN reputation.
  • QUIC / TLS fingerprint (JA4 family).
  • Domain DNSSEC + DANE posture; domain age.

E. Recipient feedback (ground truth)

  • Spam-button presses, complaints, engagement signals.
  • Spamtrap / honeypot hits.
  • Bounce and rejection patterns. The only true labels in the system — the supervision for everything else.

F. Content (where visible)

At the legacy bridge (decrypted for off-ramp) or recipient-side classification: standard content/URL/attachment scoring. Least available in the pure-AMP E2E path, by design — which is why B–E matter more here than in legacy SMTP.

Entity resolution

The core technique: cluster across A–F to infer the real actor behind many identities, then apply reputation at the cluster level. A burned actor who mints a fresh DID still shares funding provenance (B), infrastructure (D), targeting and timing (C) — and gets re-attached to its cluster on first send. Re-entry costs them real money (PoW/stake) per identity; correlation makes the new identity worthless on arrival. That is the economic lever the whole protocol exists to pull.

Decisioning

  • Signals combine into a graded score, not a binary verdict.
  • Graduated trust: new/cold identities are rate-limited, not blocked, and earn capacity through clean behavior + engagement (E).
  • Enforcement ladder: throttle → quarantine → reject at RCPT → DID burn, with the action attached to the resolved cluster.
  • Allowlisting / appeals are mandatory, not optional (see Hard problems).

The central tradeoff: privacy vs. detection

The transit graph that powers cross-identity detection (class C) is the same metadata goldmine flagged in CRYPTO_REVIEW.md §Architecture. These cannot both be naively maximized — the design axis is who may query the graph, at what resolution.

  • Fully public graph → strong detection, but hands the global social graph to stalkers and states. Unacceptable.
  • Fully private graph → preserves metadata privacy, but reputation oracles go blind and detection collapses.
  • Middle path (recommended research direction): publish only commitments on-chain; keep the queryable behavioral graph behind access-controlled reputation oracles; answer abuse queries under MPC / zero-knowledge so an oracle can attest "this DID belongs to a known abuse cluster" without revealing the underlying who-mailed-whom. Pseudonymous, rotating transit records that only authorized oracles can correlate is another lever.

This is the novel surface. Solve it and the system is more than a re-skin of existing anti-spam; ignore it and the ledger is a privacy regression.

Hard problems (don't ship without answers)

  1. False positives. Legitimate bulk/transactional senders (newsletters, ESPs) are topologically indistinguishable from spammers at the graph level — high fan-out, bursts. Without graduated trust + allowlisting + appeals you nuke Mailchimp on day one.
  2. Cold start. Reputation is weakest with no data; that's exactly when abusers flood a new network. Bootstrap with conservative defaults, infrastructure signals (D), and imported legacy reputation until A/C/E accumulate.
  3. Arms race. Once clustering features are known, adversaries diversify infrastructure, slow-ramp, and mimic organic topology. This is a continuously retrained system with a labeled feedback loop (E), not a fixed ruleset.
  4. Base rates & due process. At internet scale, even a low false-positive rate is large collateral damage. Burning a cluster must be reversible and appealable.

Open questions / next steps

  • Define the on-chain record minimally: what is committed publicly vs. held by oracles?
  • Specify the oracle trust model — federated? staked? who runs them?
  • Prototype one cross-identity cluster query under a ZK/MPC sketch to test feasibility before committing the ledger schema.
  • Decide the legacy-reputation import path for cold start (existing DNSBL / domain reputation feeds).