This document outlines an architectural review of the v1 AfterSMTP foundation, identifying areas for low-level tuning, protocol enhancements, and defining state-of-the-art administrative features for Phase 11 and beyond.

1. Areas of Improvement & Codebase Tweaks

High-Level Improvements

• Storage Subsystems: The current RoutingCallback mocks local disk storage. We need a performant encrypted data store (e.g., BadgerDB or PostgreSQL with pgcrypto) for at-rest email storage before clients pull them via FetchInbox.
• Identity Sybil Protection: Right now, the RegisterIdentity API allows any client to claim a DID. This requires Proof-of-Work (Hashcash) or administrative ACLs to prevent registry spam on both the Substrate ledger and SQLite fallback.
• Queueing Engine: Introducing an intermediate persistent queue (like NATS or RabbitMQ) between the Legacy Bridge and the AMP router to handle transient delivery failures, backoff algorithms, and high-volume bursts.

Low-Level / Protocol Tuning

• QUIC Stream Multiplexing: The quic_server currently spawns a goroutine per stream. We should implement a bounded worker pool for connection handling to prevent Out-Of-Memory (OOM) under DDOS conditions.
• Zero-Copy Serialization: Moving from standard encoding/json or simple byte appending to fasthttp style zero-copy buffer pools (sync.Pool) across the protobuf serialization boundaries to maximize DeliverMessage throughput.
• ECDH Shared Secret Caching: Diffie-Hellman operations are computationally expensive. Implementing an LRU Cache (e.g. hashicorp/golang-lru) for recent SharedSecrets paired with recipient X25519 keys will exponentially increase throughput to frequent relay targets.

2. Advanced Mail Routing & Mapping

To reach feature parity with deeply entrenched MTAs (Postfix/Exim), the AfterSMTP Core Router needs a comprehensive mapping facility.

Global & Administrative Maps

We will implement an in-memory/SQLite synchronized MappingEngine supporting: - access_map: IP and CIDR based network blocking (e.g. 192.168.1.0/24 REJECT). - mx_record_map: Explicit routing overrides for specific domains, bypassing standard DNS/Ledger lookups. - spam_cat_acl: Integration with SpamAssassin/Rspamd scores. If X-Spam-Score > 5, redirect to Junk, or outright REJECT at the SMTP RCPT TO phase. - relay_domains: A strict list of domains the node is cryptographically authorized to accept mail for, rejecting open-relay attempts early.

3. Address Rewriting & Translation Facility

Bridging internal AMP and external legacy SMTP requires dynamic address rewriting.

AMP to Legacy (Egress)

When an internal DID did:aftersmtp:msgs.global:ryan sends to a legacy user external@gmail.com: - The system must strip the AMP headers, decrypt the payload, and dynamically rewrite the From: header to a standard SMTP format: From: ryan@msgs.global. - A canonical_maps feature to define custom translations (e.g., did:aftersmtp:msgs.global:support-team rewrites to helpdesk@msgs.global).

Legacy to AMP (Ingress)

When external@gmail.com emails sales@msgs.global: - The legacy Bridge hits a virtual_alias_maps lookup table to determine that sales@msgs.global routes to did:aftersmtp:msgs.global:alice and did:aftersmtp:msgs.global:bob. - The engine duplicates the message, fetching both X25519 public keys from the Ledger, encrypting discrete payloads, and dispatching them internally.

4. Administrative Message Resigning (ARC/DKIM)

A state-of-the-art capability for large organizations is centralizing trust. - Automated Re-Signing: If an email arrives from an internal legacy system (like an old printer), the AfterSMTP Gateway captures it. Before passing it to the internet, it attaches a strong DKIM signature covering the Date, From, To, Subject, and Body, validating the origin. - ARC Sealing: When operating as a mailing list server or authorized forwarder, AfterSMTP will validate the inbound DKIM/SPF, and attach an Authenticated Received Chain (ARC) signature. This preserves the original sender's reputation (e.g. Gmail) as it passes through the AfterSMTP node preventing DMARC failures down the line.

5. Other State-of-the-Art Features to Implement

• Time-Expiring Messages: Utilizing the Proof of Transit blockchain timestamps, messages can mathematically refuse to decrypt after a specific epoch time, effectively introducing Ephemeral Email protocols.
• Quantum-Resistant Cryptography: Abstracting the X25519/Ed25519 implementations to support hybrid Kyber/Dilithium key matrices to defend against "Harvest Now, Decrypt Later" attacks.
• MailScript Integration: Expose an embedded JS/Lua/CEL engine within the Delivery Routing pipeline. This allows administrators to write dynamic scripts (if headers.contains('urgent') { route_to_slack_webhook() }) directly inside the node's configuration.