draft-meyer-map-00 | IETF Individual Submission | John Meyer
MAP is a proposed replacement for SMTP, the protocol that has carried email since 1982. SMTP's security model was built for a cooperative internet that no longer exists. Every mechanism added since (SPF, DKIM, DMARC, STARTTLS, MTA-STS, SMTP TLS Reporting) is a patch on a foundation that was never designed to authenticate the transport peer.
MAP makes mutual authentication a property of the transport itself rather than a layer added on top. A MAP session cannot be established without both endpoints proving control of DNSSEC-bound static keys for their respective domains. There is no opportunistic mode and no anonymous submission path.
The cryptographic design draws on the Noise Protocol Framework and the operational lessons of WireGuard. The primitive set is small and fixed. Static keys are bound to domain identities and distributed via DNS. Mutual authentication cannot be disabled or downgraded.
This document specifies the MTA-to-MTA transfer protocol only. Submission by user agents (SMTP Submission, JMAP) and retrieval by user agents (IMAP, POP3, JMAP) are out of scope. Existing submission and retrieval protocols continue to function unchanged. Future specifications may define MAP profiles for those roles.
A MAP session proceeds in five phases.
Discovery. The MAP client resolves SVCB or SRV records for the recipient domain to locate the service endpoint, then resolves MAPKEY records to obtain the static public key for that endpoint. All records are validated under DNSSEC.
Transport. The MAP client opens a TCP connection to the discovered endpoint. TCP is mandatory-to-implement. UDP and QUIC bindings are reserved for future specifications.
Handshake. A Noise IK handshake runs over the TCP connection. The initiator's static public key is validated against the sender domain's MAPKEY records (this is what prevents domain spoofing). The handshake transcript is bound to a digest of the DNSSEC-validated MAPKEY RRset to prevent resolver substitution attacks.
Framing. Both endpoints exchange MAP control frames over the encrypted Noise channel. Envelopes are submitted, payloads are chunked and delivered, and per-recipient outcomes are returned.
Termination or reuse. Sessions may carry multiple envelope submissions. Servers may issue resumption tickets so high-volume MTA pairs avoid repeated full handshakes.
| Role | Algorithm |
|---|---|
| Diffie-Hellman | X25519 |
| AEAD cipher | ChaCha20-Poly1305 |
| Hash | BLAKE2s |
| Envelope and DSN signatures | Ed25519 |
| Payload content hash | BLAKE3 |
| Optional end-to-end encryption | HPKE (RFC 9180) or MLS (RFC 9420) |
| Proof-of-work | Argon2id |
The cryptographic suite is fixed in v1. Algorithm agility is intentionally limited. Future revisions may introduce new identifiers; mixed-suite negotiation within a single handshake is not supported.
Sender static keys. Sending domains publish their authorized initiator keys in DNS as MAPKEY records with usage=client. Receivers verify the static key presented in the Noise handshake against the DNSSEC-validated set. A spoofed sender domain cannot complete a handshake.
Channel binding. The first encrypted payload after the handshake includes a digest of the DNSSEC chain and MAPKEY RRset. This defeats resolver-substitution attacks that would otherwise let an attacker with control of a resolver swap keys between the client's view and the server's view.
Reliable framing. A CBOR-based framing layer with sequence numbers, credit-based flow control, and payload chunking runs on top of the Noise channel. Large messages are transferred reliably without rebuilding TCP semantics.
Session resumption. PSK tickets bound to the original handshake transcript allow 0-RTT resumption between MTAs that already authenticated. High-volume pairs do not pay handshake costs per message.
Transition story. Three policy modes (enforce, testing, none) allow recipients to dictate their fallback behavior. MAP-to-SMTP gateways are specified explicitly with attribution preservation rules.
DNSSEC fallback. Recipients that cannot DNSSEC-sign their zones may publish equivalent records via a signed HTTPS bootstrap document at a well-known URL. This avoids excluding the substantial portion of the internet that does not yet deploy DNSSEC.
| File | Description |
|---|---|
draft-meyer-map-00.md |
Readable markdown of the draft content |
draft-meyer-map-00.xml |
xml2rfc v3 source (canonical for IETF submission) |
draft-meyer-map-00.txt |
Rendered IETF Internet-Draft text (for submission) |
map-envelope.cddl |
CBOR Data Definition Language schema for envelopes, frames, and DSNs |
examples.zone |
DNS record examples |
README.md |
This file |
LICENSE |
Apache 2.0 for supporting files; see file for draft text license terms |
The .xml is the build source for IETF submission. The .txt is generated from the .xml using xml2rfc. The .md is a parallel source for readers who prefer markdown; it is maintained to match the .xml content.
pip install xml2rfc
xml2rfc --text draft-meyer-map-00.xml -o draft-meyer-map-00.txt
The generated draft-meyer-map-00.txt is the canonical IETF Internet-Draft format suitable for submission to the IETF Datatracker.
Individual submission, not yet adopted by a working group. Target working group: IETF DISPATCH. Datatracker submission pending.
Discussion on the IETF DISPATCH mailing list is the appropriate channel for protocol-level review. Implementation feedback and editorial issues are welcome via GitHub Issues.
This repository constitutes a public disclosure of the MAP protocol as described in draft-meyer-map-00. The author asserts no patent claims arising from this specification. The publication is intended to establish prior art and ensure the protocol remains freely implementable by anyone. Any attempt to patent the techniques described here is contrary to the author's intent and is undermined by this disclosure.
The draft text (draft-meyer-map-00.*) is subject to IETF Trust provisions per BCP 78 (trust200902).
Supporting files (map-envelope.cddl, examples.zone) are released under the Apache License 2.0, which includes an explicit patent grant. See LICENSE.
John Meyer (jmeyer@sagosec.com)