Status: pre-alpha implementation and protocol research. This document describes what the repository implements today, not a stable internet standard.

Identity and message protection

Native identities use did:aftersmtp:<domain>:<user>. The local ledger adapter resolves an Ed25519 signing key and an X25519 encryption key for each DID. When a Substrate node is unavailable, the project uses its SQLite fallback ledger.

An AMP message contains unencrypted routing headers, an encrypted protobuf payload, an ephemeral X25519 public key, and an Ed25519 signature. Native gRPC ingress:

1. resolves the sender DID;
2. verifies the signature over serialized headers and ciphertext;
3. applies trusted-delivery admission when configured;
4. resolves the recipient; and
5. creates a proof receipt before invoking the delivery pipeline.

The current implementation uses X25519 plus AES-GCM for the normal message path. ML-KEM-768 hybrid helpers exist, but are not yet negotiated or used for AMP message delivery. Do not describe current AMP traffic as post-quantum protected.

Transports actually implemented

Surface	Default port	Current behavior
AMP gRPC	4433	gRPC service for native delivery and the client API. The process currently creates a plain gRPC server; deploy it behind a TLS-terminating authenticated edge before any network exposure.
AMP QUIC	4434/UDP	Custom QUIC streams carrying protobuf-encoded AMPMessage values. This is QUIC, not an HTTP/3 API, and it uses the configured TLS certificate/key.
SMTP submission	2525	AUTH PLAIN is required in submission mode. STARTTLS is advertised only when the configured certificate loads; startup currently degrades instead of failing if it does not.
SMTP MX ingress	2526	Unauthenticated server-to-server SMTP with relay-domain and access-map checks.
Inbox push	4435	WebSocket endpoint for inbox notifications. It is not a general HTTP API.

Native gRPC and QUIC messages are authenticated by the AMP signature, not by a client TLS certificate. The QUIC handler verifies the sender signature before the pipeline; proof creation is currently implemented in gRPC and SMTP paths, not QUIC.

Delivery pipeline and trusted delivery

Every ingress path calls the shared pipeline. It checks expiry, handles room fan-out, runs a MailScript policy, then stores local messages or attempts external delivery. The local inbox is BadgerDB-backed and can use an AES at-rest key.

The gateway starts a durable SQLite trust control plane (trust.db by default).

• AFTERSMTP_TRUST_MODE=observe allows delivery while enforcing explicit sender blocks and rate limits.
• AFTERSMTP_TRUST_MODE=require_consent requires a live recipient grant for native AMP delivery.
• Legacy SMTP remains in observe mode in strict native deployments because an SMTP envelope sender is not a verifiable DID. It is rate-controlled by peer IP.

Communication requests and grants are implemented as durable domain objects, but no request/approval RPC is exposed yet. See COMMUNICATION_REQUESTS.md.

Legacy bridge

The SMTP on-ramp maps a recipient address to a DID, parses MIME, encrypts the payload for that recipient, and signs it with the gateway identity. It records the original legacy sender and DKIM result in PreviousHop; that value is provenance metadata, not a native sender identity.

For retry safety, a legacy message gets a deterministic ID from its RFC 5322 Message-ID when present, otherwise from the raw MIME bytes, plus the recipient DID. The inbox deduplicates repeated recipient/message-ID pairs.

Known beta limits

• Pipeline.OutboundDeliver is not wired by cmd/aftersmtp, so external AMP egress is not an end-to-end working feature.
• The client CLI's send command is still a mock.
• Proof receipts are best-effort with the fallback ledger and are not a claim of global blockchain finality.
• No versioned AMP discovery or interoperable cross-language SDK release exists yet.

For deployment and SMTP details, read INTEGRATION.md. For the anti-abuse design and its remaining research work, read REPUTATION_MODEL.md.