The primary hurdle in deploying a native End-to-End Encrypted, Blockchain-verifiable protocol (AMP) is integrating it cleanly into the decades-old traditional SMTP internet ecosystem without losing deliverability or breaking external user experience.

AfterSMTP resolves this using the Hybrid Legacy Bridge (On-Ramp / Off-Ramp) architectures.

The On-Ramp (Ingress from Legacy)

Traditional providers (Google Workspace, Microsoft 365, classic Postfix MTAs) will attempt to deliver email to your domain via standard port 25 or 2525.

When the AfterSMTP Gateway receives these connections it behaves as an aggressively hardened legacy SMTP host: 1. Strict STARTTLS Requirement: Unencrypted port 25 relaying is disabled globally. STARTTLS wrapping is required. 2. Authentication Required: AUTH PLAIN is required. The On-Ramp acts as an authorized portal preventing arbitrary internet spam.

When an authorized legacy payload hits the DATA phase, the Bridge intercepts it: - It resolves the destination address (user@domain.com) into their native blockchain identity (did:aftersmtp:domain:user). - It parses the MIME text, encapsulates it mathematically into the AMF protobuf structure, and seals it under the recipient's X25519 encryption lock. - Crucially, it attaches a Delegated Signature cryptographically signing the package under the Gateway Node's Ed25519 key, vouching for the legacy origin hop on the internal network.

The Off-Ramp (Egress to Legacy)

Conversely, when an internal AMP native user attempts to send an email to user@gmail.com, the AfterSMTP protocol must safely decrypt the payload and drop it onto the insecure legacy internet.

The OffRamp struct ensures maximum standard security policies survive this translation:

1. Robust Cryptographic Signing (DKIM)

Every legacy egress translates the sender's blockchain key identity into a verified DomainKeys Identified Mail (DKIM) RSA-256 byte-stream signature. The signature is injected into the payload header (github.com/emersion/go-msgauth/dkim), authenticating the legacy string.

2. ARC Chains (Authenticated Received Chain)

If the AfterSMTP gateway is forwarding a legacy email that originated externally, it natively leverages the security.ARCManager to append an ARC Seal summarizing the hops cryptographic status. This satisfies enterprise DMARC failure mitigations when forwarding.

3. DANE & DNSSEC Pinning

Before the TCP smtp.Dial("target_mx:25") establishes, the gateway natively probes the destination via dns.Resolver for DNSSEC authenticated TLSA records mapping to port 25. - If standard TLSA pinning is discovered via DANE, the crypto/tls config is locked tightly to match the hash certificates. - If the target MX strips the STARTTLS command (a common MitM downgrade attack), the AfterSMTP link recognizes the strict DANE policy and instantly terminates the connection preventing cleartext spill.

Integration with existing Postfix / Exim Instances

If you wish to place AfterSMTP inside a corporate DMZ running mature Postfix instances, configure Postfix as an authenticated edge relay:

# POSTFIX: /etc/postfix/main.cf
relayhost = [aftersmtp.internal.address]:2525
smtp_tls_security_level = encrypt
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd

The internal AfterSMTP bridge will safely encrypt internal organizational traffic to the blockchain.