Network Working Group D. Tishkin Internet-Draft Independent Intended status: Standards Track 6 October 2026 Expires: 9 April 2027 HTTP Mail Transfer Protocol draft-tishkin-hmtp-00 Abstract This document specifies the HTTP Mail Transfer Protocol (HMTP), a protocol for the submission and transfer of Internet mail over HTTPS. HMTP covers both the submission of messages by clients to their mail service and the transfer of messages between mail servers. Each message is carried unmodified in the existing Internet Message Format inside a JSON envelope that holds the information needed for delivery. Large messages and attachments can be transferred by reference, with their integrity protected by cryptographic hashes. Requests are authenticated by signatures bound to the sending domain, using keys published with the DomainKeys Identified Mail (DKIM) key publication mechanism, which allows receivers to identify senders independently of their IP addresses. Servers discover HMTP endpoints through DNS. To allow incremental deployment alongside existing mail infrastructure, a server can optionally fall back to the Simple Mail Transfer Protocol (SMTP) when a peer does not support HMTP. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-tishkin-hmtp/. Source for this draft and an issue tracker can be found at https://github.com/dmi03/draft-tishkin-hmtp. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Tishkin Expires 9 April 2027 [Page 1] Internet-Draft HMTP October 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 9 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 1.2. Overview of HMTP . . . . . . . . . . . . . . . . . . . . 5 1.3. Relationship to Other Work . . . . . . . . . . . . . . . 7 1.4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 7 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Message Flow . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Coexistence with SMTP . . . . . . . . . . . . . . . . . . 11 4. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. DNS Record . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Capabilities Document . . . . . . . . . . . . . . . . . . 13 4.2.1. Endpoint Objects . . . . . . . . . . . . . . . . . . 14 4.2.2. Retrieval and Caching . . . . . . . . . . . . . . . . 15 4.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 16 5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1. Envelope . . . . . . . . . . . . . . . . . . . . . . . . 17 5.2. Content Object . . . . . . . . . . . . . . . . . . . . . 20 5.2.1. Retrieval of Referenced Content . . . . . . . . . . . 22 5.3. Attachments . . . . . . . . . . . . . . . . . . . . . . . 24 5.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 25 5.4.1. Capability Names . . . . . . . . . . . . . . . . . . 25 5.4.2. Advertisement and Use . . . . . . . . . . . . . . . . 26 5.4.3. Specifying a Capability . . . . . . . . . . . . . . . 27 Tishkin Expires 9 April 2027 [Page 2] Internet-Draft HMTP October 2026 5.4.4. Example . . . . . . . . . . . . . . . . . . . . . . . 28 6. Message Transfer . . . . . . . . . . . . . . . . . . . . . . 30 6.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.2. Processing by the Receiving Server . . . . . . . . . . . 31 6.3. Response . . . . . . . . . . . . . . . . . . . . . . . . 32 6.4. Retries and Idempotency . . . . . . . . . . . . . . . . . 34 6.5. Trace Information . . . . . . . . . . . . . . . . . . . . 36 7. Message Submission . . . . . . . . . . . . . . . . . . . . . 37 7.1. Client Authentication . . . . . . . . . . . . . . . . . . 38 7.2. Authorization of Sender Addresses . . . . . . . . . . . . 39 7.3. Message Validation and Modification . . . . . . . . . . . 39 7.4. Identities . . . . . . . . . . . . . . . . . . . . . . . 40 8. Authentication and Signing . . . . . . . . . . . . . . . . . 41 8.1. Signing Keys . . . . . . . . . . . . . . . . . . . . . . 41 8.2. Signature Construction . . . . . . . . . . . . . . . . . 42 8.2.1. Signing of Retrieval Requests . . . . . . . . . . . . 43 8.3. Verification Procedure . . . . . . . . . . . . . . . . . 43 8.4. Sender Alignment . . . . . . . . . . . . . . . . . . . . 45 8.5. Third-Party Senders . . . . . . . . . . . . . . . . . . . 45 9. Delivery Status and Errors . . . . . . . . . . . . . . . . . 46 9.1. Problem Details . . . . . . . . . . . . . . . . . . . . . 46 9.2. Mapping to SMTP Status Codes . . . . . . . . . . . . . . 47 9.3. Delivery Status Notifications . . . . . . . . . . . . . . 51 9.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 52 10. SMTP Fallback and Interoperability . . . . . . . . . . . . . 54 10.1. When to Fall Back . . . . . . . . . . . . . . . . . . . 54 10.1.1. Example . . . . . . . . . . . . . . . . . . . . . . 55 10.2. Downgrade Policy . . . . . . . . . . . . . . . . . . . . 58 10.3. SMTP to HMTP Gateways . . . . . . . . . . . . . . . . . 59 11. Deployment and Transition Considerations . . . . . . . . . . 60 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 61 13. Security Considerations . . . . . . . . . . . . . . . . . . . 61 13.1. Transport Security . . . . . . . . . . . . . . . . . . . 61 13.2. DNS and Downgrade Attacks . . . . . . . . . . . . . . . 61 13.3. Signatures and Replay . . . . . . . . . . . . . . . . . 62 13.4. Key Management . . . . . . . . . . . . . . . . . . . . . 62 13.5. Sender Alignment . . . . . . . . . . . . . . . . . . . . 62 13.6. Content References . . . . . . . . . . . . . . . . . . . 63 13.7. Denial of Service . . . . . . . . . . . . . . . . . . . 63 13.8. Client Authentication . . . . . . . . . . . . . . . . . 63 13.9. Transfer Identifiers . . . . . . . . . . . . . . . . . . 64 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 64 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65 15.1. Underscored and Globally Scoped DNS Node Name . . . . . 65 15.2. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 65 15.3. DKIM Service Type . . . . . . . . . . . . . . . . . . . 65 15.4. Mail Transmission Types . . . . . . . . . . . . . . . . 66 15.5. URN Sub-namespace . . . . . . . . . . . . . . . . . . . 66 Tishkin Expires 9 April 2027 [Page 3] Internet-Draft HMTP October 2026 15.6. HMTP Registry Group . . . . . . . . . . . . . . . . . . 67 15.6.1. HMTP Capabilities . . . . . . . . . . . . . . . . . 67 15.6.2. HMTP Endpoints . . . . . . . . . . . . . . . . . . . 67 15.6.3. HMTP Content Encodings . . . . . . . . . . . . . . . 68 15.6.4. HMTP Problem Types . . . . . . . . . . . . . . . . . 68 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 69 16.1. Normative References . . . . . . . . . . . . . . . . . . 69 16.2. Informative References . . . . . . . . . . . . . . . . . 73 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 75 A.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 75 A.2. Transfer with Referenced Content . . . . . . . . . . . . 76 A.3. Submission . . . . . . . . . . . . . . . . . . . . . . . 78 A.4. Retried Request . . . . . . . . . . . . . . . . . . . . . 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 79 1. Introduction The Simple Mail Transfer Protocol (SMTP) [RFC5321] has carried Internet mail for several decades and remains the only widely deployed protocol for transferring messages between mail servers. Message submission by clients [RFC6409] uses the same protocol. Over time, a number of mechanisms have been layered on top of SMTP to address requirements that did not exist when it was designed: opportunistic encryption with STARTTLS [RFC3207], sender authorization with SPF [RFC7208], message signing with DKIM [RFC6376], policy alignment with DMARC [RFC7489], and downgrade protection with MTA-STS [RFC8461] and DANE [RFC7672]. Each of these mechanisms is useful, but together they form a complex system that is difficult to deploy and operate correctly. 1.1. Problem Statement This document is motivated by the following properties of SMTP-based mail transfer: Dependence on IP addresses and port 25: Receivers commonly make trust decisions based on the IP address of the connecting server. Many cloud and hosting providers restrict outbound connections to port 25, and new senders find it difficult to establish reputation for their addresses. IP-based reputation also works poorly when many unrelated senders share addresses in cloud environments. As a result, small operators often have to relay mail through third- party sending services. Optional transport security: STARTTLS is negotiated in plaintext and Tishkin Expires 9 April 2027 [Page 4] Internet-Draft HMTP October 2026 can be removed by an active attacker. Certificate validation is frequently not performed. Additional mechanisms such as MTA-STS and DANE are required to prevent downgrade attacks, and they are not universally deployed. Limited error reporting: SMTP reply codes [RFC5321] and enhanced status codes [RFC3463], accompanied by free-form text, provide limited structured information about why a message was rejected, which makes automated handling of failures difficult. Inefficient transfer of large content: All content, including large attachments, is transferred inline within the message. The same content is transferred again for every receiving domain, and there is no standard way to refer to content stored elsewhere with integrity protection. Separate authentication mechanisms: Sender authentication relies on several independent mechanisms (SPF, DKIM, and DMARC) that are evaluated separately and can give conflicting results. No protection against duplicate delivery: If the connection is lost after a server has accepted a message but before the client has received the reply, the client cannot tell whether the message was accepted. Retrying the transaction can result in the message being delivered twice. 1.2. Overview of HMTP HMTP uses HTTP [RFC9110] over TLS as its transport and a JSON [RFC8259] envelope to carry delivery information. Its main properties are: * Transport security is mandatory. HMTP is only defined over HTTPS with certificate validation, so no plaintext mode exists and no downgrade is possible within the protocol. A domain can additionally publish a policy that prevents senders from falling back to SMTP. * The message itself is not changed. Messages are carried in the Internet Message Format [RFC5322] with MIME [RFC2045] exactly as produced by the sender. Servers only prepend trace header fields, as SMTP servers do. Existing DKIM signatures and end-to-end protection such as OpenPGP [RFC9580] or S/MIME [RFC8551] therefore remain valid. Tishkin Expires 9 April 2027 [Page 5] Internet-Draft HMTP October 2026 * The envelope is separate from the message. As in SMTP, the envelope sender and recipients are distinct from the header fields of the message, which preserves the semantics of blind carbon copies, mailing lists, and forwarding. * Senders are identified by domain. Each request is signed using HTTP Message Signatures [RFC9421] together with Digest Fields [RFC9530], with keys published in DNS in the same way as DKIM keys. This allows receivers to base trust decisions on domain reputation rather than on IP address reputation, and allows senders to operate behind proxies and content delivery networks. * Content may be transferred by reference. A message, or any part of it such as an attachment, may be provided as a URL together with its size and cryptographic hash. The receiving server retrieves such content directly from where it is stored, so that large content does not have to be carried in every request. * Requests are idempotent. Each request carries an identifier that allows the receiving server to recognize a retried request and avoid delivering the same message twice. * Endpoints are discovered through DNS. A single SVCB [RFC9460] record identifies the HMTP endpoint of a domain, and a well-known URI [RFC8615] describes the capabilities of the server. * Errors are structured. Failures are reported using Problem Details for HTTP APIs [RFC9457], with a defined mapping to SMTP enhanced status codes. * Deployment is incremental. HMTP is a complete protocol on its own and does not depend on SMTP. An implementation can optionally deliver messages using SMTP when a receiving domain does not publish an HMTP endpoint. Because the message is carried unmodified, such a fallback requires no conversion of the message, provided that the SMTP server supports the SMTP extensions that the message requires. HMTP defines two roles: submission, in which a client hands a message to its mail service, and transfer, in which one mail server delivers a message to another. Clients authenticate to their submission server using HTTP authentication. Basic authentication [RFC7617] provides compatibility with existing SMTP AUTH credentials, and bearer tokens [RFC6750] obtained through OAuth 2.0 [RFC6749] are supported for deployments that require stronger authentication. Tishkin Expires 9 April 2027 [Page 6] Internet-Draft HMTP October 2026 1.3. Relationship to Other Work The JSON Meta Application Protocol (JMAP) [RFC8620] [RFC8621] provides HTTP-based access to mailboxes and supports message submission, but it does not define transfer of messages between mail servers. HMTP is complementary: a JMAP server can use HMTP to deliver submitted messages to other domains. HMTP does not replace DKIM. DKIM signatures inside the message continue to protect the message across all hops, including hops that use SMTP. HMTP signatures protect each individual HMTP request. 1.4. Non-Goals The following are outside the scope of this document: * Defining a new format for messages. Alternative message formats may be defined as extensions. * Defining spam filtering or reputation algorithms. These remain a matter of local policy at the receiving server. * Mailbox access and synchronization, which are addressed by IMAP [RFC9051] and JMAP. * End-to-end encryption of messages, which continues to be provided by existing mechanisms such as OpenPGP and S/MIME. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses the terminology of the Internet Mail Architecture [RFC5598]. The terms "JSON object", "member", and "array" are used as defined in [RFC8259]. The terms "signature", "signer", "verifier", "covered components", and "signature parameters" are used as defined in [RFC9421]. The Content-Digest header field is defined in [RFC9530]. The following terms are defined for use in this document: Message: An Internet message in the format defined by [RFC5322], Tishkin Expires 9 April 2027 [Page 7] Internet-Draft HMTP October 2026 including any MIME [RFC2045] structure. HMTP transfers the Message without modification, except for the prepending of trace header fields described in Section 6.5 and the changes permitted at submission in Section 7.3. Envelope: The JSON object that accompanies a Message in an HMTP request and carries the information needed for delivery, such as the envelope sender and the envelope recipients. The Envelope is distinct from the header fields of the Message. It is specified in Section 5.1. Envelope Sender: The address to which delivery status notifications are sent, carried in the Envelope. It corresponds to the SMTP "MAIL FROM" address [RFC5321]. The Envelope Sender may be empty, which corresponds to the SMTP null reverse-path "<>". Envelope Recipient: An address to which the Message is to be delivered, carried in the Envelope. It corresponds to an SMTP "RCPT TO" address [RFC5321]. Sending Domain: The domain on whose behalf an HMTP transfer request is signed, as identified by the key used to sign the request (see Section 8). Client: A Mail User Agent (MUA), or another program acting on behalf of a user, that submits Messages to a Submission Server using HMTP. Submission Server: A server that accepts Messages from authenticated Clients and relays them toward their recipients. It corresponds to the Message Submission Agent (MSA) role described in [RFC5598]. Sending Server: A server that transfers a Message to a Receiving Server using HMTP. It corresponds to the Message Transfer Agent (MTA) role described in [RFC5598]. Receiving Server: A server that accepts Messages from Sending Servers for the domains it serves and delivers them to recipients or relays them further. HMTP Endpoint: The HTTPS URI at which a server accepts HMTP requests, as identified through discovery (see Section 4). Capabilities Document: The JSON document that describes the HMTP Endpoints, limits, policy, and extensions of a host (see Section 4.2). Content Object: A JSON object that carries content, such as a Tishkin Expires 9 April 2027 [Page 8] Internet-Draft HMTP October 2026 Message, either inline, by reference, or as a sequence of segments (see Section 5.2). Content Reference: A Content Object that describes content which is not carried in the request itself but is retrieved from an HTTPS URI, together with its size and cryptographic hash. Transfer Identifier: The identifier chosen by the sender of an HMTP request that allows the recipient of the request to recognize a retried request (see Section 6.4). A single server MAY act in more than one of these roles. In examples, long lines are wrapped as described in [RFC8792]. HTTP messages in examples are shown in HTTP/1.1 syntax for readability; the semantics of HMTP are independent of the HTTP version in use. Unless stated otherwise, base64-encoded data, digests, and signature values in examples are abbreviated or illustrative and are not computed over the example content. 3. Architecture HMTP is an application protocol that uses HTTP [RFC9110] over TLS as its transport. All HMTP requests are HTTP requests sent to an HMTP Endpoint. 3.1. Roles Submission: A Client sends a Message to its Submission Server. The Client authenticates to the Submission Server as described in Section 7. Transfer: A Sending Server sends a Message to a Receiving Server. The Sending Server signs each request on behalf of the Sending Domain, and the Receiving Server verifies the signature as described in Section 8. Both interactions use the same Data Model (Section 5). A Submission Server typically also acts as a Sending Server for the Messages it accepts. 3.2. Message Flow Figure 1 shows the path of a Message from a Client to a recipient. Tishkin Expires 9 April 2027 [Page 9] Internet-Draft HMTP October 2026 +--------+ submission +------------+ transfer +-----------+ | Client | ------------> | Submission | -----------> | Receiving | | (MUA) | (HMTP) | Server | (HMTP) | Server | +--------+ +------------+ +-----------+ | | | fallback v | (SMTP, optional) +-----------+ v | Recipient | +------------+ | Mailbox | | SMTP | +-----------+ | Server | +------------+ Figure 1: Message Flow 1. The Client constructs a Message and an Envelope and submits them to its Submission Server. 2. The Submission Server authenticates the Client and verifies that the Client is authorized to use the Envelope Sender and the originator addresses of the Message. 3. For each recipient domain, the Sending Server performs discovery (Section 4). If the domain publishes an HMTP Endpoint, the Sending Server transfers the Message to it using HMTP. Otherwise, a Sending Server that supports SMTP fallback delivers the Message using SMTP as described in Section 10. 4. The Receiving Server verifies the signature of the request, applies its local policy, and accepts or rejects the Message for each Envelope Recipient. 5. If the request contains Content References, the Receiving Server retrieves the referenced content and verifies its size and hash, either before it responds or after it has accepted the Message (see Section 5.2.1). 6. The Receiving Server prepends a trace header field to the Message and delivers the Message to the recipient mailbox or relays it further. Tishkin Expires 9 April 2027 [Page 10] Internet-Draft HMTP October 2026 3.3. Coexistence with SMTP HMTP does not change the use of MX records [RFC5321] or the operation of existing SMTP servers. A domain can publish an HMTP Endpoint in addition to its MX records, and a server can support both protocols at the same time. Because the Message is carried unmodified, a Message can travel over a path that combines HMTP and SMTP hops without conversion. Support for SMTP is not required for an HMTP implementation. A server that implements only HMTP is fully conformant to this document; it can exchange mail only with domains that publish an HMTP Endpoint. 4. Discovery A server or Client locates the HMTP Endpoint of a domain in two steps. It first queries DNS for the HMTP service record of the domain (Section 4.1) and then retrieves the Capabilities Document from the target host (Section 4.2). 4.1. DNS Record A domain that supports HMTP publishes one or more SVCB resource records [RFC9460] at the following owner name: _hmtp. where is the domain part of an email address, in the form of A-labels [RFC5890] for internationalized domain names. The "_hmtp" label is a globally scoped underscored node name [RFC8552]. It does not indicate a transport protocol, which is determined by the "alpn" SvcParam. Addresses whose domain part is an address literal [RFC5321] have no associated DNS name; HMTP is not used for such addresses. The records are interpreted according to [RFC9460] with the following rules: * AliasMode records are processed as specified in [RFC9460]. An AliasMode record whose TargetName is "." indicates that the domain does not provide HMTP (Section 2.5.1 of [RFC9460]). Tishkin Expires 9 April 2027 [Page 11] Internet-Draft HMTP October 2026 * In ServiceMode records, the TargetName identifies the host that provides the HMTP Endpoint. Because the owner name of the record is not a host name, the TargetName of a ServiceMode record MUST NOT be ".". A ServiceMode record whose TargetName is "." is unusable. * The "alpn" SvcParam MUST be present and MUST include "h2". It MAY also include "h3". Servers MUST support HTTP/2 [RFC9113] and MAY support HTTP/3 [RFC9114]. A ServiceMode record without an "alpn" SvcParam, or whose "alpn" SvcParam does not include "h2", is unusable. * The "port" SvcParam indicates the TCP or UDP port of the HMTP Endpoint. If it is absent, port 443 is used. * Other SvcParams, such as "ipv4hint" and "ipv6hint", are used as defined in [RFC9460] and in the documents that define them. A record that lists an unsupported key in the "mandatory" SvcParam is unusable, as specified in [RFC9460]. * If multiple ServiceMode records are present, they are tried in order of priority as specified in [RFC9460]. A Sending Server uses the domain of each Envelope Recipient to locate the Receiving Server. A Client uses the domain of its own address to locate its Submission Server. A Client MAY instead be configured with the URI of the Capabilities Document of its Submission Server. When connecting to the target host, the server or Client MUST validate the TLS certificate of the host against the TargetName, as described in [RFC9525]. DNS responses SHOULD be validated using DNSSEC [RFC4033] when available. See Section 13.2 for the consequences of an unauthenticated DNS response. The result of the DNS query is interpreted as follows: * If the query returns one or more usable ServiceMode records, the domain supports HMTP. * If the query returns a response indicating that the name does not exist or that no SVCB records exist for it, if the only record is an AliasMode record whose TargetName is ".", or if all returned records are unusable, the domain does not support HMTP. A Sending Server then proceeds as described in Section 10. Tishkin Expires 9 April 2027 [Page 12] Internet-Draft HMTP October 2026 * If the query fails for any other reason, such as a timeout or a server failure, the result MUST be treated as a temporary failure. The server MUST NOT conclude that the domain does not support HMTP. Results of DNS queries MAY be cached for the duration of their TTL. 4.2. Capabilities Document The Capabilities Document describes the HMTP Endpoint of a host. It is retrieved with an HTTP GET request to the well-known URI [RFC8615] "/.well-known/hmtp" on the target host and port identified by the DNS record. The request carries no authentication, and servers MUST NOT require authentication or a signature to retrieve the Capabilities Document. The response is a JSON object with the media type "application/json" and contains the following members: versions: REQUIRED. A JSON object whose member names identify the versions of HMTP supported by the server and whose values are Version Objects. Version names are strings of decimal digits without leading zeros; a higher number denotes a later version. This document defines version "1". When the server and the sender of a request have more than one version in common, the sender SHOULD use the highest of them. The object MUST contain at least one member. A Version Object contains the following member: endpoints: REQUIRED. A JSON object whose member names identify the interactions supported in this version and whose values are Endpoint Objects (Section 4.2.1). This document defines the following members: * "transfer": the Transfer Endpoint Object, which describes the endpoint for transfer (Section 6); * "submission": the Submission Endpoint Object, which describes the endpoint for submission (Section 7) and the related identities endpoint (Section 7.4). At least one of "transfer" and "submission" MUST be present. Additional endpoints MAY be defined by capabilities (Section 5.4) and are registered as described in Section 15.6.2. limits: OPTIONAL. A JSON object describing limits of the server. Tishkin Expires 9 April 2027 [Page 13] Internet-Draft HMTP October 2026 All values are non-negative integers. This document defines the following members: * "maxMessageSize": the maximum size of a Message in octets, after the reconstruction of all segments described in Section 5.2. * "maxRequestSize": the maximum size of the content of an HMTP request in octets, that is, of the JSON document itself. Content that is transferred by reference does not count toward this limit. * "maxRecipients": the maximum number of Envelope Recipients in one request. The value MUST NOT be less than 100. * "maxIdLength": the maximum length of a Transfer Identifier in characters (see Section 5.1). The value MUST NOT be less than 22 and MUST NOT be greater than 255. If this member is absent, the maximum length is 64. The absence of any other limit means that the server does not advertise it; the server can still reject a request that exceeds a limit it applies, as described in Section 9.1. policy: OPTIONAL. A JSON object that expresses the downgrade policy of the domains served by this host. It is specified in Section 10.2. capabilities: OPTIONAL. A JSON object whose member names identify supported extensions and whose values contain parameters of each extension. Extensions are specified as described in Section 5.4. Their names are either registered with IANA or URIs that serve only as unique names (Section 5.4.1). Recipients of the Capabilities Document MUST ignore members they do not understand. 4.2.1. Endpoint Objects An Endpoint Object is a JSON object that describes one endpoint and the parameters that apply to it. Every Endpoint Object contains the following member: uri: REQUIRED. The URI of the endpoint. The URI MUST use the "https" scheme and MAY be relative, in which case it is resolved against the URI of the Capabilities Document [RFC3986]. Tishkin Expires 9 April 2027 [Page 14] Internet-Draft HMTP October 2026 The specification of an endpoint, or a capability (Section 5.4), can define further members of an Endpoint Object. Because recipients ignore members they do not understand, new parameters can be added to an endpoint without changing the structure of the Capabilities Document. The Transfer Endpoint Object has no members other than "uri" in this document. Transfer requests are authenticated by signatures (Section 8), so no authentication parameters apply to it. The Submission Endpoint Object contains the following members in addition to "uri": identities: OPTIONAL. The URI of the identities endpoint (Section 7.4), subject to the same rules as "uri". The identities endpoint accepts the same authentication as the submission endpoint. authentication: REQUIRED. A non-empty array of strings listing the authentication schemes accepted by the submission endpoint and the identities endpoint, as described in Section 7.1. oauthResourceMetadata: OPTIONAL. The URI of the OAuth 2.0 Protected Resource Metadata [RFC9728] of the Submission Server, subject to the same rules as "uri". If this member is absent, Clients locate the metadata as specified in [RFC9728]. The resource identifier of a Submission Server is the origin of its submission endpoint. 4.2.2. Retrieval and Caching Servers SHOULD include caching information in the response, and recipients MAY cache the document as specified in [RFC9111]. The result of retrieving the Capabilities Document is interpreted as follows: * If the Capabilities Document cannot be retrieved because of a connection failure, a TLS failure (including a failure to validate the certificate of the host), or a 5xx status code, the result MUST be treated as a temporary failure. * If the server responds with any other error status code, if the document is not valid, or if it lists no version that the server or Client supports, the server or Client MUST NOT use HMTP with this host and continues with the next ServiceMode record, if any. If no usable host remains, the domain is treated as not supporting HMTP. Tishkin Expires 9 April 2027 [Page 15] Internet-Draft HMTP October 2026 4.2.3. Example The following example shows the DNS record and the Capabilities Document of a domain whose mail is handled by a provider: _hmtp.example.com. 3600 IN SVCB 1 hmtp.provider.example. ( alpn=h2,h3 ) HTTP/1.1 200 OK Content-Type: application/json Cache-Control: max-age=86400 { "versions": { "1": { "endpoints": { "transfer": { "uri": "/hmtp/v1/transfer" }, "submission": { "uri": "/hmtp/v1/submission", "identities": "/hmtp/v1/identities", "authentication": ["basic", "bearer"], "oauthResourceMetadata": "/.well-known/oauth-protected-resource" } } } }, "limits": { "maxMessageSize": 107374182400, "maxRequestSize": 52428800, "maxRecipients": 1000, "maxIdLength": 64 }, "policy": { "mode": "enforce", "maxAge": 604800 }, "capabilities": {} } Tishkin Expires 9 April 2027 [Page 16] Internet-Draft HMTP October 2026 5. Data Model All JSON documents defined by this document MUST conform to the Internet JSON (I-JSON) profile [RFC7493]. Member names are case- sensitive. Unless stated otherwise, recipients of a JSON document MUST ignore members they do not understand, and a member whose value is null is treated as if it were absent. Timestamps are strings in the "date-time" format of Section 5.6 of [RFC3339] and MUST use the UTC offset "Z". Sizes are integers counting octets. The content of a submission or transfer request is a JSON object, called the Request Object, with the following members: capabilities: OPTIONAL. An array of strings naming the capabilities that the request uses and that the recipient of the request is required to understand, as described in Section 5.4. The array MUST NOT contain duplicates. If this member is absent, it is equivalent to an empty array. envelope: REQUIRED. The Envelope (Section 5.1). message: REQUIRED. A Content Object (Section 5.2) whose content is the Message. The response to a successful request is a Response Object, specified in Section 6.3. 5.1. Envelope The Envelope is a JSON object with the following members: id: REQUIRED. The Transfer Identifier of the request. It is a string of at least 1 character consisting only of the characters of the base64url alphabet (Section 5 of [RFC4648]): "A" to "Z", "a" to "z", "0" to "9", "-", and "_". Its length MUST NOT exceed the "maxIdLength" limit of the recipient of the request (see Section 4.2). The sender SHOULD include at least 128 bits of randomness, for example 16 random octets encoded in base64url without padding, which yields 22 characters. A request whose Transfer Identifier does not meet these requirements is rejected with the "invalid-request" problem type. A Transfer Identifier is not globally unique and is never interpreted on its own. The recipient of a request stores and compares it only together with its scope (Section 6.4): Tishkin Expires 9 April 2027 [Page 17] Internet-Draft HMTP October 2026 * for a transfer request, the Sending Domain, that is, the domain of the key that signed the request as established by the verification procedure (Section 8.3). The host name and IP address of the Sending Server are not part of the scope, so that a retry is recognized even if it is sent from another host of the same Sending Domain; * for a submission request, the account of the authenticated Client. The sender MUST generate Transfer Identifiers that are unique within their scope. Identical Transfer Identifiers in different scopes, for example from two different Sending Domains, identify unrelated requests. from: REQUIRED. The Envelope Sender. The value is either a "Mailbox" as defined in Section 4.1.2 of [RFC5321], without the enclosing angle brackets, or the empty string, which denotes the null reverse-path. If "smtpUtf8" is true, the address MAY use the syntax extended by [RFC6531]. to: REQUIRED. A non-empty array of Recipient Objects, one for each Envelope Recipient. The array MUST NOT contain two Recipient Objects with the same address. Its length MUST NOT exceed the "maxRecipients" limit of the recipient of the request, if one is advertised. dsn: OPTIONAL. A JSON object that carries the per-message parameters of the Delivery Status Notification (DSN) extension [RFC3461]. It has the following members, both OPTIONAL: * "ret": the string "full" or "hdrs", with the semantics of the RET parameter of [RFC3461]; * "envid": a string with the semantics of the ENVID parameter of [RFC3461]. The value is carried in decoded form, without the "xtext" encoding used in SMTP, and is subject to the same length and character restrictions as in [RFC3461]. body: OPTIONAL. The type of the body of the Message. The value is one of "7bit", "8bitmime", and "binarymime", with the semantics of the BODY parameter values "7BIT", "8BITMIME" [RFC6152], and "BINARYMIME" [RFC3030], respectively. The default is "7bit". The sender MUST set this member to a value that correctly describes the Message. smtpUtf8: OPTIONAL. A boolean that is true if any address in the Tishkin Expires 9 April 2027 [Page 18] Internet-Draft HMTP October 2026 Envelope or any header field of the Message contains non-ASCII characters, as permitted by [RFC6531] and [RFC6532]. The default is false. The sender MUST set this member to true in that case. requireTls: OPTIONAL. A boolean that, when true, requests that the Message be transferred only over connections that are protected by TLS with certificate validation on every hop, with the semantics of the REQUIRETLS extension [RFC8689]. The default is false. HMTP hops always satisfy this requirement; SMTP hops are governed by [RFC8689]. A Recipient Object is a JSON object with the following members: address: REQUIRED. The Envelope Recipient. The value is a "Mailbox" as defined in Section 4.1.2 of [RFC5321], without the enclosing angle brackets, or, if "smtpUtf8" is true, as extended by [RFC6531]. dsn: OPTIONAL. A JSON object that carries the per-recipient parameters of the DSN extension [RFC3461]. It has the following members, both OPTIONAL: * "notify": an array of strings with the semantics of the NOTIFY parameter of [RFC3461]. The array contains either the single value "never", or one or more of the values "success", "failure", and "delay"; * "orcpt": a string with the semantics of the ORCPT parameter of [RFC3461], consisting of an address type, a semicolon, and the original recipient address, for example "rfc822;bob@example.net". The value is carried in decoded form, without the "xtext" encoding used in SMTP. When the domain part of an address is compared, for example to determine alignment (Section 8.4) or to perform discovery, it is first converted to A-labels and then compared without regard to case. The following example shows an Envelope: Tishkin Expires 9 April 2027 [Page 19] Internet-Draft HMTP October 2026 { "id": "3q2-7wEXAMPLEd9Kc1fQ0g", "from": "bounces+7f3a@example.com", "to": [ {"address": "bob@example.net"}, { "address": "carol@example.net", "dsn": { "notify": ["failure", "delay"], "orcpt": "rfc822;carol@example.net" } } ], "dsn": {"ret": "hdrs", "envid": "QQ314159"}, "body": "8bitmime" } 5.2. Content Object A Content Object carries a sequence of octets, called its content. It takes one of three forms, distinguished by the members present. A Content Object MUST contain exactly one of the members "data", "uri", and "segments". Inline: The content is carried in the request. The Content Object has the following member: data: REQUIRED. The content, encoded using base64 as defined in Section 4 of [RFC4648], with padding and without line breaks. Reference: The content is retrieved from a URI. A Content Object of this form is a Content Reference and has the following members: uri: REQUIRED. An absolute URI [RFC3986] with the "https" scheme from which the content is retrieved, as described in Section 5.2.1. size: REQUIRED. The size of the retrieved representation data in octets, before any transformation specified by "encoding". digest: REQUIRED. A Digest Object for the retrieved representation data, before any transformation specified by "encoding". expires: REQUIRED. A timestamp until which the sender guarantees that the content can be retrieved from the URI. The timestamp MUST be at least 24 hours after the time at which the request is sent and SHOULD be at least 7 days after it. Tishkin Expires 9 April 2027 [Page 20] Internet-Draft HMTP October 2026 encoding: OPTIONAL. The name of a transformation that is applied to the retrieved representation data to produce the content, as described in Section 5.3. If this member is absent, the content is the retrieved representation data itself. Composite: The content is the concatenation of the content of a sequence of segments. The Content Object has the following members: segments: REQUIRED. A non-empty array of Content Objects, each of which is either of the inline or of the reference form. A segment MUST NOT itself be of the composite form. size: REQUIRED. The size of the content, that is, the sum of the sizes of the content of all segments. The content of a composite Content Object is reconstructed by concatenating the content of its segments in the order in which they appear in the array. No octets are added between segments. The integrity of the reconstructed content follows from the integrity of each segment: inline segments are covered by the Content-Digest of the request, and reference segments by their "digest" member. Recipients MUST support composite Content Objects with at least 64 segments. A Digest Object is a JSON object whose member names are hash algorithm keys from the "Hash Algorithms for HTTP Digest Fields" registry established by [RFC9530] and whose values are the hashes computed with these algorithms, encoded using base64 as defined in Section 4 of [RFC4648]. A Digest Object MUST contain at least one of the members "sha-256" and "sha-512", and MAY contain additional members. Recipients MUST support "sha-256" and "sha-512", MUST ignore algorithms they do not support, and MUST verify the hash of every supported algorithm that is present. If a Digest Object contains no supported algorithm, the request is rejected with the "invalid-request" problem type. The "maxMessageSize" limit (Section 4.2) applies to the size of the reconstructed Message. Because the size of every segment is known before any content is retrieved, the recipient of a request can determine whether the limit is exceeded without retrieving any content. The following example shows a Message carried inline and the same Message carried as a single Content Reference: Tishkin Expires 9 April 2027 [Page 21] Internet-Draft HMTP October 2026 { "data": "RnJvbTogQWxpY2UgPGFsaWNlQGV4YW1wbGUuY29tPg0K..." } { "uri": "https://files.example.com/m/7f3a91c2e4d8", "size": 52428800, "digest": { "sha-256": "rbJw2yTgX0Gj3nVQb1Zu4eKcN9mF8sPq7LdW6xHtA0E=" }, "expires": "2026-01-08T12:00:00Z" } 5.2.1. Retrieval of Referenced Content The recipient of a request retrieves the content of a Content Reference with an HTTP GET request to its URI. The following rules apply: * The recipient MUST validate the TLS certificate of the host as described in [RFC9525]. * The recipient MUST NOT send credentials, such as cookies or an Authorization header field, in the retrieval request. It MAY sign the retrieval request as described in Section 8.2.1. * The recipient MAY follow redirections, but only to URIs with the "https" scheme, and SHOULD NOT follow more than 5 redirections. * The recipient MAY use range requests to resume an interrupted retrieval. * The representation data is the content of the response after any content coding has been removed. If its size differs from "size", or any supported hash in "digest" does not match, the retrieval has failed permanently with the "content-mismatch" problem type. The recipient SHOULD stop retrieving as soon as the received data exceeds "size". * A connection failure, a TLS failure, or a response with status code 408, 429, or 5xx is a temporary failure, and the recipient retries the retrieval. A response with any other error status code is a permanent failure with the "content-unavailable" problem type. The recipient of a request chooses, for each request, when it retrieves referenced content: Tishkin Expires 9 April 2027 [Page 22] Internet-Draft HMTP October 2026 Before responding: The recipient retrieves and verifies all Content References before it sends the response, which then has the status code 200 (OK). If retrieval fails temporarily, it responds with the "content-unavailable" problem type and a temporary enhanced status code. If retrieval fails permanently, it rejects the request with the corresponding problem type. After responding: The recipient accepts the Message for some or all Envelope Recipients and responds with the status code 202 (Accepted), which indicates that retrieval is still pending (see Section 6.3). By doing so, it accepts responsibility for retrieving the content and MUST complete the retrieval before the earliest "expires" timestamp of the Content References. If the retrieval fails permanently, or cannot be completed before that time, the recipient MUST treat the Message as undeliverable for all Envelope Recipients for which it was accepted and generate delivery status notifications as described in Section 9.3. This choice allows a recipient to retrieve small content synchronously while accepting very large Messages without keeping the request open for the duration of the retrieval. In either case, a server MUST NOT deliver a Message to a recipient mailbox, and MUST NOT make any part of it available to the recipient, before the Message has been completely reconstructed and verified. A server MUST NOT make the time of retrieval depend on actions of the recipient of the Message, such as opening the Message (see Section 14). The sender of a request MUST keep the content of every Content Reference available at its URI until its "expires" timestamp, unless every request containing the Content Reference has received a response with the status code 200 (OK), which indicates that the retrieval is complete or was not needed. After a response with the status code 202 (Accepted), the sender keeps the content available until its "expires" timestamp. A server that relays a Message MAY pass Content References on to the next hop unchanged, without retrieving them, if at least 24 hours remain before their "expires" timestamp. Otherwise, it MUST retrieve the content and either carry it inline or provide it through Content References of its own. A recipient MAY reject a request that contains a Content Reference whose "expires" timestamp is less than 24 hours after the time of receipt, with the "invalid-request" problem type. Tishkin Expires 9 April 2027 [Page 23] Internet-Draft HMTP October 2026 5.3. Attachments A composite Content Object allows a sender to transfer parts of a Message, such as the body of an attachment, by reference, while the reconstructed Message remains identical, octet for octet, to the Message as produced by its originator. DKIM signatures and other signatures computed over the Message therefore remain valid. To transfer an attachment by reference, the sender splits the Message into three segments: an inline segment containing everything up to the first octet of the body of the MIME body part, a reference segment containing the body of the body part, and an inline segment containing the remainder of the Message. Following [RFC2046], the CRLF that precedes a boundary delimiter belongs to the delimiter and therefore to the following inline segment. A Message may contain any number of such references, subject to the limit on segments described in Section 5.2. Attachments are usually encoded with the base64 Content-Transfer- Encoding [RFC2045], while the content stored at a URI is usually the original, unencoded file. The "encoding" member allows a Content Reference to refer to the unencoded file. This document defines the following encoding: base64: The retrieved representation data is encoded using base64 as defined in Section 6.8 of [RFC2045]. The encoded output is divided into lines of exactly 76 characters, except that the last line contains the remaining 1 to 76 characters. Lines are separated by CRLF. No CRLF follows the last line. If the representation data is empty, the content is empty. A sender MUST use the "base64" encoding only if the body of the MIME body part in the Message is exactly the output of this transformation. Senders that wish to use this encoding therefore produce base64-encoded body parts with lines of 76 characters, which is the most common practice. The size of the content produced by the "base64" encoding from n octets of representation data is 4 * ceil(n / 3) characters plus 2 octets for each line separator. Additional encodings can be registered as described in Section 15.6.3. A sender MUST NOT use an encoding other than "base64" unless the recipient of the request advertises support for it through a capability. The following example shows a Message with a 700 MiB attachment. The first segment contains the header section and the MIME structure up to the body of the attachment, which is followed by a CRLF and the closing boundary delimiter "--b1--" in the last segment: Tishkin Expires 9 April 2027 [Page 24] Internet-Draft HMTP October 2026 { "segments": [ { "data": "RnJvbTogQWxpY2UgPGFsaWNlQGV4YW1wbGUuY29tPg0K..." }, { "uri": "https://files.example.com/f/9b1c4e7a", "size": 734003200, "digest": { "sha-256": "Yk3qV0sJpRm9T2cFhWxN6dL1bA8eQu7ZgKi4oPyXwE0=" }, "expires": "2026-01-08T12:00:00Z", "encoding": "base64" }, { "data": "DQotLWIxLS0NCg==" } ], "size": 1004426786 } In this example, the first segment contains 1342 octets, the second segment produces 1004425434 octets after the "base64" encoding, and the last segment contains 10 octets. The same URI can be used in requests to any number of Receiving Servers, so that the attachment is uploaded by the originator only once. Receiving Servers that retrieve the same content for several Messages can recognize it by its digest. Messages that are protected end to end, such as encrypted OpenPGP or S/MIME messages, can only be transferred by reference as a whole. 5.4. Capabilities Capabilities allow HMTP to be extended without changing this document. A capability can define new members of the Request Object, the Envelope, the Recipient Object, Content Objects, the Response Object, and the Capabilities Document; new endpoints; new encodings; and new problem types. Examples of functionality that could be defined as capabilities include the transfer of several Messages in one request, a status endpoint for submitted Messages, and the recall of Messages that have not yet been delivered. 5.4.1. Capability Names A capability is identified by its name. A name takes one of two forms: Tishkin Expires 9 April 2027 [Page 25] Internet-Draft HMTP October 2026 Registered name: A string of 1 to 64 characters that consists of lowercase ASCII letters, digits, and hyphens, starts with a letter, and does not end with a hyphen, for example "future- release". A registered name MUST be registered in the "HMTP Capabilities" registry (Section 15.6.1) before it is used, which requires a publicly available specification (see Section 15). Implementations MUST NOT use a name of this form that is not registered. Registered names are intended for capabilities that are meant to be implemented interoperably by independent parties. URI: An absolute URI [RFC3986], for example "https://vendor.example.com/hmtp/future-release". Such a URI is only a unique name for the capability. It is compared with other names character by character, with case sensitivity, and is never dereferenced: implementations MUST NOT retrieve it as part of protocol processing, and it does not need to resolve to anything. Uniqueness follows from the control of the party that defines the capability over the authority component of the URI, typically a domain name it owns. URIs require no registration with IANA and are intended for private, vendor-specific, and experimental capabilities. The URI MAY point to human-readable documentation, but this has no significance for the protocol. A capability that starts as a URI and is later standardized receives a registered name. The two names identify distinct capabilities; a server MAY advertise both during a transition period, and a request lists the one whose definition it follows. 5.4.2. Advertisement and Use A server advertises the capabilities it supports in the "capabilities" member of its Capabilities Document. The value of each member is a JSON object containing the parameters of the capability, as defined by its specification; a capability without parameters has an empty object as its value. The specification of a capability states whether the capability is "must-understand". A must-understand capability changes the meaning of a request in a way that a recipient that does not support it cannot safely ignore. The following rules apply: * A sender MUST NOT use a capability that is not advertised by the recipient of the request, except that members defined by a capability that is not must-understand MAY be included regardless, because recipients that do not support them ignore them. * A sender MUST list every must-understand capability that a request uses in the "capabilities" member of the Request Object. Tishkin Expires 9 April 2027 [Page 26] Internet-Draft HMTP October 2026 * A recipient MUST reject a request that lists a capability it does not support with the "unsupported-capability" problem type. * A recipient MAY include members defined by a capability in its response if the capability is listed in the request or is not must-understand. Recipients of responses MUST ignore members they do not understand. To prevent collisions between members defined by independent parties, the following rules apply to the members that a capability adds to JSON objects defined by this document: * A capability with a registered name defines member names directly. The designated experts ensure that these names do not collide with names defined by this document or by other registered capabilities. * A capability identified by a URI adds exactly one member to each object it extends. The name of this member is the URI of the capability, and its value is a JSON object that contains all members defined by the capability for that object. * A capability with a registered name that defines a new endpoint registers the endpoint name (Section 15.6.2) and is advertised with an Endpoint Object in the "endpoints" member of a Version Object. A capability identified by a URI advertises the URIs of its endpoints in its own parameters instead. 5.4.3. Specifying a Capability The specification of a capability defines at least the following: * its name and whether it is must-understand; * its parameters in the Capabilities Document, including their types and default values; * the members it adds to the Request Object, the Envelope, the Recipient Object, Content Objects, the Response Object, and Endpoint Objects, and their meaning; * any new endpoints, encodings, and problem types; * the behavior of senders and recipients, including the behavior of a server that relays a Message that uses the capability to a next hop that does not support it, either over HMTP or over SMTP; and * its security and privacy considerations. Tishkin Expires 9 April 2027 [Page 27] Internet-Draft HMTP October 2026 5.4.4. Example This section shows a complete example of a hypothetical must- understand capability that allows the sender to request that a Message be held by the Receiving Server and released for delivery no earlier than a given time, similar to the SMTP FUTURERELEASE extension [RFC4865]. The capability is defined by a vendor and is therefore identified by a URI. Its specification could read as follows: Name: "https://vendor.example/hmtp/future-release". Must-understand: Yes. A recipient that ignored the capability would deliver the Message immediately. Parameters: "maxInterval": REQUIRED. The maximum number of seconds between the receipt of a request and the release time that the server accepts. Envelope members: "releaseAt": REQUIRED. A timestamp before which the recipient MUST NOT deliver the Message to a recipient mailbox. If it is more than "maxInterval" seconds after the time of receipt, the recipient rejects the request with the "invalid- request" problem type. Response members: None. Relaying: A server that relays the Message before the release time MUST NOT pass it to a next hop that does not advertise the capability; it holds the Message itself until the release time instead. A server that supports the capability advertises it in its Capabilities Document: Tishkin Expires 9 April 2027 [Page 28] Internet-Draft HMTP October 2026 { "versions": { "1": { "endpoints": { "transfer": { "uri": "/hmtp/v1/transfer" } } } }, "capabilities": { "https://vendor.example/hmtp/future-release": { "maxInterval": 604800 } } } A sender that uses the capability lists it in the request and adds the member defined by the capability to the Envelope, under the name of the capability: { "capabilities": [ "https://vendor.example/hmtp/future-release" ], "envelope": { "id": "Rt5yU8iO1pA4sD7fG0hJ2k", "from": "alice@example.com", "to": [{"address": "bob@example.net"}], "https://vendor.example/hmtp/future-release": { "releaseAt": "2026-01-02T09:00:00Z" } }, "message": { "data": "RnJvbTogQWxpY2UgPGFsaWNlQGV4YW1wbGUuY29tPg0K..." } } The URI "https://vendor.example/hmtp/future-release" in this example is never retrieved; it only names the capability. A server that does not support the capability rejects the request: Tishkin Expires 9 April 2027 [Page 29] Internet-Draft HMTP October 2026 HTTP/1.1 400 Bad Request Content-Type: application/problem+json { "type": "urn:ietf:params:hmtp:error:unsupported-capability", "title": "Unsupported capability", "status": 400, "detail": "https://vendor.example/hmtp/future-release", "smtpStatus": "5.5.4", "smtpReply": 555 } If the same capability were standardized and registered under the name "future-release", the server would advertise "future-release": {"maxInterval": 604800}, the request would list "future-release" in its "capabilities" member, and the Envelope would contain the member "releaseAt": "2026-01-02T09:00:00Z" directly. 6. Message Transfer A Sending Server transfers a Message to a Receiving Server by sending a transfer request to the transfer endpoint of the Receiving Server. All Envelope Recipients in one request MUST have domains for which discovery yielded the same transfer endpoint. A Sending Server sends a separate request for each transfer endpoint. 6.1. Request A transfer request is an HTTP POST request [RFC9110] to the transfer endpoint, with the following properties: * The content of the request is a Request Object (Section 5), and the Content-Type header field is "application/json". * The request MUST contain a Content-Digest header field [RFC9530] computed over the content of the request, using the "sha-256" or "sha-512" algorithm. * The request MUST be signed on behalf of the Sending Domain as described in Section 8, using the Signature-Input and Signature header fields [RFC9421]. * If the Envelope Sender is not empty, its domain MUST be aligned with the Sending Domain as described in Section 8.4. * The request does not use HTTP authentication. Receiving Servers ignore any Authorization header field in a transfer request. Tishkin Expires 9 April 2027 [Page 30] Internet-Draft HMTP October 2026 * The content of the request MAY use a content coding only if the Receiving Server has indicated support for it in an Accept- Encoding header field, as described in Section 12.5.3 of [RFC9110]. A Sending Server SHOULD reuse connections for several requests and MAY send several requests concurrently on one connection, within the limits that the Receiving Server sets, such as the SETTINGS_MAX_CONCURRENT_STREAMS setting of HTTP/2 [RFC9113]. This document does not define the transfer of several Messages in one request. Sending Servers SHOULD wait at least 10 minutes for the response after the request has been sent completely, consistent with the timeouts recommended in Section 4.5.3.2 of [RFC5321]. The following example shows a transfer request: NOTE: '\' line wrapping per RFC 8792 POST /hmtp/v1/transfer HTTP/1.1 Host: mx.example.net Content-Type: application/json Content-Digest: sha-256=:Cw2CRUGnwBRSPpU7qzJnP6Fk2zBdJ8u8mXh7sQe1zYI=: Signature-Input: hmtp=("@method" "@target-uri" "content-type" \ "content-digest");created=1767268800;expires=1767269100;\ keyid="hmtp2026._domainkey.example.com";alg="ed25519";tag="hmtp" Signature: hmtp=:3iXk1Lw3P1pZq9xH0M2eR8vUe6bJ4yD7nT5aC0fK2gS9\ hV1mQ4wL8oE6rB3tY7uI0pA5sD2fG9hJ1kL3zX8cVQ==: { "envelope": { "id": "3q2-7wEXAMPLEd9Kc1fQ0g", "from": "bounces+7f3a@example.com", "to": [ {"address": "bob@example.net"}, {"address": "carol@example.net"} ] }, "message": { "data": "RnJvbTogQWxpY2UgPGFsaWNlQGV4YW1wbGUuY29tPg0K..." } } 6.2. Processing by the Receiving Server A Receiving Server processes a transfer request as follows: Tishkin Expires 9 April 2027 [Page 31] Internet-Draft HMTP October 2026 1. It verifies that the request uses the POST method and that the media type and size of the content are acceptable. It rejects a request whose content exceeds its "maxRequestSize" limit with the "request-too-large" problem type. 2. It verifies the signature and the Content-Digest of the request as described in Section 8.3, including the alignment of the Envelope Sender (Section 8.4). 3. It parses the Request Object and validates it against Section 5. It rejects an invalid Request Object with the "invalid-request" problem type. 4. It checks the Transfer Identifier as described in Section 6.4. If the request is a retry of a request that has already been processed, it returns the stored response and does not process the request again. 5. It checks that it supports every capability listed in the "capabilities" member (Section 5.4). 6. It verifies that the size of the Message does not exceed its "maxMessageSize" limit and that the number of Envelope Recipients does not exceed its "maxRecipients" limit. 7. It determines, for each Envelope Recipient, whether it accepts the Message for that recipient. For an Envelope Recipient whose domain it does not serve, and for which it has no agreement to relay, it rejects the recipient with the "domain-not-served" problem type. Other decisions are a matter of local policy. 8. It retrieves referenced content as described in Section 5.2.1, either before responding or after responding. 9. It prepends trace header fields as described in Section 6.5, stores the Message for each accepted Envelope Recipient, and sends the response. A Receiving Server MAY perform these steps in a different order, as long as the result is the same. In particular, it MAY start verifying the signature before the content of the request has been received completely. 6.3. Response If the Receiving Server has processed the request, it responds with a Response Object and one of the following status codes, even if it has rejected the Message for some or all Envelope Recipients: Tishkin Expires 9 April 2027 [Page 32] Internet-Draft HMTP October 2026 200 (OK): The request has been processed completely. Either the request contains no Content References, or all referenced content has been retrieved and verified, or the Message has not been accepted for any Envelope Recipient. 202 (Accepted): The Message has been accepted for at least one Envelope Recipient, but the retrieval of referenced content is still pending. The Receiving Server has accepted responsibility for completing the retrieval later, as described in Section 5.2.1. A Receiving Server MUST NOT use this status code for a request that contains no Content References. In both cases, the results for the individual Envelope Recipients are final: a recipient with the result "accepted" remains accepted, and any later failure, including a failure of the pending retrieval, is reported through a delivery status notification (Section 9.3). The status code only tells the sender whether it still has to keep the referenced content available. If the request as a whole fails, the Receiving Server responds with a 4xx or 5xx status code and a problem details object as described in Section 9.1; in that case, the Message has not been accepted for any Envelope Recipient. The Response Object is a JSON object with the media type "application/json" and the following members: queueId: OPTIONAL. A string assigned by the Receiving Server that identifies the Message in its systems, such as a queue identifier. It is intended for logging and diagnostics. recipients: REQUIRED. An array of Recipient Result Objects, exactly one for each Envelope Recipient, in the same order as in the "to" member of the Envelope. A Recipient Result Object is a JSON object with the following members: address: REQUIRED. The address of the Envelope Recipient, as given in the request. result: REQUIRED. One of the following strings: * "accepted": the Receiving Server has accepted responsibility for delivering or relaying the Message to this recipient, with the semantics of Section 6.1 of [RFC5321]. It MUST NOT lose the Message, and if it later fails to deliver it, it generates a delivery status notification as described in Section 9.3. Tishkin Expires 9 April 2027 [Page 33] Internet-Draft HMTP October 2026 * "deferred": the Message was not accepted for this recipient because of a temporary condition. The sender MAY retry delivery to this recipient later. * "rejected": the Message was not accepted for this recipient because of a permanent condition. The sender MUST NOT retry delivery to this recipient. problem: REQUIRED if "result" is "deferred" or "rejected", and absent otherwise. A problem details object, as described in Section 9.1, that describes the reason. Its "smtpStatus" member MUST have the class 4 if "result" is "deferred" and the class 5 if "result" is "rejected". The following example shows a response in which the Message was accepted for one recipient and rejected for another: HTTP/1.1 200 OK Content-Type: application/json { "queueId": "4Y7mKq2ZtR", "recipients": [ { "address": "bob@example.net", "result": "accepted" }, { "address": "carol@example.net", "result": "rejected", "problem": { "type": "urn:ietf:params:hmtp:error:unknown-recipient", "title": "Unknown recipient", "detail": "The mailbox carol@example.net does not exist.", "smtpStatus": "5.1.1", "smtpReply": 550 } } ] } 6.4. Retries and Idempotency The Transfer Identifier allows a Receiving Server to recognize a request that is retried because the sender did not receive the response, for example because the connection was lost after the Receiving Server had accepted the Message. Tishkin Expires 9 April 2027 [Page 34] Internet-Draft HMTP October 2026 The scope of a Transfer Identifier is the Sending Domain for transfer requests, and the authenticated account of the Client for submission requests (see Section 5.1). The key under which a Receiving Server stores and looks up a Transfer Identifier is therefore the pair (Sending Domain, Transfer Identifier) for transfer requests and the pair (account, Transfer Identifier) for submission requests. The Sending Domain is the one established by verifying the signature of the request (Section 8.3), never a value taken from the content of the request. A sender MUST NOT use the same Transfer Identifier within one scope for requests with different content. When a Receiving Server sends a 200 (OK) or 202 (Accepted) response, it MUST store the key, a hash of the content of the request, and the response, and MUST retain them for at least 24 hours. When it receives a request whose key matches a stored entry: * If the hash of the content of the request matches, the Receiving Server MUST NOT process the request again and MUST return the stored response. If the stored response has the status code 202 (Accepted) and the retrieval of referenced content has been completed in the meantime, it MAY return the status code 200 (OK) with the same Response Object instead. Senders MUST NOT retry requests solely to learn whether a retrieval has been completed. * Otherwise, it MUST reject the request with the "id-conflict" problem type. If a request with the same scope and Transfer Identifier is still being processed, the Receiving Server MUST NOT process the second request concurrently; it MAY respond with the "server-unavailable" problem type and a Retry-After header field. A request that fails as a whole does not need to be stored, because the Message has not been accepted for any recipient. A sender retries a request as follows: * If the sender has not received a response, or has received a response indicating a temporary failure of the whole request, it MAY send the identical request again, with the same Transfer Identifier and the same content. It signs each attempt anew. It SHOULD send the retry within 24 hours of the first attempt, so that the Receiving Server can recognize it. * For Envelope Recipients with the result "deferred", the sender sends a new request containing only those recipients, with a new Transfer Identifier. Tishkin Expires 9 April 2027 [Page 35] Internet-Draft HMTP October 2026 * The sender MUST NOT retry a request, or deliver to an Envelope Recipient, after a permanent failure. A failure of the whole request is temporary if the "smtpStatus" member of the problem details object has the class 4. If the response does not contain a problem details object with an "smtpStatus" member, the status codes 408, 429, and 5xx, as well as connection failures, are temporary, and all other status codes are permanent. The sender MUST honor a Retry-After header field [RFC9110] in the response. Otherwise, the intervals between retries and the time after which the sender gives up SHOULD follow the guidance of Section 4.5.4.1 of [RFC5321]. When the sender gives up, it generates a delivery status notification as described in Section 9.3. Before each retry, the sender repeats discovery if its cached results have expired. 6.5. Trace Information A server that accepts responsibility for a Message, whether through transfer or submission, MUST prepend a Received header field to the Message. The field follows the syntax of Section 4.4 of [RFC5321] and has the following content: * The "from" clause contains, for a transfer request, the Sending Domain, followed by the IP address of the sender of the request in the "TCP-info" part, for example from example.com (hmtp- out.example.com [192.0.2.25]). For a submission request, it contains the IP address of the Client as an address literal, followed by the same address literal in the "TCP-info" part, for example from [198.51.100.7] ([198.51.100.7]). For privacy reasons, a Submission Server MAY use the address literal [127.0.0.1] in both places instead of the IP address of the Client. * The "by" clause contains the host name of the server. * The "with" clause contains "HMTP" for a transfer request and "HMTPA" for a submission request (see Section 15.4). * The "id" clause, if present, contains the "queueId" of the response. * The "for" clause SHOULD be included only if the request has a single Envelope Recipient (see Section 14). Tishkin Expires 9 April 2027 [Page 36] Internet-Draft HMTP October 2026 A server MAY also prepend other trace header fields, such as an Authentication-Results header field [RFC8601] that records the result of the verification described in Section 8.3. Prepending header fields is the only modification that servers make to a Message during transfer. When the Message is represented as a Content Object, a server prepends header fields by adding an inline segment that contains them before the existing content; existing Content References can thus be passed on unchanged. A Receiving Server SHOULD reject a Message that contains more Received header fields than a locally configured limit with the "loop-detected" problem type, as described in Section 6.3 of [RFC5321]. The following example shows a Received header field added by a Receiving Server: Received: from example.com (hmtp-out.example.com [192.0.2.25]) by mx.example.net with HMTP id 4Y7mKq2ZtR; Thu, 01 Jan 2026 12:00:01 +0000 7. Message Submission A Client submits a Message by sending a submission request to the submission endpoint of its Submission Server. A submission request is an HTTP POST request with the same content as a transfer request (see Section 6.1), with the following differences: * The Client authenticates using HTTP authentication as described in Section 7.1. The request does not need to be signed, and the Content-Digest header field is OPTIONAL. * The Envelope Recipients can have any domain. The Submission Server processes the request as described in Section 6.2, except that it authenticates the Client instead of verifying a signature, accepts Envelope Recipients in any domain, verifies the sender addresses as described in Section 7.2, and validates the Message as described in Section 7.3. It responds with a Response Object as described in Section 6.3. The result "accepted" indicates that the Submission Server has accepted responsibility for delivering the Message to the recipient; the outcome of the final delivery is reported through delivery status notifications (Section 9.3). Tishkin Expires 9 April 2027 [Page 37] Internet-Draft HMTP October 2026 The Transfer Identifier of a submission request is scoped to the authenticated account, as described in Section 6.4, so that a Client can safely retry a submission after a lost response. 7.1. Client Authentication The "authentication" member of the Submission Endpoint Object (Section 4.2.1) lists the HTTP authentication schemes [RFC9110] accepted by the Submission Server for the submission and identities endpoints, using the scheme names from the "HTTP Authentication Scheme Registry". Scheme names are compared without regard to case. This document uses the following schemes: basic: The "Basic" scheme [RFC7617]. The user-id is the name of the account at the Submission Server. Servers that support this scheme SHOULD include the "charset" parameter with the value "UTF- 8" in their challenges. This scheme allows existing SMTP AUTH credentials, including application-specific passwords, to be used with HMTP. bearer: The "Bearer" scheme [RFC6750]. Access tokens are obtained using OAuth 2.0 [RFC6749]. The Client discovers the authorization servers and the supported scopes from the OAuth 2.0 Protected Resource Metadata [RFC9728] of the Submission Server. A Submission Server MUST support at least one of these schemes and SHOULD support "bearer". Clients SHOULD support both. If a submission request or a request to the identities endpoint does not contain valid credentials, the server responds with the status code 401 (Unauthorized), a WWW-Authenticate header field containing a challenge for each accepted scheme, and a problem details object with the "authentication-required" problem type if no credentials were provided, or the "authentication-failed" problem type if the provided credentials are not valid. A challenge for the "Bearer" scheme SHOULD include the "resource_metadata" parameter defined in [RFC9728]. If a bearer token is valid but lacks a required scope, the server responds as specified in [RFC6750]. Servers SHOULD limit the rate of failed authentication attempts. Credentials for submission MUST NOT be sent to a transfer endpoint. The following example shows a rejected submission request: Tishkin Expires 9 April 2027 [Page 38] Internet-Draft HMTP October 2026 NOTE: '\' line wrapping per RFC 8792 HTTP/1.1 401 Unauthorized WWW-Authenticate: Basic realm="hmtp", charset="UTF-8" WWW-Authenticate: Bearer realm="hmtp", resource_metadata=\ "https://hmtp.provider.example/.well-known/oauth-protected-resource" Content-Type: application/problem+json { "type": "urn:ietf:params:hmtp:error:authentication-required", "title": "Authentication required", "status": 401, "smtpStatus": "5.7.0", "smtpReply": 530 } 7.2. Authorization of Sender Addresses A Submission Server determines the set of identities that the authenticated Client is authorized to use, as returned by the identities endpoint (Section 7.4). It MUST verify that each of the following addresses is covered by one of these identities: * the Envelope Sender, unless it is empty; * each address in the From header field of the Message; * the address in the Sender header field of the Message, if present. An empty Envelope Sender is permitted for Messages that require it, such as message disposition notifications [RFC8098]. If any of these addresses is not authorized, the Submission Server rejects the request with the "sender-not-authorized" problem type. When the Submission Server acts as a Sending Server for the Message, it signs the transfer requests with a key of a Sending Domain that is aligned with the Envelope Sender (Section 8.4). A Submission Server therefore only includes in the identities of a Client addresses for which it can produce such signatures. 7.3. Message Validation and Modification A Submission Server MUST verify that the Message conforms to [RFC5322], and in particular that it contains exactly one Date header field and exactly one From header field. It MUST reject a Message that does not conform with the "invalid-request" problem type, except as follows. Tishkin Expires 9 April 2027 [Page 39] Internet-Draft HMTP October 2026 A Submission Server MAY add a Date header field or a Message-ID header field if either is missing, as permitted by Section 8 of [RFC6409]. Besides adding these fields, prepending trace header fields (Section 6.5), and prepending DKIM-Signature header fields [RFC6376], a Submission Server MUST NOT modify the Message. The Client is responsible for any other content of the Message, including the removal of Bcc header fields (Section 3.6.3 of [RFC5322]). 7.4. Identities The identities endpoint returns the identities that the authenticated Client is authorized to use as originator addresses. Its URI is given by the "identities" member of the Submission Endpoint Object (Section 4.2.1). A Client sends an HTTP GET request to the endpoint, authenticated as described in Section 7.1. The server responds with the status code 200 (OK) and a JSON object with the media type "application/json" and the following member: identities: REQUIRED. An array of Identity Objects. An Identity Object is a JSON object with the following members: email: REQUIRED. An address that the Client may use. If the local part of the address is the single character "_", as in "_@example.org", the Client may use any address in that domain, following the convention of Section 6 of [RFC8621]. name: OPTIONAL. A display name associated with the address, which the Client can use in the From header field. The server SHOULD include an ETag header field in the response and support conditional requests [RFC9110]. The response is specific to the authenticated account and MUST be marked accordingly for caches, for example with "Cache-Control: private". Tishkin Expires 9 April 2027 [Page 40] Internet-Draft HMTP October 2026 GET /hmtp/v1/identities HTTP/1.1 Host: hmtp.provider.example Authorization: Bearer mF_9.B5f-4.1JqM HTTP/1.1 200 OK Content-Type: application/json Cache-Control: private ETag: "a7c3" { "identities": [ {"email": "alice@example.com", "name": "Alice Example"}, {"email": "*@sales.example.com"} ] } 8. Authentication and Signing Every transfer request is signed by the Sending Server using HTTP Message Signatures [RFC9421]. The public keys are published in DNS using the key record format and location defined by DKIM [RFC6376], so that domains can use their existing DNS infrastructure and delegation practices. Successful verification establishes the Sending Domain, which the Receiving Server can use for reputation and policy decisions. 8.1. Signing Keys A signing key is identified by a selector and a domain, as in DKIM (Section 3.1 of [RFC6376]). The public key is published as a DKIM key record (Section 3.6.1 of [RFC6376]) in a TXT record at the following name: ._domainkey. The tags of the key record are interpreted as follows: * "k" (key type): the value "ed25519" [RFC8463] corresponds to the signature algorithm "ed25519", and the value "rsa" corresponds to the signature algorithm "rsa-v1_5-sha256", both as defined in Section 3.3 of [RFC9421]. Records with other key types MUST NOT be used for HMTP. * "p" (public key data): an empty value means that the key has been revoked. RSA keys MUST have a modulus of at least 2048 bits. Tishkin Expires 9 April 2027 [Page 41] Internet-Draft HMTP October 2026 * "s" (service type): the record can be used for HMTP only if this tag is absent, or if its value includes "*" or "hmtp". The service type "hmtp" is registered in Section 15.3. * "h" (acceptable hash algorithms): if present for a record of key type "rsa", the value MUST include "sha256". * "t" (flags): if the flag "y" is present, the domain is testing the key. In accordance with the meaning of this flag in [RFC6376], a verifier MUST NOT treat a request signed with such a key differently from an unsigned request, and therefore rejects it. A domain SHOULD use a dedicated selector for HMTP with the service type "hmtp" only. Such a key record is ignored by DKIM verifiers, which keeps keys for HMTP request signing separate from keys for DKIM message signing (see Section 13.4). A domain MAY instead use an existing DKIM key whose record permits all service types; this simplifies deployment but forgoes this separation. Signers and verifiers MUST implement both "ed25519" and "rsa- v1_5-sha256". Signers SHOULD use "ed25519". To replace a key, a domain publishes a new key record under a new selector, starts signing with the new key, and keeps the old key record published for at least the maximum lifetime of a signature plus the TTL of the old record before revoking or removing it. 8.2. Signature Construction The Sending Server creates a signature as specified in Section 3.1 of [RFC9421], with the following requirements: * The covered components MUST include "@method", "@target-uri", "content-type", and "content-digest". The Content-Digest header field MUST be present in the request, as required in Section 6.1. * The signature parameters (Section 2.3 of [RFC9421]) MUST include "created", "expires", "keyid", "alg", and "tag": - "created" is the time at which the signature was created. - "expires" MUST NOT be more than 300 seconds after "created". - "keyid" is the DNS name of the key record, in the form ._domainkey., where the domain is in A-label form, without a trailing dot. The domain in this name is the Sending Domain. Tishkin Expires 9 April 2027 [Page 42] Internet-Draft HMTP October 2026 - "alg" is the signature algorithm that corresponds to the key type of the key record. - "tag" is the string "hmtp". * The signature label is not significant; "hmtp" is RECOMMENDED. A request MAY carry more than one signature with the tag "hmtp", for example during a key rollover or a change of algorithm. Other signatures that the request carries are ignored for the purposes of HMTP. The following example shows the signature-related header fields of a transfer request: NOTE: '\' line wrapping per RFC 8792 Content-Digest: sha-256=:Cw2CRUGnwBRSPpU7qzJnP6Fk2zBdJ8u8mXh7sQe1zYI=: Signature-Input: hmtp=("@method" "@target-uri" "content-type" \ "content-digest");created=1767268800;expires=1767269100;\ keyid="hmtp2026._domainkey.example.com";alg="ed25519";tag="hmtp" Signature: hmtp=:3iXk1Lw3P1pZq9xH0M2eR8vUe6bJ4yD7nT5aC0fK2gS9\ hV1mQ4wL8oE6rB3tY7uI0pA5sD2fG9hJ1kL3zX8cVQ==: The corresponding key record is: hmtp2026._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=ed25519; s=hmtp; " "p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo=" ) 8.2.1. Signing of Retrieval Requests A Receiving Server MAY sign the requests with which it retrieves referenced content (Section 5.2.1), using a key of its own domain published as described in Section 8.1. Such a signature covers at least "@method" and "@target-uri", contains the signature parameters required in Section 8.2, and uses the tag "hmtp-retrieval". A server that hosts referenced content MAY use such signatures to restrict access to the content, for example to the domains of the Envelope Recipients. A Receiving Server that does not sign its retrieval requests can only retrieve content that does not require such signatures. 8.3. Verification Procedure The Receiving Server verifies a transfer request as follows. Unless stated otherwise, a failure of any step causes the request to be rejected with the "signature-invalid" problem type. Tishkin Expires 9 April 2027 [Page 43] Internet-Draft HMTP October 2026 1. It selects the signatures in the request whose "tag" parameter is "hmtp". If there is none, verification fails. If there are several, it processes each of them until one is verified successfully. 2. It verifies that the covered components and signature parameters meet the requirements of Section 8.2 and that it supports the algorithm given in "alg". 3. It verifies that "created" is not later than the current time and that "expires" is not earlier than the current time, both evaluated at the time the header section of the request was received, allowing for a clock skew of no more than 60 seconds, and that "expires" is not more than 300 seconds after "created". 4. It verifies that "keyid" has the form ._domainkey., where the selector has the syntax defined in [RFC6376]. Because a selector cannot contain the label "_domainkey", the Sending Domain is the part of the name that follows the first "_domainkey" label. 5. It queries DNS for TXT records at the name given in "keyid". If the query fails temporarily, it rejects the request with the "key-unavailable" problem type, which is a temporary failure. If the name does not exist, or if the response does not contain exactly one valid key record, verification fails. DNS responses SHOULD be validated using DNSSEC [RFC4033] when available. 6. It verifies that the key record meets the requirements of Section 8.1 and that its key type corresponds to "alg". 7. It verifies the signature as specified in Section 3.2 of [RFC9421]. 8. It verifies that the Content-Digest header field matches the content of the request as specified in [RFC9530]. If it does not, it rejects the request with the "digest-mismatch" problem type. 9. It verifies the alignment of the Envelope Sender with the Sending Domain as described in Section 8.4. If verification fails, the response MAY include an Accept-Signature header field as described in [RFC9421]. A Receiving Server that terminates TLS in a reverse proxy MUST ensure that the covered components reach the verifier unchanged, or perform verification in the proxy. Tishkin Expires 9 April 2027 [Page 44] Internet-Draft HMTP October 2026 8.4. Sender Alignment The domain of a non-empty Envelope Sender is aligned with the Sending Domain if it is equal to the Sending Domain or is a subdomain of it. For example, the Envelope Sender "bounces@mail.example.com" is aligned with the Sending Domain "example.com", but not with the Sending Domain "example.org". A Receiving Server MUST reject a transfer request in which the Envelope Sender is not empty and is not aligned with the Sending Domain, with the "sender-not-aligned" problem type, unless the Receiving Server has a local agreement that authorizes the Sending Domain to relay Messages for other domains. Such agreements are used, for example, with inbound filtering services and backup servers that relay Messages to the Receiving Server on behalf of the recipient domain (see Section 10.3). If the Envelope Sender is empty, any Sending Domain is acceptable, and the Receiving Server applies its local policy based on the Sending Domain. Alignment authenticates the Envelope Sender's domain, not the author of the Message. The domains in the From header field continue to be authenticated by DKIM and DMARC at the message level. A server that forwards Messages to another domain, such as a mailing list or a forwarding service, uses an Envelope Sender in a domain for which it can produce aligned signatures. As in SMTP, such a server typically rewrites the Envelope Sender so that delivery status notifications are returned to it. 8.5. Third-Party Senders A domain can authorize a third party, such as an email service provider, to send Messages with Envelope Senders in its domain. Because HMTP keys are published in the same way as DKIM keys, the same delegation methods apply: Delegation of a selector: The domain publishes a CNAME record at a selector name that points to a key record maintained by the provider, for example: esp1._domainkey.example.com. 3600 IN CNAME ( example-com.keys.esp.example. ) Tishkin Expires 9 April 2027 [Page 45] Internet-Draft HMTP October 2026 The provider signs with "keyid" set to "esp1._domainkey.example.com"; the Sending Domain is "example.com". The domain can revoke the authorization at any time by removing the CNAME record. Publication of a provider key: The domain publishes, under a selector of its own, a public key whose private key is held by the provider. Provider domain: The provider uses Envelope Senders in its own domain and signs as that domain. The reputation of the Sending Domain then accrues to the provider rather than to its customer. Because signatures are not bound to IP addresses, a Sending Server can send requests through any network path, including forward proxies and HTTP intermediaries, provided that the covered components and the content of the request are not modified on the way. 9. Delivery Status and Errors HMTP reports failures in two ways: synchronously, through problem details objects in responses, and asynchronously, through delivery status notifications. 9.1. Problem Details When a request fails as a whole, the server responds with a 4xx or 5xx status code and a problem details object [RFC9457] with the media type "application/problem+json". When the Message is not accepted for an individual Envelope Recipient, the reason is given as a problem details object in the "problem" member of the Recipient Result Object (Section 6.3); in that case, the "status" member MAY be omitted and is ignored if present. Problem types defined for HMTP have URIs of the form urn:ietf:params:hmtp:error: and are registered as described in Section 15.6.4. Servers MAY use other problem type URIs as permitted by [RFC9457]. This document defines the following extension members of problem details objects: smtpStatus: REQUIRED in problem details objects sent by HMTP Tishkin Expires 9 April 2027 [Page 46] Internet-Draft HMTP October 2026 servers. An enhanced mail system status code [RFC3463] in the form "class.subject.detail". The class MUST be 4 (persistent transient failure) or 5 (permanent failure). The class determines whether the failure is temporary or permanent, also for problem types that are unknown to the recipient of the problem details object. smtpReply: OPTIONAL. An SMTP reply code [RFC5321] that corresponds to the failure. It is used when the failure is reported over SMTP, for example by a gateway (Section 10.3) or in a delivery status notification (Section 9.3). If it is absent, the reply code from Table 1 is used for registered problem types, and 451 or 550 otherwise, depending on the class of "smtpStatus". The "detail" member SHOULD be suitable for inclusion in a delivery status notification sent to the Envelope Sender. The language of human-readable members can be indicated with the Content-Language header field. Responses with the status codes 429 (Too Many Requests) [RFC6585] and 503 (Service Unavailable) SHOULD include a Retry-After header field. The following example shows a request that was rejected as a whole: HTTP/1.1 403 Forbidden Content-Type: application/problem+json Content-Language: en { "type": "urn:ietf:params:hmtp:error:sender-not-aligned", "title": "Envelope Sender not aligned with Sending Domain", "status": 403, "detail": "example.org is not aligned with example.com.", "smtpStatus": "5.7.1", "smtpReply": 550 } 9.2. Mapping to SMTP Status Codes Table 1 lists the problem types defined by this document, whether they apply to a whole request ("Request"), to an individual Envelope Recipient ("Recipient"), or to both, and the HTTP status code, enhanced status code, and SMTP reply code to be used with them. Where two codes are given, the first is used for a temporary and the second for a permanent failure. Tishkin Expires 9 April 2027 [Page 47] Internet-Draft HMTP October 2026 +=========================+===========+=======+==========+=======+ | Name | Scope | HTTP | Enhanced | Reply | | | | | Status | | +=========================+===========+=======+==========+=======+ | invalid-request | Request | 400 | 5.5.2 | 501 | +-------------------------+-----------+-------+----------+-------+ | unsupported-capability | Request | 400 | 5.5.4 | 555 | +-------------------------+-----------+-------+----------+-------+ | id-conflict | Request | 409 | 5.5.4 | 501 | +-------------------------+-----------+-------+----------+-------+ | signature-invalid | Request | 403 | 5.7.0 | 550 | +-------------------------+-----------+-------+----------+-------+ | key-unavailable | Request | 503 | 4.4.3 | 451 | +-------------------------+-----------+-------+----------+-------+ | digest-mismatch | Request | 400 | 5.7.7 | 554 | +-------------------------+-----------+-------+----------+-------+ | sender-not-aligned | Request | 403 | 5.7.1 | 550 | +-------------------------+-----------+-------+----------+-------+ | authentication-required | Request | 401 | 5.7.0 | 530 | +-------------------------+-----------+-------+----------+-------+ | authentication-failed | Request | 401 | 5.7.8 | 535 | +-------------------------+-----------+-------+----------+-------+ | sender-not-authorized | Request | 403 | 5.7.1 | 550 | +-------------------------+-----------+-------+----------+-------+ | request-too-large | Request | 413 | 5.3.4 | 552 | +-------------------------+-----------+-------+----------+-------+ | message-too-large | Both | 413 | 5.3.4 | 552 | +-------------------------+-----------+-------+----------+-------+ | too-many-recipients | Request | 422 | 4.5.3 | 452 | +-------------------------+-----------+-------+----------+-------+ | rate-limited | Request | 429 | 4.7.0 | 451 | +-------------------------+-----------+-------+----------+-------+ | server-unavailable | Request | 503 | 4.3.2 | 421 | +-------------------------+-----------+-------+----------+-------+ | content-unavailable | Request | 502 / | 4.4.1 / | 451 / | | | | 422 | 5.6.0 | 554 | +-------------------------+-----------+-------+----------+-------+ | content-mismatch | Request | 422 | 5.7.7 | 554 | +-------------------------+-----------+-------+----------+-------+ | loop-detected | Request | 422 | 5.4.6 | 554 | +-------------------------+-----------+-------+----------+-------+ | policy-rejected | Both | 403 | 4.7.1 / | 451 / | | | | | 5.7.1 | 550 | +-------------------------+-----------+-------+----------+-------+ | unknown-recipient | Recipient | - | 5.1.1 | 550 | +-------------------------+-----------+-------+----------+-------+ | invalid-address | Recipient | - | 5.1.3 | 553 | +-------------------------+-----------+-------+----------+-------+ Tishkin Expires 9 April 2027 [Page 48] Internet-Draft HMTP October 2026 | domain-not-served | Recipient | - | 5.1.2 | 550 | +-------------------------+-----------+-------+----------+-------+ | mailbox-disabled | Recipient | - | 5.2.1 | 550 | +-------------------------+-----------+-------+----------+-------+ | mailbox-full | Recipient | - | 4.2.2 / | 452 / | | | | | 5.2.2 | 552 | +-------------------------+-----------+-------+----------+-------+ | routing-failed | Recipient | - | 4.4.4 / | 451 / | | | | | 5.4.4 | 550 | +-------------------------+-----------+-------+----------+-------+ | conversion-required | Recipient | - | 5.6.3 | 554 | +-------------------------+-----------+-------+----------+-------+ | tls-required | Recipient | - | 5.7.30 | 550 | +-------------------------+-----------+-------+----------+-------+ Table 1: HMTP Problem Types The meaning of each problem type is as follows: invalid-request: The request content is not a valid Request Object, the Message does not conform to [RFC5322], or another requirement of this document is not met. unsupported-capability: The request lists a capability that the server does not support. id-conflict: The Transfer Identifier has already been used for a request with different content (Section 6.4). signature-invalid: The request has no valid HMTP signature (Section 8.3). key-unavailable: The key record could not be retrieved because of a temporary DNS failure. digest-mismatch: The Content-Digest header field does not match the content of the request. sender-not-aligned: The Envelope Sender is not aligned with the Sending Domain (Section 8.4). authentication-required: A submission request or identities request carries no credentials. authentication-failed: The credentials of a submission request or identities request are not valid. This problem type corresponds to the SMTP enhanced status code 5.7.8 defined in [RFC4954]. Tishkin Expires 9 April 2027 [Page 49] Internet-Draft HMTP October 2026 sender-not-authorized: The Client is not authorized to use an originator address of the Message (Section 7.2). request-too-large: The content of the request exceeds the "maxRequestSize" limit. The sender can transfer part of the Message by reference instead. message-too-large: The size of the Message exceeds a limit of the server or of a recipient mailbox. too-many-recipients: The number of Envelope Recipients exceeds the "maxRecipients" limit. The sender MUST NOT repeat the request unchanged; it splits the Envelope Recipients into several requests with new Transfer Identifiers. rate-limited: The sender has exceeded a rate limit of the server. server-unavailable: The server is temporarily unable to process requests. content-unavailable: Referenced content could not be retrieved (Section 5.2.1). content-mismatch: The size or digest of referenced content does not match its Content Reference. This problem type corresponds to the enhanced status code for message integrity failures defined in [RFC3463]. loop-detected: The Message has passed through too many servers (Section 6.5). policy-rejected: The Message was rejected by the local policy of the server, for example on the basis of the reputation of the Sending Domain or the content of the Message. unknown-recipient: The recipient mailbox does not exist. invalid-address: The address of the Envelope Recipient is syntactically invalid. domain-not-served: The server does not accept Messages for the domain of the Envelope Recipient and has no agreement to relay them. mailbox-disabled: The recipient mailbox exists but does not accept Messages. mailbox-full: The recipient mailbox has exceeded its storage limit. Tishkin Expires 9 April 2027 [Page 50] Internet-Draft HMTP October 2026 routing-failed: The server was unable to route the Message toward the recipient, for example because the recipient domain supports neither HMTP nor, for a server that supports fallback, SMTP. conversion-required: Delivery requires a conversion of the Message that the server does not perform, for example because an SMTP server used for fallback does not support an extension that the Message requires (Section 10.1). tls-required: The Envelope requests REQUIRETLS, and the requirement cannot be satisfied on the path to the recipient. The enhanced status code is defined in [RFC8689]. 9.3. Delivery Status Notifications When a Message cannot be delivered after it has been accepted, or when a delivery status notification (DSN) is requested on success or delay, a DSN is generated as specified in [RFC3461] and [RFC3464]. The DSN parameters of the Envelope (Section 5.1) have the same semantics as the corresponding SMTP parameters. In particular: * A Sending Server generates a DSN for an Envelope Recipient that was rejected by the Receiving Server or for which it has given up retrying (Section 6.4). The Receiving Server does not generate a DSN for a recipient that it rejected in its response. * A Receiving Server generates a DSN for an Envelope Recipient for which it accepted the Message but later failed to deliver it, including when the retrieval of referenced content fails after the response (Section 5.2.1). * A DSN is sent to the Envelope Sender of the original Message, with an empty Envelope Sender. No DSN is generated for a Message whose Envelope Sender is empty. * A server that relays a Message passes the DSN parameters on to the next hop, whether that hop uses HMTP or SMTP. The fields of the DSN are filled in as follows: * The "Reporting-MTA" field contains the host name of the reporting server with the type "dns". * The "Remote-MTA" field, if present, contains the TargetName of the HMTP Endpoint or, after a fallback to SMTP (Section 10), the host name of the SMTP server, with the type "dns". Tishkin Expires 9 April 2027 [Page 51] Internet-Draft HMTP October 2026 * The "Status" field contains the enhanced status code from the "smtpStatus" member of the problem details object. A Sending Server that gives up after retries uses the code 4.4.7 if no more specific code is available. * The "Diagnostic-Code" field uses the diagnostic type "smtp" and contains the SMTP reply code, the enhanced status code, and the "detail" member of the problem details object, if any. * The "Original-Recipient" and "Original-Envelope-Id" fields are derived from the "orcpt" and "envid" members of the Envelope. If the Envelope requests the return of the full Message ("ret" is "full") and the Message is very large, the DSN MAY contain only the header section of the Message. DSNs are ordinary Messages and are transferred using HMTP or SMTP like any other Message. 9.3.1. Example The following DSN is generated by the Sending Server in the example of Section 10.1.1 for the rejected Envelope Recipient "dave@example.org". It uses the "multipart/report" media type [RFC6522] with a "message/delivery-status" part [RFC3464]. Because the "ret" member of the Envelope is "hdrs", the DSN contains only the header section of the original Message: Date: Thu, 01 Jan 2026 12:00:03 +0000 From: Mail Delivery System To: alice@example.com Subject: Delivery Status Notification (Failure) Message-ID: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="dsn-b1" --dsn-b1 Content-Type: text/plain; charset=us-ascii Your message could not be delivered to the following recipient: dave@example.org 550 5.1.1 Recipient address rejected --dsn-b1 Content-Type: message/delivery-status Tishkin Expires 9 April 2027 [Page 52] Internet-Draft HMTP October 2026 Reporting-MTA: dns; hmtp.provider.example Original-Envelope-Id: QQ314159 Arrival-Date: Thu, 01 Jan 2026 11:59:58 +0000 Original-Recipient: rfc822;dave@example.org Final-Recipient: rfc822;dave@example.org Action: failed Status: 5.1.1 Remote-MTA: dns; mx.example.org Diagnostic-Code: smtp; 550 5.1.1 : Recipient address rejected --dsn-b1 Content-Type: text/rfc822-headers Received: from [198.51.100.7] ([198.51.100.7]) by hmtp.provider.example with HMTPA id S-20260101-0043; Thu, 01 Jan 2026 11:59:58 +0000 Date: Thu, 01 Jan 2026 11:59:57 +0000 From: Alice To: Dave , Erin Subject: Quarterly report Message-ID: <20260101115957.4f2a@example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit --dsn-b1-- The fields of the "message/delivery-status" part are derived as described above: "Original-Envelope-Id" from the "envid" member, "Original-Recipient" from the "orcpt" member, "Status" and "Diagnostic-Code" from the SMTP reply, and "Remote-MTA" from the host name of the SMTP server. If the failure had been reported by an HMTP Receiving Server, "Status" would have been taken from the "smtpStatus" member of the problem details object, "Diagnostic-Code" would have been composed from its "smtpReply", "smtpStatus", and "detail" members, and "Remote-MTA" would have contained the TargetName of the HMTP Endpoint. The DSN is delivered to the Envelope Sender of the original Message like any other Message, with an empty Envelope Sender, so that no DSN is generated if the DSN itself cannot be delivered. When it is transferred using HMTP, the Request Object contains the following Envelope; because the Envelope Sender is empty, any Sending Domain is acceptable (Section 8.4): Tishkin Expires 9 April 2027 [Page 53] Internet-Draft HMTP October 2026 { "id": "nH8sK2dL5fQ9wE3rT6yU1i", "from": "", "to": [{"address": "alice@example.com"}] } 10. SMTP Fallback and Interoperability HMTP is a self-contained protocol. Support for SMTP is OPTIONAL and serves only the interoperability with domains that do not support HMTP. A Sending Server that does not support SMTP rejects Envelope Recipients whose domains do not support HMTP with the "routing- failed" problem type and a permanent enhanced status code. 10.1. When to Fall Back A Sending Server that supports SMTP MAY deliver a Message to an Envelope Recipient using SMTP only if both of the following conditions hold: 1. Discovery (Section 4) has determined that the domain of the Envelope Recipient does not support HMTP. 2. The Sending Server has no unexpired downgrade policy with the mode "enforce" for that domain (Section 10.2). A Sending Server MUST NOT fall back to SMTP after a temporary failure of discovery or of an HMTP request, such as a DNS timeout, a connection or TLS failure, or a response with a 5xx or 429 status code. It retries the delivery using HMTP as described in Section 6.4. A Sending Server MUST NOT fall back to SMTP after an HMTP request has been rejected permanently. When it falls back, the Sending Server delivers the Message as specified in [RFC5321], with the following requirements: * It locates the SMTP server using MX records as specified in Section 5.1 of [RFC5321]. If the domain publishes a null MX record [RFC7505], the Message cannot be delivered. * It retrieves all referenced content and reconstructs the Message before the transfer, because SMTP cannot carry Content References. Tishkin Expires 9 April 2027 [Page 54] Internet-Draft HMTP October 2026 * It transmits the Envelope using the parameters of the corresponding SMTP extensions: the BODY parameter for "body" [RFC6152] [RFC3030], the SMTPUTF8 parameter for "smtpUtf8" [RFC6531], the RET, ENVID, NOTIFY, and ORCPT parameters for the DSN parameters [RFC3461], and the REQUIRETLS parameter for "requireTls" [RFC8689]. Values are encoded as "xtext" where [RFC3461] requires it. * It MUST NOT convert the Message. If the SMTP server does not support an extension that the Message requires, such as 8BITMIME, BINARYMIME, or SMTPUTF8, the delivery to the affected Envelope Recipients fails with the "conversion-required" problem type. If "requireTls" is true and the requirements of [RFC8689] cannot be met, the delivery fails with the "tls-required" problem type. * If the SMTP server does not support the DSN extension, the Sending Server behaves as specified in [RFC3461] for relaying to a server that does not support it. * It SHOULD use STARTTLS [RFC3207] and SHOULD apply MTA-STS [RFC8461] or DANE [RFC7672] when the domain publishes them. 10.1.1. Example The Submission Server "hmtp.provider.example" of the domain "example.com", which also acts as its Sending Server, has accepted a Message from a Client with the following Envelope: { "id": "Xk4mP9qR2sT7vW1yZ3bC5d", "from": "alice@example.com", "to": [ { "address": "dave@example.org", "dsn": { "notify": ["failure", "delay"], "orcpt": "rfc822;dave@example.org" } }, {"address": "erin@example.org"} ], "dsn": {"ret": "hdrs", "envid": "QQ314159"}, "body": "8bitmime" } Tishkin Expires 9 April 2027 [Page 55] Internet-Draft HMTP October 2026 Discovery for "example.org" shows that the domain does not support HMTP, because the name "_hmtp.example.org" does not exist. The Sending Server has no recorded downgrade policy for "example.org", so it falls back to SMTP and looks up the MX records of the domain: ; _hmtp.example.org. IN SVCB -> NXDOMAIN example.org. 3600 IN MX 10 mx.example.org. The Sending Server then delivers the Message to "mx.example.org". In the following transcript, "C:" denotes lines sent by the Sending Server and "S:" lines sent by the SMTP server: Tishkin Expires 9 April 2027 [Page 56] Internet-Draft HMTP October 2026 NOTE: '\' line wrapping per RFC 8792 S: 220 mx.example.org ESMTP C: EHLO hmtp.provider.example S: 250-mx.example.org S: 250-8BITMIME S: 250-DSN S: 250-ENHANCEDSTATUSCODES S: 250 STARTTLS C: STARTTLS S: 220 2.0.0 Ready to start TLS (TLS handshake; the certificate of mx.example.org is validated) C: EHLO hmtp.provider.example S: 250-mx.example.org S: 250-8BITMIME S: 250-DSN S: 250 ENHANCEDSTATUSCODES C: MAIL FROM: BODY=8BITMIME RET=HDRS \ ENVID=QQ314159 S: 250 2.1.0 Sender OK C: RCPT TO: NOTIFY=FAILURE,DELAY \ ORCPT=rfc822;dave@example.org S: 550 5.1.1 : Recipient address rejected C: RCPT TO: S: 250 2.1.5 Recipient OK C: DATA S: 354 End data with . C: Received: from [198.51.100.7] ([198.51.100.7]) C: by hmtp.provider.example with HMTPA id S-20260101-0043; C: Thu, 01 Jan 2026 11:59:58 +0000 C: Date: Thu, 01 Jan 2026 11:59:57 +0000 C: From: Alice C: To: Dave , Erin C: Subject: Quarterly report C: Message-ID: <20260101115957.4f2a@example.com> C: MIME-Version: 1.0 C: Content-Type: text/plain; charset=utf-8 C: Content-Transfer-Encoding: 8bit C: C: (body of the Message) C: . S: 250 2.0.0 Ok: queued as 7HG2Lk C: QUIT S: 221 2.0.0 Bye The members of the Envelope are mapped to SMTP as follows: Tishkin Expires 9 April 2027 [Page 57] Internet-Draft HMTP October 2026 * "from" and the "address" members of the Recipient Objects become the arguments of the MAIL FROM and RCPT TO commands. * "body" with the value "8bitmime" becomes the parameter "BODY=8BITMIME". The SMTP server advertises 8BITMIME, so the Message can be transferred without conversion. If it did not, the Sending Server would fail the delivery to both recipients with the "conversion-required" problem type instead of converting the Message. * "ret" and "envid" become the parameters "RET=HDRS" and "ENVID=QQ314159", and the "dsn" member of the first Recipient Object becomes the parameters "NOTIFY=FAILURE,DELAY" and "ORCPT=rfc822;dave@example.org". The values contain no characters that require "xtext" encoding. The SMTP server advertises the DSN extension [RFC3461], so the parameters can be transmitted. * The Message is transmitted octet for octet as it was accepted from the Client, including the Received header field that the Submission Server prepended (Section 6.5). The SMTP server advertises ENHANCEDSTATUSCODES [RFC2034], so its replies contain enhanced status codes. The SMTP server accepts the Message for "erin@example.org". It rejects "dave@example.org" with a permanent failure. Because the Recipient Object of "dave@example.org" requests notification on failure, the Sending Server generates the DSN shown in Section 9.3.1. Had the SMTP server failed with a temporary error, the Sending Server would have retried later, repeating discovery before each retry, and would have used HMTP if "example.org" had started to publish an HMTP Endpoint in the meantime. 10.2. Downgrade Policy Without DNSSEC, an attacker who can modify DNS responses can remove the SVCB records of a domain and thereby cause Sending Servers to fall back to SMTP. A downgrade policy allows a domain to instruct Sending Servers that have once reached it over HMTP not to fall back to SMTP, in a way similar to HTTP Strict Transport Security [RFC6797] and MTA-STS [RFC8461]. The policy is expressed in the "policy" member of the Capabilities Document (Section 4.2), which is a JSON object with the following members: mode: REQUIRED. The string "enforce" or "none". maxAge: REQUIRED. The number of seconds for which a Sending Server Tishkin Expires 9 April 2027 [Page 58] Internet-Draft HMTP October 2026 applies the policy, as a non-negative integer. The value MUST NOT exceed 31557600 (one year). Sending Servers MUST treat larger values as 31557600. Whenever a Sending Server has located a host through discovery for a domain and has successfully retrieved the Capabilities Document of the host, it updates its policy state for that domain as follows: * If the document contains a policy with the mode "enforce", the Sending Server records that the policy applies to the domain until "maxAge" seconds after the time of retrieval. * If the document contains a policy with the mode "none", or no policy, the Sending Server removes any recorded policy for the domain. While an unexpired policy with the mode "enforce" is recorded for a domain, the Sending Server MUST treat a discovery result indicating that the domain does not support HMTP as a temporary failure and MUST NOT fall back to SMTP. It retries delivery as described in Section 6.4 and, when it gives up, generates a DSN. Because the Capabilities Document belongs to a host, its policy applies to all domains that use the host. A domain that intends to stop using HMTP first publishes, through its host, a policy with the mode "none" or a "maxAge" of 0, and keeps its SVCB records published for at least the previously advertised "maxAge" before removing them. A Sending Server that does not support SMTP fallback does not need to record policies. 10.3. SMTP to HMTP Gateways An SMTP server can relay Messages that it receives over SMTP to an HMTP Endpoint. Such a gateway acts as a Sending Server and constructs the Envelope from the SMTP transaction: * "from" and the "address" members of the Recipient Objects are taken from the MAIL FROM and RCPT TO commands; * "body", "smtpUtf8", and "requireTls" are taken from the BODY, SMTPUTF8, and REQUIRETLS parameters; * the DSN parameters are taken from the RET, ENVID, NOTIFY, and ORCPT parameters, after decoding "xtext". Tishkin Expires 9 April 2027 [Page 59] Internet-Draft HMTP October 2026 The Message is the message received over SMTP, including the Received header field that the gateway prepends as an SMTP server. A gateway SHOULD record the results of the authentication checks it performed on the SMTP transaction, such as SPF, DKIM, and DMARC, in an Authentication-Results header field [RFC8601]. A gateway signs its requests with a key of its own domain. For outbound Messages of the domain that operates the gateway, the Envelope Sender is aligned as usual. A gateway that relays Messages from other domains, such as an inbound filtering service or a backup server, cannot produce aligned signatures for them. It is used under a local agreement with the Receiving Server, as described in Section 8.4. A gateway MAY relay the Message over HMTP before it replies to the SMTP DATA or BDAT command. In that case, it translates the result of the HMTP request into the SMTP reply, using the "smtpReply" and "smtpStatus" members of the problem details object, and the mapping in Table 1. Otherwise, it accepts the Message, relays it later, and reports failures through DSNs. 11. Deployment and Transition Considerations HMTP is designed to be deployed alongside SMTP, without a flag day. The following considerations apply: Receiving mail: A domain enables inbound HMTP by publishing an SVCB record and serving a Capabilities Document, while keeping its MX records. Because the TLS certificate is validated against the TargetName, a provider that hosts many domains needs a certificate only for its own host name, not for each customer domain. Sending mail: A domain enables outbound HMTP by publishing a key record for HMTP, preferably under a dedicated selector with the service type "hmtp", and by enabling discovery in its Sending Servers. Sending Servers that support SMTP fall back to it for domains that do not yet support HMTP. Downgrade policy: A domain SHOULD start with a short "maxAge", or without a policy, and increase it once it is confident that its HMTP Endpoint is reliable, because a policy with the mode "enforce" prevents delivery over SMTP for its duration. Reputation: Receiving Servers base reputation on the Sending Domain instead of IP addresses. New Sending Domains still need to establish reputation, and Receiving Servers MAY apply rate limits to Sending Domains without history. Tishkin Expires 9 April 2027 [Page 60] Internet-Draft HMTP October 2026 Infrastructure: HMTP uses standard HTTP infrastructure, including load balancers, reverse proxies, and HTTP libraries. Operators need to ensure that intermediaries preserve the components covered by signatures (Section 8.3) and accept request sizes up to the advertised "maxRequestSize". Large content is best transferred by reference, so that it can be served from storage optimized for that purpose. Clients: Clients locate their Submission Server through discovery or configuration. Existing SMTP AUTH credentials can be used with the "basic" scheme, and Clients can migrate to OAuth 2.0 bearer tokens over time. Operating both protocols: A server that supports both protocols can use a single queue, because the Message is the same in both protocols and only the Envelope representation differs. 12. Implementation Status No implementations are known at the time of writing. 13. Security Considerations 13.1. Transport Security All HMTP requests, including the retrieval of the Capabilities Document and of referenced content, use TLS with certificate validation. No plaintext mode exists. TLS protects the confidentiality and integrity of each hop, but not of the Message end to end: every server that handles a Message has access to its content, as in SMTP. End-to-end protection requires OpenPGP or S/ MIME. 13.2. DNS and Downgrade Attacks The TLS certificate of the HMTP Endpoint is validated against the TargetName obtained from DNS. If DNS responses are not authenticated, an attacker who can modify them can redirect HMTP requests to a host under its control, for which it can obtain a valid certificate, or can remove the SVCB records so that a Sending Server falls back to SMTP. This is the same exposure that MX records have without DNSSEC. Domains SHOULD sign their zones with DNSSEC, and Sending Servers SHOULD validate DNS responses. Tishkin Expires 9 April 2027 [Page 61] Internet-Draft HMTP October 2026 The downgrade policy (Section 10.2) protects against the removal of SVCB records after a Sending Server has reached a domain once, but not on first contact and not against redirection to another host. The rule that temporary failures never cause a fallback to SMTP (Section 10.1) prevents an attacker from forcing a downgrade by blocking HTTPS connections. 13.3. Signatures and Replay Signatures cover the method, the target URI, the media type, and the digest of the content, and are therefore bound to the Envelope, the Message, and the Receiving Server. A captured request cannot be replayed to another Receiving Server, because the target URI differs. A replay to the same Receiving Server is limited by the validity period of the signature, which is at most 300 seconds, and within that period by the Transfer Identifier, which causes the Receiving Server to return the stored response instead of delivering the Message again. Verifiers need reasonably accurate clocks. 13.4. Key Management The security of HMTP depends on the protection of the private keys of the Sending Domain. A compromised key allows an attacker to send requests on behalf of the domain until the key record is revoked. Domains SHOULD rotate keys regularly as described in Section 8.1. When a key is shared between DKIM message signing and HMTP request signing, a compromise affects both uses. The data that HMTP signs, the signature base defined by [RFC9421], has a different structure from the data signed by DKIM, which makes it difficult to use a signature from one protocol in the other. Nevertheless, keys dedicated to HMTP with the service type "hmtp" are RECOMMENDED. RSA keys shorter than 2048 bits, which [RFC8301] still permits for DKIM, are not permitted for HMTP. 13.5. Sender Alignment Alignment permits a domain to sign for its subdomains. A Receiving Server SHOULD NOT accept signatures of domains that are registry suffixes, such as top-level domains, as authenticating the Envelope Sender, because such domains do not operate mail services for the domains registered under them. An HMTP signature authenticates the Sending Domain and its alignment with the Envelope Sender. It does not authenticate the author of the Message. Receiving Servers MUST NOT present the Sending Domain to users as the author of the Message. Tishkin Expires 9 April 2027 [Page 62] Internet-Draft HMTP October 2026 13.6. Content References Retrieving referenced content causes the Receiving Server to send requests to URIs chosen by the sender. A Receiving Server MUST NOT retrieve content from IP addresses that are not globally routable, such as loopback, private, and link-local addresses, unless it is explicitly configured to do so, in order to prevent attacks on internal services. It SHOULD apply limits to the number of redirections, the duration of retrievals, and the number of concurrent retrievals per Sending Domain. The integrity of referenced content is protected by its digest, which is covered by the signature of the request. The size of referenced content is declared in advance, so a Receiving Server can reject oversized Messages before retrieving them and can stop a retrieval that exceeds the declared size. URIs of referenced content act as bearer capabilities: anyone who learns them can retrieve the content until it is removed. Senders SHOULD use URIs that contain sufficient randomness to be unguessable, SHOULD remove content after its "expires" timestamp, and MAY require signed retrieval requests (Section 8.2.1). Receiving Servers MUST NOT disclose these URIs to recipients of the Message. 13.7. Denial of Service HMTP servers are exposed to resource exhaustion through large requests, many concurrent requests, slow transmission of requests, and Messages with many segments or recipients. Servers SHOULD advertise and enforce limits (Section 4.2), SHOULD apply rate limits per Sending Domain and per IP address, and MAY verify the signature before receiving the content of the request. Because the identity of the sender is established by the signature, rate limits and blocking can be applied per Sending Domain rather than per IP address. 13.8. Client Authentication Credentials used with the "basic" scheme are passwords and are subject to guessing and phishing. Servers SHOULD support bearer tokens, SHOULD support application-specific passwords for the "basic" scheme, and SHOULD limit the rate of failed attempts. Bearer tokens SHOULD be restricted to the Submission Server as their audience, and Clients MUST NOT send them to other servers. Tishkin Expires 9 April 2027 [Page 63] Internet-Draft HMTP October 2026 A Submission Server MUST authenticate every submission request and MUST verify the sender addresses (Section 7.2). A transfer endpoint MUST NOT accept Messages for domains it does not serve, except under a local relay agreement. Otherwise, the server would act as an open relay. 13.9. Transfer Identifiers Transfer Identifiers are scoped to the Sending Domain or to the authenticated account, so a third party cannot cause a legitimate request to be suppressed as a duplicate without being able to sign requests for the same scope. The limit on the length of Transfer Identifiers bounds the storage that a Receiving Server needs for them. 14. Privacy Considerations HMTP exposes the same information to the servers that handle a Message as SMTP does: the Envelope, the Message, and the IP addresses of the communicating servers. TLS protects this information from observers on the network. The name of the HMTP Endpoint is visible in the TLS handshake unless Encrypted Client Hello is used, and DNS queries for SVCB records reveal the domains with which a server exchanges mail unless encrypted DNS transports are used. An HMTP request contains all Envelope Recipients that are served by the same HMTP Endpoint. As in SMTP, the Receiving Server learns all of them, including recipients that are not visible in the header fields of the Message, such as blind carbon copy recipients. Receiving Servers MUST NOT disclose the list of Envelope Recipients to recipients of the Message, and include the "for" clause in Received header fields only for single recipients (Section 6.5). The retrieval of referenced content reveals to the server that hosts the content which Receiving Servers retrieve it and when. Because retrieval is performed by the Receiving Server and is not triggered by actions of the recipient (Section 5.2.1), it does not reveal whether or when the recipient reads the Message. Senders can still learn which Receiving Servers serve the recipients, which they can also learn from DNS. The identities endpoint reveals the addresses of an account only to the authenticated Client. The Capabilities Document is public and reveals the endpoints and limits of the host, and implicitly the provider that serves a domain, which can also be learned from DNS. Tishkin Expires 9 April 2027 [Page 64] Internet-Draft HMTP October 2026 Receiving Servers store Transfer Identifiers together with a hash of the request content and the response. This information SHOULD NOT be retained longer than needed for the purposes described in Section 6.4. Submission Servers MAY replace the IP address of the Client in the Received header field with a placeholder (Section 6.5) to protect the privacy of the user. 15. IANA Considerations 15.1. Underscored and Globally Scoped DNS Node Name IANA is requested to add the following entry to the "Underscored and Globally Scoped DNS Node Names" registry [RFC8552]: +=========+============+===========+ | RR Type | _NODE NAME | Reference | +=========+============+===========+ | SVCB | _hmtp | RFC XXXX | +---------+------------+-----------+ Table 2 15.2. Well-Known URI IANA is requested to add the following entry to the "Well-Known URIs" registry [RFC8615]: URI Suffix: hmtp Change Controller: IETF Specification Document(s): Section 4.2 of RFC XXXX Status: permanent Related Information: None 15.3. DKIM Service Type IANA is requested to add the following entry to the "DKIM Service Types" registry [RFC6376]: Tishkin Expires 9 April 2027 [Page 65] Internet-Draft HMTP October 2026 +======+===========+========+ | Type | Reference | Status | +======+===========+========+ | hmtp | RFC XXXX | active | +------+-----------+--------+ Table 3 15.4. Mail Transmission Types IANA is requested to add the following entries to the "Mail Transmission Types" registry in the "Mail Parameters" registry group: +===============+=======================================+===========+ | WITH protocol | Description | Reference | | type | | | +===============+=======================================+===========+ | HMTP | HTTP Mail Transfer | RFC XXXX | | | Protocol, transfer | | +---------------+---------------------------------------+-----------+ | HMTPA | HTTP Mail Transfer | RFC XXXX | | | Protocol, submission with | | | | client authentication | | +---------------+---------------------------------------+-----------+ Table 4 15.5. URN Sub-namespace IANA is requested to register the following entry in the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" registry [RFC3553]: Registry name: hmtp Specification: RFC XXXX Repository: The "HTTP Mail Transfer Protocol (HMTP)" registry group defined in this document. URNs of the form urn:ietf:params:hmtp:error: identify problem types registered in the "HMTP Problem Types" registry. Index value: The name of a problem type, as registered in the "HMTP Problem Types" registry. Tishkin Expires 9 April 2027 [Page 66] Internet-Draft HMTP October 2026 15.6. HMTP Registry Group IANA is requested to create a new registry group titled "HTTP Mail Transfer Protocol (HMTP)" containing the registries defined in the following subsections. For all of them, the registration policy is Specification Required [RFC8126]. The designated experts verify that the specification is publicly available, that the registered name does not conflict with an existing entry, and that the specification is consistent with the extension rules of Section 5.4. 15.6.1. HMTP Capabilities The registry contains capabilities with registered names. Capabilities identified by URIs are not registered (see Section 5.4.1). The registry records the following fields for each capability: * Name: the registered name of the capability, with the syntax defined in Section 5.4.1. * Description: a brief description. * Must-Understand: "yes" or "no", as defined in Section 5.4. * Reference: the specification of the capability. * Change Controller: the party responsible for the capability. The registry is initially empty. 15.6.2. HMTP Endpoints The registry records the following fields for each endpoint name used in the "endpoints" member of a Version Object: * Name: the member name. * Description: a brief description. * Reference: the specification of the endpoint and of the members of its Endpoint Object. The initial contents are: Tishkin Expires 9 April 2027 [Page 67] Internet-Draft HMTP October 2026 +============+============================+===============+ | Name | Description | Reference | +============+============================+===============+ | transfer | Transfer of Messages | Section 6 and | | | between servers | Section 4.2.1 | | | | of RFC XXXX | +------------+----------------------------+---------------+ | submission | Submission of Messages by | Section 7 and | | | Clients, and identities of | Section 4.2.1 | | | an authenticated Client | of RFC XXXX | +------------+----------------------------+---------------+ Table 5 15.6.3. HMTP Content Encodings The registry records the following fields for each encoding used in the "encoding" member of a Content Reference: * Name: the name of the encoding. * Description: a brief description of the transformation. * Reference: the specification of the encoding. The initial contents are: +========+==============================+=============+ | Name | Description | Reference | +========+==============================+=============+ | base64 | Base64 with lines of 76 | Section 5.3 | | | characters separated by CRLF | of RFC XXXX | +--------+------------------------------+-------------+ Table 6 15.6.4. HMTP Problem Types The registry records the following fields for each problem type: * Name: the name of the problem type, used in the URN urn:ietf:params:hmtp:error:. * Scope: "Request", "Recipient", or "Both". * HTTP Status: the HTTP status code used for request-level failures. * Enhanced Status: the enhanced status code or codes. Tishkin Expires 9 April 2027 [Page 68] Internet-Draft HMTP October 2026 * SMTP Reply: the SMTP reply code or codes. * Reference: the specification of the problem type. The initial contents are the problem types listed in Table 1, each with the reference Section 9.2 of RFC XXXX. 16. References 16.1. Normative References [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, DOI 10.17487/RFC3030, December 2000, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, DOI 10.17487/RFC3461, January 2003, . [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, DOI 10.17487/RFC3463, January 2003, . [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, DOI 10.17487/RFC3464, January 2003, . [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, . Tishkin Expires 9 April 2027 [Page 69] Internet-Draft HMTP October 2026 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, Ed., "SMTP Service Extension for 8-bit MIME Transport", STD 71, RFC 6152, DOI 10.17487/RFC6152, March 2011, . [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, . [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, . [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, . Tishkin Expires 9 April 2027 [Page 70] Internet-Draft HMTP October 2026 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 2012, . [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, . [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, . [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8463] Levine, J., "A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM)", RFC 8463, DOI 10.17487/RFC8463, September 2018, . [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, . Tishkin Expires 9 April 2027 [Page 71] Internet-Draft HMTP October 2026 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [RFC8689] Fenton, J., "SMTP Require TLS Option", RFC 8689, DOI 10.17487/RFC8689, November 2019, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, . [RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, June 2022, . [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . [RFC9457] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023, . [RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, . [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023, . [RFC9530] Polli, R. and L. Pardue, "Digest Fields", RFC 9530, DOI 10.17487/RFC9530, February 2024, . [RFC9728] Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, . Tishkin Expires 9 April 2027 [Page 72] Internet-Draft HMTP October 2026 16.2. Informative References [RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, DOI 10.17487/RFC2034, October 1996, . [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, . [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, . [RFC4865] White, G. and G. Vaudreuil, "SMTP Submission Service Extension for Future Message Release", RFC 4865, DOI 10.17487/RFC4865, May 2007, . [RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service Extension for Authentication", RFC 4954, DOI 10.17487/RFC4954, July 2007, . [RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages", STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012, . [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict Transport Security (HSTS)", RFC 6797, DOI 10.17487/RFC6797, November 2012, . [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, . [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, . Tishkin Expires 9 April 2027 [Page 73] Internet-Draft HMTP October 2026 [RFC7505] Levine, J. and M. Delany, "A "Null MX" No Service Resource Record for Domains That Accept No Mail", RFC 7505, DOI 10.17487/RFC7505, June 2015, . [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)", RFC 7672, DOI 10.17487/RFC7672, October 2015, . [RFC8098] Hansen, T., Ed. and A. Melnikov, Ed., "Message Disposition Notification", STD 85, RFC 8098, DOI 10.17487/RFC8098, February 2017, . [RFC8301] Kitterman, S., "Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM)", RFC 8301, DOI 10.17487/RFC8301, January 2018, . [RFC8461] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., and J. Jones, "SMTP MTA Strict Transport Security (MTA- STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018, . [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, . [RFC8601] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 8601, DOI 10.17487/RFC8601, May 2019, . [RFC8620] Jenkins, N. and C. Newman, "The JSON Meta Application Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July 2019, . [RFC8621] Jenkins, N. and C. Newman, "The JSON Meta Application Protocol (JMAP) for Mail", RFC 8621, DOI 10.17487/RFC8621, August 2019, . [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, . Tishkin Expires 9 April 2027 [Page 74] Internet-Draft HMTP October 2026 [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message Access Protocol (IMAP) - Version 4rev2", RFC 9051, DOI 10.17487/RFC9051, August 2021, . [RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, . [RFC9580] Wouters, P., Ed., Huigens, D., Winter, J., and Y. Niibe, "OpenPGP", RFC 9580, DOI 10.17487/RFC9580, July 2024, . Appendix A. Examples This appendix contains complete examples of HMTP exchanges. As noted in Section 2, base64 data, digests, and signature values are abbreviated or illustrative. A.1. Discovery A Sending Server that has a Message for "bob@example.net" queries DNS and retrieves the Capabilities Document of the target host: _hmtp.example.net. 3600 IN SVCB 1 mx.example.net. alpn=h2,h3 Tishkin Expires 9 April 2027 [Page 75] Internet-Draft HMTP October 2026 GET /.well-known/hmtp HTTP/1.1 Host: mx.example.net HTTP/1.1 200 OK Content-Type: application/json Cache-Control: max-age=86400 { "versions": { "1": { "endpoints": { "transfer": { "uri": "/hmtp/v1/transfer" } } } }, "limits": { "maxMessageSize": 10737418240, "maxRequestSize": 26214400, "maxRecipients": 500 }, "policy": { "mode": "enforce", "maxAge": 2592000 } } A.2. Transfer with Referenced Content The Sending Server transfers a Message with a large attachment by reference. The Receiving Server accepts the Message and retrieves the attachment after responding, which it indicates with the status code 202 (Accepted). The Sending Server keeps the attachment available until its "expires" timestamp: Tishkin Expires 9 April 2027 [Page 76] Internet-Draft HMTP October 2026 NOTE: '\' line wrapping per RFC 8792 POST /hmtp/v1/transfer HTTP/1.1 Host: mx.example.net Content-Type: application/json Content-Digest: sha-256=:q1M8rT4vYw7Zb2Nd5Kf0Hs9Lx3Jc6Pg1Ue8Ra4Wi2Oo=: Signature-Input: hmtp=("@method" "@target-uri" "content-type" \ "content-digest");created=1767268800;expires=1767269100;\ keyid="hmtp2026._domainkey.example.com";alg="ed25519";tag="hmtp" Signature: hmtp=:Zm9vYmFyZXhhbXBsZXNpZ25hdHVyZXZhbHVlbm90cmVh\ bGx5dmFsaWRqdXN0aWxsdXN0cmF0aXZlb25seWZvcg==: { "envelope": { "id": "Hq9vR2xLm4Tz8Kc1Wb6Nd0", "from": "alice@example.com", "to": [{"address": "bob@example.net"}], "body": "7bit" }, "message": { "segments": [ {"data": "RnJvbTogQWxpY2UgPGFsaWNlQGV4YW1wbGUuY29tPg0K..."}, { "uri": "https://files.example.com/f/9b1c4e7a", "size": 734003200, "digest": { "sha-256": "Yk3qV0sJpRm9T2cFhWxN6dL1bA8eQu7ZgKi4oPyXwE0=" }, "expires": "2026-01-08T12:00:00Z", "encoding": "base64" }, {"data": "DQotLWIxLS0NCg=="} ], "size": 1004426786 } } HTTP/1.1 202 Accepted Content-Type: application/json { "queueId": "8Jk2Pq7Xv1", "recipients": [ {"address": "bob@example.net", "result": "accepted"} ] } Tishkin Expires 9 April 2027 [Page 77] Internet-Draft HMTP October 2026 A.3. Submission A Client submits a Message with Basic authentication. The Submission Server accepts responsibility for both recipients and reports the outcome of the final delivery through DSNs: POST /hmtp/v1/submission HTTP/1.1 Host: hmtp.provider.example Authorization: Basic YWxpY2U6czNjcjN0LWFwcC1wYXNzd29yZA== Content-Type: application/json { "envelope": { "id": "c5N1qW8eR3tY6uI9oP2aS4", "from": "alice@example.com", "to": [ {"address": "bob@example.net"}, {"address": "dave@example.org"} ] }, "message": { "data": "RnJvbTogQWxpY2UgPGFsaWNlQGV4YW1wbGUuY29tPg0K..." } } HTTP/1.1 200 OK Content-Type: application/json { "queueId": "S-20260101-0042", "recipients": [ {"address": "bob@example.net", "result": "accepted"}, {"address": "dave@example.org", "result": "accepted"} ] } A.4. Retried Request The connection is lost before the Sending Server receives the response to the request in Section 6.1. The Sending Server sends the identical request again with a new signature. The Receiving Server recognizes the Transfer Identifier and returns the stored response without delivering the Message again: Tishkin Expires 9 April 2027 [Page 78] Internet-Draft HMTP October 2026 HTTP/1.1 200 OK Content-Type: application/json { "queueId": "4Y7mKq2ZtR", "recipients": [ {"address": "bob@example.net", "result": "accepted"}, { "address": "carol@example.net", "result": "rejected", "problem": { "type": "urn:ietf:params:hmtp:error:unknown-recipient", "title": "Unknown recipient", "smtpStatus": "5.1.1", "smtpReply": 550 } } ] } Author's Address Dmitrii Tishkin Independent Email: hello@dmi03.com Tishkin Expires 9 April 2027 [Page 79]