HTTP Mail Transfer Protocol

HTTP Mail Transfer Protocol Independent

hello@dmi03.com

ART email mail submission HTTP REST This document specifies the HTTP Mail Transfer Protocol (HMTP), a protocol for the submission and transfer of Internet mail over HTTPS. HMTP retains what SMTP and the mail system built around it have proven, namely the Internet Message Format, the separation of envelope and message, and the semantics of delivery and delivery status notifications, and adds what SMTP provides only through optional extensions or not at all. Security is built in: transport encryption is mandatory, and every transfer request is signed on behalf of the sending domain, using keys published with the DomainKeys Identified Mail (DKIM) key publication mechanism. Requests carry identifiers that make retries safe, failures are reported per recipient as structured problem details with a mapping to SMTP status codes, and extensions are declared explicitly as capabilities. Messages are carried unmodified inside a JSON envelope, and large messages and attachments can be transferred by reference, with their integrity protected by cryptographic hashes. Servers discover HMTP endpoints through DNS and a well-known URI, and a domain can publish a policy that prevents downgrade to SMTP. HMTP does not depend on SMTP, but an implementation can optionally fall back to SMTP when a peer does not support HMTP, so that it can be deployed incrementally alongside existing systems. About This Document Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction The Simple Mail Transfer Protocol (SMTP) has carried Internet mail for several decades and remains the only widely deployed protocol for transferring messages between mail servers. Message submission by clients 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 , sender authorization with SPF , message signing with DKIM , policy alignment with DMARC , and downgrade protection with MTA-STS and DANE . Each of these mechanisms is useful, but together they form a complex system that is difficult to deploy and operate correctly. This document takes a different approach. Instead of adding another mechanism on top of SMTP, it defines a new protocol that keeps what has proven itself in Internet mail and builds the rest on HTTPS. The message format, the separation of envelope and message, and the semantics of delivery and delivery status notifications are taken from SMTP, so that HMTP and SMTP can coexist and a message can pass through both. Security is part of the base protocol rather than a set of optional extensions: transport encryption is mandatory, and every request is authenticated. In addition, HMTP provides functionality that SMTP lacks, such as request identifiers that make retries safe, explicitly declared extensions, structured per-recipient errors, and the transfer of large content by reference.

Problem Statement This document is motivated by the following properties of SMTP-based mail transfer:

Optional transport security:: STARTTLS is negotiated in plaintext and 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 and enhanced status codes , 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.
No standard HTTP interface:: Applications increasingly submit mail through HTTP APIs offered by individual products and services. These APIs are proprietary and mutually incompatible, and none of them can be used to transfer mail between independent domains.

Overview of HMTP HMTP uses HTTP over TLS as its transport and a JSON 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 with MIME 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 or S/MIME therefore remain valid.
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 together with Digest Fields , with keys published in DNS in the same way as DKIM keys.
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, either before it responds or after it has accepted the message, 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 record identifies the HMTP endpoint of a domain, and a well-known URI describes the capabilities of the server.
Errors are structured. Failures are reported using Problem Details for HTTP APIs , with a defined mapping to SMTP enhanced status codes. The result is reported separately for each recipient. Delivery status notifications can optionally be sent as JSON reports to the domain of the sender instead of as DSN messages.
The protocol is extensible. Servers advertise optional extensions, called capabilities, in the Capabilities Document, and requests indicate the capabilities they use, so that new functionality can be added without changing the base protocol.
HMTP coexists with SMTP. HMTP is a complete protocol on its own and does not depend on SMTP, but the two can be combined freely: the protocol is chosen separately for each hop, so a server can receive a message with one protocol and forward it with the other. An implementation can also deliver messages using SMTP when a receiving domain does not publish an HMTP endpoint. Because the message is carried unmodified, no conversion is needed, 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. Both use the same data model. Clients authenticate to their submission server using HTTP authentication. Basic authentication provides compatibility with existing SMTP AUTH credentials, and bearer tokens obtained through OAuth 2.0 are supported for deployments that require stronger authentication.

Relationship to SMTP HMTP is not an extension or a revision of SMTP and does not update . It is also more than a new transport for the SMTP mail model. HMTP takes from SMTP the parts on which the rest of the mail system depends and redesigns the protocol around them, with security and extensibility built in. lists the main SMTP concepts and their HMTP counterparts. SMTP Concepts and Their Counterparts in HMTP

SMTP	HMTP
MX records	SVCB record at `_hmtp.<domain>`
EHLO and extension keywords	Capabilities Document and capabilities
STARTTLS, optional	HTTPS, mandatory
Ports 25 and 587	Port 443 by default
SMTP AUTH	HTTP authentication
MAIL FROM	Envelope member "from"
RCPT TO	Envelope member "to"
BODY, SMTPUTF8, REQUIRETLS	"body", "smtpUtf8", "requireTls"
DSN parameters	Envelope member "dsn"
DATA and BDAT	"message", inline or by reference
SIZE	Limit "maxMessageSize"
PIPELINING	Concurrent requests over HTTP/2 or HTTP/3
Reply and enhanced status codes	Problem details, "smtpStatus"
Successful reply to DATA	Result "accepted" for a recipient
Received field "with ESMTP"	Received field "with HMTP"
DSN messages	DSN messages or delivery status reports

The counterparts are specified in , , , , , , , , , , and . The following parts of the mail system are the same for both protocols: the Internet Message Format, DKIM and DMARC evaluation of the message, the meaning of accepting responsibility for a message, delivery status notifications, and enhanced status codes. This is what allows a message to travel over a path that combines HMTP and SMTP hops without conversion (). In addition, HMTP provides the following, which SMTP offers only through optional extensions or not at all:

Security by default. TLS with certificate validation is mandatory, every transfer request is authenticated by the Sending Domain, and a domain can prevent downgrade to SMTP. In SMTP, the corresponding functions are provided by STARTTLS, SPF, DKIM, DMARC, MTA-STS, and DANE, each of which is deployed separately.
Request identifiers. A Transfer Identifier in every request prevents duplicate delivery when the request is retried ().
Declared extensions. Capabilities are advertised with their parameters in the Capabilities Document, are listed in the requests that depend on them, and are either registered with IANA or named by URIs ().
Structured errors. Each failure is reported per recipient as a problem details object with a registered type ().
Content by reference. Large messages and attachments do not have to be carried in every request ().

HMTP does not provide the line-oriented, interactive dialogue of SMTP; each request carries a complete transaction.

Relationship to Other Work The JSON Meta Application Protocol (JMAP) 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. Some mail transfer agents provide HTTP APIs for injecting messages. For example, the Halon MTA accepts a multipart HTTP request that carries a JSON object with the envelope sender and recipients together with the message in Internet Message Format, authenticated with an API key . Sending services such as Amazon Simple Email Service and Oracle Cloud Infrastructure Email Delivery likewise offer proprietary HTTP APIs for submitting messages. Each of these APIs is specific to one product or service and covers only submission to it, while delivery to other domains continues to use SMTP. Because each service defines its own API, an application that integrates with one of them cannot switch to another without being modified. HMTP follows a similar model, an envelope that accompanies an unmodified message, and standardizes it for both submission and transfer between independent domains, together with discovery, domain-based authentication, and a common error model. 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.

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 and JMAP.
End-to-end encryption of messages, which continues to be provided by existing mechanisms such as OpenPGP and S/MIME.

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 when, and only when, they appear in all capitals, as shown here. This document uses the terminology of the Internet Mail Architecture . The terms "JSON object", "member", and "array" are used as defined in . The terms "signature", "signer", "verifier", "covered components", and "signature parameters" are used as defined in . The Content-Digest header field is defined in . The following terms are defined for use in this document:

Message:: An Internet message in the format defined by , including any MIME structure. HMTP transfers the Message without modification, except for the prepending of trace header fields described in and the changes permitted at submission in .
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 .
Envelope Sender:: The address to which delivery status notifications are sent, carried in the Envelope. It corresponds to the SMTP "MAIL FROM" address . 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 .
Sending Domain:: The domain on whose behalf an HMTP transfer request is signed, as given in the "domain" parameter of the signature and established by verifying the signature (see ).
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 .
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 .
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 ).
Capabilities Document:: The JSON document that describes the HMTP Endpoints, limits, policy, and extensions of a host (see ).
Content Object:: A JSON object that carries content, such as a Message, either inline, by reference, or as a sequence of segments (see ).
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 ).

A single server MAY act in more than one of these roles. In examples, long lines are wrapped as described in . 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.

Architecture HMTP is an application protocol that uses HTTP over TLS as its transport. All HMTP requests are HTTP requests sent to an HMTP Endpoint.

Roles

Submission:: A Client sends a Message to its Submission Server. The Client authenticates to the Submission Server as described in .
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 .

Both interactions use the same Data Model (). A Submission Server typically also acts as a Sending Server for the Messages it accepts.

Message Flow shows the path of a Message from a Client to a recipient.

Message Flow | Submission | -----------> | Receiving | | (MUA) | (HMTP) | Server | (HMTP) | Server | +--------+ +------------+ +-----------+ | | | fallback v | (SMTP, optional) +-----------+ v | Recipient | +------------+ | Mailbox | | SMTP | +-----------+ | Server | +------------+ ]]>

The Client constructs a Message and an Envelope and submits them to its Submission Server.
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.
For each recipient domain, the Sending Server performs discovery (). 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 .
The Receiving Server verifies the signature of the request, applies its local policy, and accepts or rejects the Message for each Envelope Recipient.
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 ).
The Receiving Server prepends a trace header field to the Message and delivers the Message to the recipient mailbox or relays it further.

Coexistence with SMTP HMTP is designed to coexist with SMTP permanently, not only during a transition period. HMTP does not change the use of MX records 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. The protocol is chosen separately for each hop. A server that supports both protocols decides how to forward a Message independently of the protocol over which it received the Message, so that all four combinations shown in are possible:

Combinations of Incoming and Outgoing Hops +------------------------+ --- HMTP ---> (2) --- HMTP ---> | Server that supports | --- SMTP ---> (3) --- SMTP ---> | both HMTP and SMTP | --- HMTP ---> (4) --- SMTP ---> | | --- SMTP ---> +------------------------+ ]]>

HMTP to HMTP:: A server relays a Message that it received over HMTP to another HMTP Endpoint, for example a Submission Server that delivers to a domain that publishes an HMTP Endpoint.
HMTP to SMTP:: A server accepts a Message over HMTP and forwards it over SMTP. Examples are a Submission Server that sends all outbound Messages through an SMTP relay of its operator, a Receiving Server that passes accepted Messages to an existing SMTP-based mail system of the recipient domain, and a Sending Server that falls back to SMTP for a domain that does not support HMTP ().
SMTP to HMTP:: A server accepts a Message over SMTP and forwards it over HMTP. Examples are an existing MX server that relays Messages to an HMTP-based mailbox service of the same domain, and an SMTP server that delivers outbound Messages to domains that publish an HMTP Endpoint, as described in .
SMTP to SMTP:: The operation of SMTP is not affected by HMTP.

In every combination, the Message is forwarded unchanged, except for the trace header fields that each server prepends (), and the Envelope information is carried over between the parameters of SMTP commands and the members of the Envelope as described in and . DKIM signatures and end-to-end protection of the Message therefore remain valid on any path. How the protocol for an outgoing hop is chosen depends on how the next hop is determined:

If the next hop is determined by discovery for the domain of an Envelope Recipient, HMTP is used if the domain supports it. SMTP is used only under the conditions of , which include the downgrade policy of the domain.
If the next hop is determined by local configuration, for example a relay of the operator of the server, the internal mail system of the recipient domain, or a filtering or backup service under an agreement with the recipient domain, the server uses the protocol configured for that next hop. This is not a fallback in the sense of . The rules of apply to the server that eventually delivers the Message to the recipient domain.

As a result, a domain can, for example, receive mail over HMTP while its outbound mail continues to use SMTP, or send mail over HMTP while it continues to receive mail over SMTP, without any dependency between the two directions. 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.

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 () and then retrieves the Capabilities Document from the target host ().

DNS Record A domain that supports HMTP publishes one or more SVCB resource records at the following owner name: ]]> where <domain> is the domain part of an email address, in the form of A-labels for internationalized domain names. The "_hmtp" label is a globally scoped underscored node name . It does not indicate a transport protocol, which is determined by the "alpn" SvcParam. Addresses whose domain part is an address literal have no associated DNS name; HMTP is not used for such addresses. The records are interpreted according to with the following rules:

AliasMode records are processed as specified in . An AliasMode record whose TargetName is "." indicates that the domain does not provide HMTP ().
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 and MAY support HTTP/3 . 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 and in the documents that define them. A record that lists an unsupported key in the "mandatory" SvcParam is unusable, as specified in .
If multiple ServiceMode records are present, the host to connect to is selected as described in .

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 . DNS responses SHOULD be validated using DNSSEC when available. See 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 .
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.

Selection of the Target Host A domain can publish several ServiceMode records, for example to provide redundant hosts or a backup host. The server or Client selects among them in the same way as an SMTP client selects among MX records ():

It discards the records that are unusable as described in .
It orders the remaining records by their SvcPriority, from the lowest value to the highest. A lower value indicates a more preferred host.
It orders records with the same SvcPriority randomly, so that each of them is equally likely to be tried first, as recommended in . SVCB records have no weight, so the load is distributed evenly among hosts of equal priority.
It tries the hosts in the resulting order. A host with a higher SvcPriority value is tried only after all hosts with lower values have failed.
If the attempt fails at every host, the delivery attempt has failed temporarily. The server retries later as described in , starting again with step 1, so that a new random order is used. A retry of a request whose outcome is unknown is an exception to this rule, as described below.

If the TargetName of a host resolves to several IP addresses, the server or Client tries these addresses before it proceeds to the next host, for example using the Happy Eyeballs algorithm . The server or Client proceeds to the next host if the attempt at the current host fails in one of the following ways:

The TargetName cannot be resolved, or no connection can be established to any of its addresses.
The TLS handshake fails, including a failure to validate the certificate of the host.
The Capabilities Document cannot be retrieved because of a temporary failure, or the host is not usable according to .
The connection fails before the request has been sent completely, or the host indicates that it has not processed the request, for example in HTTP/2 by resetting the stream with the error code REFUSED_STREAM or by sending a GOAWAY frame whose last stream identifier is lower than that of the request ().
The response has the status code 500, 502, or 503 and does not contain a problem details object with an "smtpStatus" member. Such a response is typically generated by an intermediary, such as a load balancer, that could not pass the request to an HMTP server.

Otherwise, the attempt ends, and the server or Client does not try further hosts:

A response with the status code 200 (OK) or 202 (Accepted) completes the attempt. Envelope Recipients with the result "deferred" are retried later as described in .
A response that contains a problem details object with an "smtpStatus" member has been generated by an HMTP server that received the request, whatever its status code. Trying another host would not help, because the condition usually applies to the domain as a whole, as with "rate-limited" or "key-unavailable", or could cause the request to be processed twice, as with "request-in-progress". The response is handled as described in , according to the class of the "smtpStatus" member: a temporary failure is retried later, and a permanent failure is not retried. Any other response is handled in the same way, according to its status code.
If no response is received after the request has been sent completely, for example because the connection is lost or a timeout expires, or if the response has the status code 504 (Gateway Timeout) and does not contain a problem details object, the outcome of the request is unknown. The request is retried later.

A request whose outcome is unknown, or that was rejected with the "request-in-progress" problem type, may have been processed, or may still be processed, by the host. A retry at another host could then cause duplicate delivery, because the other host does not necessarily know the Transfer Identifier. The sender therefore sends the retry () to the same host, rather than to a host chosen in a new random order. It proceeds to the other hosts, in the order described above, only if the retry fails at that host in one of the first four ways listed above, or if the host is no longer listed in the SVCB records of the domain. Even then, the host may have processed the request before it became unreachable. A domain that publishes several hosts SHOULD therefore ensure that the stored Transfer Identifiers are shared among them. Where this is not possible, for example for a backup host operated by a third party, duplicate delivery can still occur (see ). A server MAY reuse an established connection to a host for further requests for the same domain while the SVCB records that led to the host remain valid. In the following example, the hosts "hmtp1.example.net" and "hmtp2.example.net" share the lowest priority. Each of them is tried first with equal probability, and the other one is tried if the first fails. The host "backup.provider.example" is tried only if both fail:

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 "/.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 (). This document defines the following members:

"transfer": the Transfer Endpoint Object, which describes the endpoint for transfer () and the related OPTIONAL endpoint for delivery status reports ();
"submission": the Submission Endpoint Object, which describes the endpoint for submission () and the related identities endpoint ().

At least one of "transfer" and "submission" MUST be present. Additional endpoints MAY be defined by capabilities () and are registered as described in .

limits:

OPTIONAL. A JSON object describing limits of the server, which apply to all of its endpoints unless an Endpoint Object specifies other values (). 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 .
"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 ). 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 . Where this document refers to a limit of a server or of the recipient of a request, it means the value that applies to the endpoint to which the request is sent.

policy:

OPTIONAL. A JSON object that expresses the downgrade policy of the domains served by this host. It is specified in .

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 . Their names are either registered with IANA or URIs that serve only as unique names ().

Recipients of the Capabilities Document MUST ignore members they do not understand.

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 members:

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 .
limits:: OPTIONAL. A JSON object with the same members as the "limits" member of the Capabilities Document (). Its members apply to requests sent to the endpoints described by the Endpoint Object, including related endpoints such as "reports" and "identities". For each limit, a value given in the Endpoint Object takes precedence over the value in the "limits" member of the Capabilities Document; if neither contains the limit, the default described there applies. This allows a server, for example, to apply different limits to submission by its own users and to transfer from other domains.

Requests do not carry the version of HMTP that they use. Instead, the version of a request is determined by the endpoint to which it is sent: a request sent to an endpoint described in a Version Object is a request of that version. The URI of every endpoint, after it has been resolved, MUST therefore differ from the URIs of the endpoints of all other versions in the same Capabilities Document. This applies to the "uri" member of an Endpoint Object as well as to the URIs of related endpoints, such as the "reports" and "identities" members. For example, a server can include the version in the path of each URI, as in "/hmtp/v1/transfer". The specification of an endpoint, or a capability (), 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 contains the following member in addition to "uri":

reports:: OPTIONAL. The URI of the endpoint for delivery status reports (), subject to the same rules as "uri". If this member is absent, the domains served by the host do not accept reports, and DSN messages are sent to them instead.

Transfer requests and reports are authenticated by signatures (), so no authentication parameters apply to the Transfer Endpoint Object. The Submission Endpoint Object contains the following members in addition to "uri":

identities:: OPTIONAL. The URI of the identities endpoint (), 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 .
oauthResourceMetadata:: OPTIONAL. The URI of the OAuth 2.0 Protected Resource Metadata of the Submission Server, subject to the same rules as "uri". If this member is absent, Clients locate the metadata as specified in . The resource identifier of a Submission Server is the origin of its submission endpoint.

Retrieval and Caching Servers SHOULD include caching information in the response, and recipients MAY cache the document as specified in . 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.

Example The following example shows the DNS record and the Capabilities Document of a domain whose mail is handled by a provider: In this example, a submission request can contain at most 100 Envelope Recipients, while a transfer request can contain up to 1000. The other limits apply to both endpoints.

Data Model All JSON documents defined by this document MUST conform to the Internet JSON (I-JSON) profile . 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 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 . The array MUST NOT contain duplicates. If this member is absent, it is equivalent to an empty array.
envelope:: REQUIRED. The Envelope ().
message:: REQUIRED. A Content Object () whose content is the Message.

The Request Object does not identify the version of HMTP; the version is determined by the endpoint to which the request is sent (). The response to a successful request is a Response Object, specified in .

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 22 characters consisting only of the characters of the base64url alphabet (): "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 ). The sender MUST generate the Transfer Identifier with at least 128 bits of randomness, for example from 16 random octets encoded in base64url without padding, which yields 22 characters. A request whose Transfer Identifier does not meet the requirements on its length and characters 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 ():

for a transfer request, the Sending Domain, that is, the domain of the key that signed the request as established by the verification procedure (). 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. Neither is the selector of the key, so that a retry is recognized even if it is signed with a new key after a key rollover;
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. Several independent senders can share one scope, for example a domain and an email service provider to which it has delegated a selector (). The randomness of Transfer Identifiers ensures that the identifiers of such senders do not collide without any coordination between them.

from:

REQUIRED. The Envelope Sender. The value is either a "Mailbox" as defined in , 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 .

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 . It has the following members, both OPTIONAL:

"ret": the string "full" or "hdrs", with the semantics of the RET parameter of ;
"envid": a string with the semantics of the ENVID parameter of . 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 .

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" , and "BINARYMIME" , 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 Envelope or any header field of the Message contains non-ASCII characters, as permitted by and . 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 . The default is false. HMTP hops always satisfy this requirement; SMTP hops are governed by .

A Recipient Object is a JSON object with the following members:

address:

REQUIRED. The Envelope Recipient. The value is a "Mailbox" as defined in , without the enclosing angle brackets, or, if "smtpUtf8" is true, as extended by . A sender MUST NOT send an address that does not have this syntax. If the value is a string that does not have this syntax, the Request Object is nevertheless valid: the recipient of the request rejects only this Envelope Recipient, with the "invalid-address" problem type (), and processes the other Envelope Recipients as usual.

dsn:

OPTIONAL. A JSON object that carries the per-recipient parameters of the DSN extension . It has the following members, both OPTIONAL:

"notify": an array of strings with the semantics of the NOTIFY parameter of . 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 , 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 () or to perform discovery, it is first converted to A-labels and then compared without regard to case. The following example shows an Envelope:

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 , 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 with the "https" scheme from which the content is retrieved, as described in .
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.
encoding:: OPTIONAL. The name of a transformation that is applied to the retrieved representation data to produce the content, as described in . 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 and whose values are the hashes computed with these algorithms, encoded using base64 as defined in . 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 () 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:

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 .
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 .
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:

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 ). By doing so, it accepts responsibility for retrieving the content and MUST complete the retrieval before the earliest "expires" timestamp of the Content References, unless it passes the Content References on to a next hop as described below. 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 .

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 ). 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. The following rules apply to a server that passes Content References on:

Because it has not retrieved the content, it responds to the request in which it received the Message with the status code 202 (Accepted), not 200 (OK). It does not need to retrieve or verify the content itself.
Its responsibility for the retrieval passes to the next hop when the next hop accepts the Message for an Envelope Recipient. From then on, the next hop is responsible for the retrieval for that recipient as described above, whether it retrieves the content before or after responding or passes the Content References on in turn. If the retrieval fails, the server that is responsible for it at that time generates the delivery status notifications ().
Until the next hop accepts the Message, for example while delivery to it is retried, the server remains responsible for the retrieval. If it cannot pass the Content References on while at least 24 hours remain before their "expires" timestamp, it MUST retrieve the content itself as described above.

The original sender does not learn whether or when the content has been retrieved along the path. Because it has received the status code 202 (Accepted), it keeps the content available until its "expires" timestamp, as described above, which also allows servers further along the path to retrieve it. 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.

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 , 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 . Attachments are usually encoded with the base64 Content-Transfer-Encoding , 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 . 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 . 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: 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.

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.

Capability Names A capability is identified by its name. A name takes one of two forms:

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 () before it is used, which requires a publicly available specification (see ). 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 , 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.

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.
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 () 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.

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.

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 . 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: 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: 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: 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.

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 set of usable ServiceMode records, that is, records with the same SvcPriority, TargetName, and SvcParams, regardless of the order in which they were returned. A Sending Server groups the Envelope Recipients accordingly, sends a separate request for each group, and selects the host for each request as described in . A set of records does not identify a single host in advance, because hosts of the same priority are tried in random order, but every host in the set serves all domains of the group.

Request A transfer request is an HTTP POST request to the transfer endpoint, with the following properties:

The content of the request is a Request Object (), and the Content-Type header field is "application/json".
The request MUST contain a Content-Digest header field 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 , using the Signature-Input and Signature header fields .
If the Envelope Sender is not empty, its domain MUST be aligned with the Sending Domain as described in .
The request does not use HTTP authentication. Receiving Servers ignore any Authorization header field in a transfer request.
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 .

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 . 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 . The following example shows a transfer request:

Processing by the Receiving Server A Receiving Server processes a transfer request as follows:

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.
It verifies the signature and the Content-Digest of the request as described in , including the alignment of the Envelope Sender ().
It parses the Request Object and validates it against . It rejects an invalid Request Object with the "invalid-request" problem type. A syntactically invalid address of an Envelope Recipient does not make the Request Object invalid; it is handled in step 7.
It checks the Transfer Identifier as described in . 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.
It checks that it supports every capability listed in the "capabilities" member ().
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.
It determines, for each Envelope Recipient, whether it accepts the Message for that recipient. It rejects an Envelope Recipient whose address is syntactically invalid () with the "invalid-address" problem type. 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.
It retrieves referenced content as described in , either before responding or after responding, or, if it relays the Message, passes the Content References on to the next hop.
It prepends trace header fields as described in , 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.

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:

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, or for passing the Content References on to a next hop that takes over this responsibility, as described in . 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 (). 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 ; 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 . It MUST NOT lose the Message, and if it later fails to deliver it, it generates a delivery status notification as described in .
"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 , 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:

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. The scope of a Transfer Identifier is the Sending Domain for transfer requests, and the authenticated account of the Client for submission requests (see ). 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 (), 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 to a transfer or submission request, or a 204 (No Content) response to a delivery status report (), 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. The hash is computed over the content after any content coding has been removed, so that a retry is recognized even if it uses a different content coding. When the Receiving Server 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 the stored response contains a Response Object, the problem details object contains, as extension members, its "recipients" member and, if present, its "queueId" member.

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 either waits until the processing of the first request has been completed and then proceeds as described above, or rejects the second request with the "request-in-progress" problem type, which is a temporary failure. A response with this problem type SHOULD include 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. If the outcome of the earlier attempt is unknown, or if it was rejected with the "request-in-progress" problem type, the retry is sent to the same host as described in .
For Envelope Recipients with the result "deferred", the sender sends a new request containing only those recipients, with a new Transfer Identifier.
The sender MUST NOT retry a request, or deliver to an Envelope Recipient, after a permanent failure.

The content of a retry is compared with the content of the earlier request octet for octet. The sender MUST therefore retain the octets of the content of the request and MUST resend them unchanged. A Request Object that is serialized again, for example from fields that the sender has stored in a database, is different content, even if it represents the same JSON values, because the order of members, whitespace, and escaping can differ. Only the header fields of the request, including its signature, and its content coding can differ between attempts. If a retry is nevertheless rejected with the "id-conflict" problem type, the earlier request has been processed, and the problem details object contains its results. A sender that receives this problem type in response to a retry of its own earlier request MUST treat these results as the results of the earlier request, and not as a failure of the whole request. In particular, it MUST NOT generate a delivery status notification reporting a failure for an Envelope Recipient that has the result "accepted". If the request was not a retry, the "id-conflict" problem type is 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 in the response. Otherwise, the intervals between retries and the time after which the sender gives up SHOULD follow the guidance of . When the sender gives up, it generates a delivery status notification as described in . Before each retry, the sender repeats discovery if its cached results have expired.

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 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 ).
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 ).

A server MAY also prepend other trace header fields, such as an Authentication-Results header field that records the result of the verification described in . 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 . The following example shows a Received header field added by a Receiving Server:

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 ), with the following differences:

The Client authenticates using HTTP authentication as described in . 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 , except that it authenticates the Client instead of verifying a signature, accepts Envelope Recipients in any domain, verifies the sender addresses as described in , and validates the Message as described in . It responds with a Response Object as described in . 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 (). The Transfer Identifier of a submission request is scoped to the authenticated account, as described in , so that a Client can safely retry a submission after a lost response.

Client Authentication The "authentication" member of the Submission Endpoint Object () lists the HTTP authentication schemes 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 . 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 . Access tokens are obtained using OAuth 2.0 . The Client discovers the authorization servers and the supported scopes from the OAuth 2.0 Protected Resource Metadata 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 . If a bearer token is valid but lacks a required scope, the server responds as specified in . 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:

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 (). 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 . 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 (). A Submission Server therefore only includes in the identities of a Client addresses for which it can produce such signatures.

Message Validation and Modification A Submission Server MUST verify that the Message conforms to , 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. A Submission Server MAY add a Date header field or a Message-ID header field if either is missing, as permitted by . Besides adding these fields, prepending trace header fields (), and prepending DKIM-Signature header fields , 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 ().

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 (). A Client sends an HTTP GET request to the endpoint, authenticated as described in . 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 .
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 . The response is specific to the authenticated account and MUST be marked accordingly for caches, for example with "Cache-Control: private".

Authentication and Signing Every transfer request is signed by the Sending Server using HTTP Message Signatures . The public keys are published in DNS using the key record format and location defined by DKIM , 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.

Signing Keys A signing key is identified by a selector and a domain, as in DKIM (). In a signature, the selector is carried in the "keyid" parameter and the domain in the "domain" parameter (). The public key is published as a DKIM key record () 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" corresponds to the signature algorithm "ed25519", and the value "rsa" corresponds to the signature algorithm "rsa-v1_5-sha256", both as defined in . 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.
"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 .
"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 , 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 ). 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.

Signature Construction The Sending Server creates a signature as specified in , 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 .
The signature parameters () MUST include "created", "expires", "keyid", "domain", "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 selector of the key, with the syntax defined in , for example "hmtp2026".
- "domain" is the Sending Domain, that is, the domain under which the key record is published, in A-label form, without a trailing dot, for example "example.com". This parameter is defined in . If the Envelope Sender is not empty, the Sending Domain MUST be aligned with it as described in .
- "alg" is the signature algorithm that corresponds to the key type of the key record.
- "tag" is the string "hmtp".
The key record is located at the name formed from these two parameters as <keyid>._domainkey.<domain>. Because both parameters are covered by the signature, they cannot be changed without invalidating it.
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: The corresponding key record, located at hmtp2026._domainkey.example.com, is:

Signing of Retrieval Requests A Receiving Server MAY sign the requests with which it retrieves referenced content (), using a key of its own domain published as described in . Such a signature covers at least "@method" and "@target-uri", contains the signature parameters required in , 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.

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.

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.
It verifies that the covered components and signature parameters meet the requirements of and that it supports the algorithm given in "alg".
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".
It verifies that "keyid" is a selector with the syntax defined in and that "domain" is a domain name in A-label form. The value of "domain" is the Sending Domain.
It queries DNS for TXT records at the name <keyid>._domainkey.<domain>. 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 when available.
It verifies that the key record meets the requirements of and that its key type corresponds to "alg".
It verifies the signature as specified in .
It verifies that the Content-Digest header field matches the content of the request as specified in . If it does not, it rejects the request with the "digest-mismatch" problem type.
It verifies the alignment of the Envelope Sender with the Sending Domain as described in .

If verification fails, the response MAY include an Accept-Signature header field as described in . 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.

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 ). 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.

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: The provider signs with "keyid" set to "esp1" and "domain" set to "example.com", which is the Sending Domain. 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.

Delivery Status and Errors HMTP reports failures in two ways: synchronously, through problem details objects in responses, and asynchronously, through delivery status notifications.

Problem Details When a request fails as a whole, the server responds with a 4xx or 5xx status code and a problem details object 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 (); 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:<name> and are registered as described in . Servers MAY use other problem type URIs as permitted by . This document defines the following extension members of problem details objects:

smtpStatus:: REQUIRED in problem details objects sent by HMTP servers. An enhanced mail system status code in the form "class.subject.detail". The class MUST be 4 (persistent transient failure) or 5 (permanent failure). In a response, 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. In a delivery status report, the "action" member determines whether delivery has failed, and the class 4 can also describe a failure after which the reporting server has given up ().
smtpReply:: OPTIONAL. An SMTP reply code that corresponds to the failure. It is used when the failure is reported over SMTP, for example by a gateway () or in a delivery status notification (). If it is absent, the reply code from 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) and 503 (Service Unavailable) SHOULD include a Retry-After header field. The following example shows a request that was rejected as a whole:

Mapping to SMTP Status Codes 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. HMTP Problem Types

Name	Scope	HTTP	Enhanced Status	Reply
invalid-request	Request	400	5.5.2	501
unsupported-capability	Request	400	5.5.4	555
id-conflict	Request	409	5.5.4	501
request-in-progress	Request	409	4.3.0	451
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 / 422	4.4.1 / 5.6.0	451 / 554
content-mismatch	Request	422	5.7.7	554
loop-detected	Request	422	5.4.6	554
policy-rejected	Both	403	4.7.1 / 5.7.1	451 / 550
unknown-recipient	Recipient	-	5.1.1	550
invalid-address	Recipient	-	5.1.3	553
domain-not-served	Both	422	5.1.2	550
mailbox-disabled	Recipient	-	5.2.1	550
mailbox-full	Recipient	-	4.2.2 / 5.2.2	452 / 552
routing-failed	Recipient	-	4.4.4 / 5.4.4	451 / 550
delivery-expired	Recipient	-	4.4.7	451
conversion-required	Recipient	-	5.6.3	554
tls-required	Recipient	-	5.7.30	550

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 , 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 (). The problem details object contains the results of the earlier request.
request-in-progress:: A request with the same Transfer Identifier in the same scope is still being processed (). The sender retries the request later at the same host ().
signature-invalid:: The request has no valid HMTP signature ().
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 ().
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 .
sender-not-authorized:: The Client is not authorized to use an originator address of the Message ().
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 ().
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 .
loop-detected:: The Message has passed through too many servers ().
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 (). Only this Envelope Recipient is rejected; the other Envelope Recipients of the request are not affected.
domain-not-served:: The server does not accept Messages for the domain of the Envelope Recipient and has no agreement to relay them, or, for a delivery status report, does not serve the domain of the "envelopeSender" member ().
mailbox-disabled:: The recipient mailbox exists but does not accept Messages.
mailbox-full:: The recipient mailbox has exceeded its storage limit.
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.
delivery-expired:: The server has given up retrying the delivery to the recipient (), and no more specific problem type is available. It is used in delivery status reports and DSN messages with the action "failed" () and corresponds to the enhanced status code for an expired delivery time defined in .
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, or because the request uses a must-understand capability that cannot be forwarded over SMTP ().
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 .

Mapping from SMTP Replies maps problem types to SMTP replies. A server that forwards a Message over SMTP, for example after a fallback () or to an SMTP server of the recipient domain (), receives SMTP replies instead of problem details objects. When it reports a failure that it received in an SMTP reply in a problem details object, for example in a delivery status report () or in its own response to an HMTP request, it constructs the problem details object as follows:

The "smtpStatus" member contains the enhanced status code of the reply. If the reply does not contain an enhanced status code, for example because the SMTP server does not support the ENHANCEDSTATUSCODES extension , it contains "4.0.0" or "5.0.0", according to the first digit of the reply code.
The "smtpReply" member contains the reply code.
The "detail" member contains the text of the reply, without the reply code and the enhanced status code.
If lists the enhanced status code for a problem type with the scope "Recipient" or "Both", the "type" member identifies that problem type, for example "urn:ietf:params:hmtp:error:unknown-recipient" for the code 5.1.1. Otherwise, the "type" member contains "about:blank" (), and the failure is described only by the other members.

A reply that applies to all Envelope Recipients, such as a rejection of the MAIL FROM or DATA command, is reported in this way for each of them.

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 and . The DSN parameters of the Envelope () 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 (). 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 ().
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.
If the domain of the Envelope Sender supports delivery status reports, the information is sent as a report instead of a DSN message, as described in . All HMTP servers MUST continue to accept DSN messages, which are ordinary Messages.

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 (), the host name of the SMTP server, with the type "dns".
The "Status" field contains the enhanced status code from the "smtpStatus" member of the problem details object. A server that gives up after retries uses the "failed" action together with the enhanced status code of the last temporary failure, which has the class 4, or, if no more specific code is available, the code 4.4.7 of the "delivery-expired" problem type. As described in , the class 4 then denotes a persistent transient failure that has caused the abandonment of delivery attempts.
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.

Example The following DSN is generated by the Sending Server in the example of for the rejected Envelope Recipient "dave@example.org". It uses the "multipart/report" media type with a "message/delivery-status" part . Because the "ret" member of the Envelope is "hdrs", the DSN contains only the header section of the original Message: 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 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 ():

Delivery Status Reports DSN messages are designed to be read by people and are difficult to process automatically, because the information has to be extracted from a multipart Message. When both the reporting server and the domain of the Envelope Sender support HMTP, the same information can instead be sent as a delivery status report: a JSON document that is transferred directly to the "reports" endpoint of that domain. Delivery status reports are OPTIONAL. A server that does not support them sends DSN messages as described in , and every HMTP server MUST continue to accept DSN messages. A report carries the same information as a DSN message and is subject to the same rules on when it is generated: a report is sent only where and call for a DSN.

Sending Reports When a server is about to generate a DSN for a Message whose Envelope Sender is not empty, it performs discovery () for the domain of the Envelope Sender. If the domain supports HMTP and the Transfer Endpoint Object in a version that the server supports contains a "reports" member (), the server SHOULD send a report to the URI given in that member instead of generating a DSN message. Otherwise, it generates a DSN message. A report is sent with an HTTP POST request to the "reports" endpoint. The request has the same properties as a transfer request (), except that its content is a Report Object ():

The Content-Type header field is "application/json", and the request contains a Content-Digest header field.
The request is signed as described in on behalf of the domain of the reporting server. Because a report has no Envelope Sender, the alignment rules of do not apply, as for a Message with an empty Envelope Sender.
The "id" member of the Report Object is a Transfer Identifier, and retries follow the rules of . The server that receives the report stores the Transfer Identifier when it responds with the status code 204 (No Content), as it does for a transfer request when it responds with 200 (OK) or 202 (Accepted).

A report covers one Message and MAY cover several of its Envelope Recipients, in the same way as a single DSN message. A server MUST NOT combine information about different Messages in one report. If the request fails temporarily, the server retries it as described in . If the request fails permanently, or if the server gives up retrying, it MUST generate a DSN message instead, so that the information is not lost. A retry that is rejected with the "id-conflict" problem type is not a permanent failure in this sense: it indicates that the earlier report has been accepted (). No report and no DSN message is generated about the failure to deliver a report or a DSN message.

Report Object A Report Object is a JSON object with the following members:

id:: REQUIRED. The Transfer Identifier of the report, with the syntax and semantics described in and .
envelopeSender:: REQUIRED. The Envelope Sender of the original Message, to which the report is addressed.
reportingServer:: REQUIRED. The host name of the server that generates the report.
transferId:: OPTIONAL. The Transfer Identifier of the transfer request in which the reporting server received the Message, if it received the Message in a transfer request. This member is present if and only if "transferDomain" is present.
transferDomain:: OPTIONAL. The Sending Domain of that transfer request, in A-label form, which is the scope of "transferId" (). This member is present if and only if "transferId" is present. Together, "transferId" and "transferDomain" allow the sender of that request to correlate the report with the request. The report is sent to the domain of the Envelope Sender, which is not necessarily the Sending Domain of that request, for example if the Message reached the reporting server through a relay.
envid:: OPTIONAL. The value of the "envid" member of the Envelope of the original Message, if present.
messageId:: OPTIONAL. The value of the Message-ID header field of the original Message, if present.
arrivalDate:: OPTIONAL. A timestamp at which the reporting server received the Message.
recipients:: REQUIRED. A non-empty array of Recipient Report Objects, one for each Envelope Recipient that the report covers.
returnedContent:: OPTIONAL. A Content Object () that contains the original Message or its header section, as requested by the "ret" member of the Envelope, under the same conditions as for a DSN message.

A Recipient Report Object is a JSON object with the following members:

finalRecipient:: REQUIRED. The address of the Envelope Recipient to which the report refers.
originalRecipient:: OPTIONAL. The value of the "orcpt" member of the Recipient Object, if present.
action:: REQUIRED. The action taken for the recipient: one of "failed", "delayed", "delivered", "relayed", and "expanded", with the semantics of the Action field of .
problem:: REQUIRED for the actions "failed" and "delayed", and absent otherwise. A problem details object () that describes the reason for the action. Its "smtpStatus" member is the enhanced status code of the recipient. For the action "delayed", it MUST have the class 4. For the action "failed", it has the class 5 if the failure is permanent, or the class 4 if the reporting server has given up after a persistent temporary failure, as described in . The action, not the class, determines whether the reporting server makes further delivery attempts. If the failure was reported by an SMTP server, the problem details object is constructed as described in . For the actions "delivered", "relayed", and "expanded", the enhanced status code is "2.0.0".
remoteServer:: OPTIONAL. The host name of the server that reported the failure, such as the TargetName of an HMTP Endpoint or the host name of an SMTP server.
lastAttempt:: OPTIONAL. A timestamp of the last delivery attempt.
willRetryUntil:: OPTIONAL. For the action "delayed", a timestamp after which the reporting server will stop retrying.

Processing Reports The server that receives a report verifies the request as described in , except for the alignment check. It rejects a report whose "envelopeSender" is in a domain that it does not serve with the "domain-not-served" problem type. It checks the Transfer Identifier of the report as described in : if the report is a retry of a report that has already been processed, it returns the stored response and does not process the report again, so that the Envelope Sender receives the information only once. Otherwise, it responds with the status code 204 (No Content) and stores the Transfer Identifier. By doing so, it accepts responsibility for the report in the same way as for a Message. The server SHOULD correlate the report with a Message that it sent, using the "transferId", "envid", and "messageId" members. It uses the "transferId" member only if the "transferDomain" member is a Sending Domain on whose behalf it signs transfer requests; otherwise, the Transfer Identifier belongs to the scope of another domain, such as that of a relay, and is ignored. It MAY discard a report that it cannot correlate with any Message, but it still responds with the status code 204 (No Content), so that the reporting server does not retry the report. Senders that rely on reports SHOULD use values of "envid" that cannot be guessed (see ). The server then makes the information available to the Envelope Sender. If the Envelope Sender is a mailbox that is read with a mail client, the server SHOULD convert the report into a DSN message as described in and deliver it to the mailbox, so that existing clients can display it. Automated recipients, such as mailing list managers and bounce processing systems, can process the report directly.

Mapping to DSN Fields lists the members of a report and the corresponding fields of a DSN message . Timestamps are converted to the date-time format of . Host names use the type "dns". Addresses use the type "rfc822" or, for internationalized addresses, the type defined in . The "returnedContent" member becomes the third part of the DSN message, of type "message/rfc822" for the full Message or "text/rfc822-headers" for the header section. Mapping of Reports to DSN Fields

Report member	DSN field
reportingServer	Reporting-MTA
envid	Original-Envelope-Id
arrivalDate	Arrival-Date
originalRecipient	Original-Recipient
finalRecipient	Final-Recipient
action	Action
problem, "smtpStatus" member	Status
problem	Diagnostic-Code, of type "smtp"
remoteServer	Remote-MTA
lastAttempt	Last-Attempt-Date
willRetryUntil	Will-Retry-Until

The "Status" field contains the "smtpStatus" member of the problem details object, or "2.0.0" if the report contains no problem details object for the recipient. The "Diagnostic-Code" field is composed from the "smtpReply", "smtpStatus", and "detail" members of the problem details object, as described in , and is omitted if there is no problem details object.

Example In the example of , the Receiving Server "mx.example.net" accepted the Message for "bob@example.net". When it later fails to deliver the Message because the mailbox is over quota, it performs discovery for "example.com", the domain of the Envelope Sender, finds a "reports" endpoint, and sends the following report instead of a DSN message: ", "arrivalDate": "2026-01-01T12:00:01Z", "recipients": [ { "finalRecipient": "bob@example.net", "action": "failed", "problem": { "type": "urn:ietf:params:hmtp:error:mailbox-full", "title": "Mailbox full", "detail": "The mailbox bob@example.net is over quota.", "smtpStatus": "5.2.2", "smtpReply": 552 }, "lastAttempt": "2026-01-01T12:10:00Z" } ] } HTTP/1.1 204 No Content ]]> The request is signed by "example.net", the domain of the reporting server. The server of "example.com" correlates the report with its earlier transfer request through the "transferId" member, because the "transferDomain" member is its own Sending Domain. Had the Message reached "mx.example.net" through a relay, "transferDomain" would contain the Sending Domain of the relay, and the server of "example.com" would correlate the report through the "envid" or "messageId" member instead.

SMTP Fallback and Interoperability HMTP is a self-contained protocol. Support for SMTP is OPTIONAL and serves the interoperability with domains and systems 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.

When to Fall Back The rules in this section apply when the next hop for an Envelope Recipient is determined by discovery. Forwarding a Message to a next hop that is determined by local configuration is not a fallback and is described in . A Sending Server that supports SMTP MAY deliver a Message to an Envelope Recipient using SMTP only if all of the following conditions hold:

Discovery () has determined that the domain of the Envelope Recipient does not support HMTP.
The Sending Server has no unexpired downgrade policy with the mode "enforce" for that domain ().
Every must-understand capability that the request uses () can be forwarded over SMTP: its specification defines how the capability is handled when the Message is forwarded over SMTP, for example by mapping it to an SMTP extension or by completing its function before the Message is forwarded.

If the first two conditions hold but the third does not, the Message can be delivered neither over HMTP nor over SMTP. The delivery to the affected Envelope Recipients fails with the "conversion-required" problem type, and the Sending Server generates a delivery status notification (). The third condition also applies when the next hop is determined by local configuration (). 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 . 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 , with the following requirements:

It locates the SMTP server using MX records as specified in . If the domain publishes a null MX record , the Message cannot be delivered.
It retrieves all referenced content and reconstructs the Message before the transfer, because SMTP cannot carry Content References.
It transmits the Envelope using the parameters of the corresponding SMTP extensions: the BODY parameter for "body" , the SMTPUTF8 parameter for "smtpUtf8" , the RET, ENVID, NOTIFY, and ORCPT parameters for the DSN parameters , and the REQUIRETLS parameter for "requireTls" . Values are encoded as "xtext" where 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 cannot be met, the delivery fails with the "tls-required" problem type.
Members of capabilities that are not must-understand are not transferred over SMTP. If a must-understand capability is mapped to an SMTP extension that the SMTP server does not support, the delivery fails with the "conversion-required" problem type, as for other extensions that the Message requires.
If the SMTP server does not support the DSN extension, the Sending Server behaves as specified in for relaying to a server that does not support it.
Where a failure reported by the SMTP server needs to be expressed as a problem details object, for example in a delivery status report, the Sending Server constructs it as described in .
It SHOULD use STARTTLS and SHOULD apply MTA-STS or DANE when the domain publishes them.

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: 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: 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: 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:

"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 , 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 (). The SMTP server advertises ENHANCEDSTATUSCODES , 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 . 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.

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 and MTA-STS . The policy is expressed in the "policy" member of the Capabilities Document (), 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 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 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.

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".

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 . 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 . 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 . Otherwise, it accepts the Message, relays it later, and reports failures through DSNs.

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.
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 () 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.

Abuse and Reputation Considerations This document does not define spam filtering or reputation algorithms, which remain a matter of the local policy of each Receiving Server. This section describes the information that HMTP makes available to such policies and the ways in which features of HMTP can be abused.

Information Available to Receivers When it evaluates a transfer request, a Receiving Server can use the following information in addition to the content of the Message:

the Sending Domain, authenticated by the signature of the request (), and its alignment with the Envelope Sender ();
the selector of the signing key, which a domain can use to separate different streams of mail, such as transactional and bulk mail, or the mail of different customers of a provider;
the IP address from which the request was received, which identifies an intermediary rather than the Sending Server when the request passes through a proxy;
the results of the DKIM and DMARC evaluation of the Message;
the Envelope, including the Envelope Sender and the number of Envelope Recipients.

SPF authorizes hosts to use a domain in SMTP sessions and is not used for HMTP requests, whose sender is authenticated by the signature. Because a Sending Server can operate behind proxies and content delivery networks, Receiving Servers SHOULD NOT evaluate SPF against the IP address of an HMTP request. SPF continues to apply to SMTP hops.

Reputation of Sending Domains A valid signature establishes which domain is responsible for a request. It does not indicate that the request is legitimate. Domains can be registered at low cost, so an attacker can sign requests with newly registered domains. Receiving Servers SHOULD therefore treat Sending Domains without history with caution, for example by applying lower rate limits, or by deferring part of their mail with the "rate-limited" or "policy-rejected" problem types and a temporary enhanced status code. A Sending Domain is responsible for all Envelope Senders that are aligned with it (), including those in its subdomains, and the reputation earned with such mail applies to the Sending Domain. When a provider signs with its own domain on behalf of its customers (), the reputation accrues to the provider, which is then responsible for abuse by its customers. When a customer delegates a selector to a provider, the reputation accrues to the domain of the customer. The restrictions on signatures of registry suffixes described in also apply to reputation.

Rejection and Backscatter Because the Receiving Server reports the result for each Envelope Recipient in its response (), it can reject an unwanted Message during the request. A Receiving Server SHOULD reject a Message that it does not intend to deliver in its response, rather than accepting it and generating a delivery status notification later. Later notifications create additional traffic and, for Messages that reached the Receiving Server through a relay, can be sent to an Envelope Sender that did not send the Message. The "detail" member of a problem details object for a policy rejection SHOULD allow a legitimate sender to understand the reason for the rejection, but does not need to reveal the internal rules of the filtering system.

Abuse of Content References An attacker can include Content References to URIs of a third party in many requests and thereby cause Receiving Servers to send retrieval requests to that party. The checks of size and digest prevent such content from being delivered, but not the retrieval requests themselves. Receiving Servers SHOULD limit the number and rate of retrievals per Sending Domain and per target host. Because each request is signed, such abuse can be attributed to the Sending Domain. Content References can also be used to deliver malicious content. Because a Message is reconstructed completely before it is delivered (), Receiving Servers can apply their content checks to referenced content in the same way as to inline content.

Abuse of Submission Compromised Client credentials are a common source of abusive mail. Submission Servers SHOULD apply rate limits per account, SHOULD monitor accounts for unusual sending patterns, and SHOULD support bearer tokens with a limited lifetime (). Because a Submission Server signs the Messages that it relays with keys of its Sending Domain, abuse by its users affects the reputation of that domain.

Abuse Reports Complaints about abusive Messages, such as reports in the Abuse Reporting Format , are sent as ordinary Messages and are not affected by this document. Delivery status reports () are not intended for complaints. A structured endpoint for abuse reports could be defined as a capability ().

Implementation Status No implementations are known at the time of writing.

Security Considerations

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.

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. The downgrade policy () 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 () prevents an attacker from forcing a downgrade by blocking HTTPS connections.

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.

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 . 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 , 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 still permits for DKIM, are not permitted for HMTP.

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.

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 (). Receiving Servers MUST NOT disclose these URIs to recipients of the Message.

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 (), SHOULD apply rate limits per Sending Domain and per IP address, and MAY verify the signature before receiving the content of the request.

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. A Submission Server MUST authenticate every submission request and MUST verify the sender addresses (). 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.

Delivery Status Reports A report is authenticated by the domain of the reporting server, but that domain is not necessarily related to the Envelope Sender or to the Envelope Recipients, because a Message can pass through servers of several domains. An attacker can therefore send forged reports about Messages that it did not handle, for example to cause a sender to remove a valid address from a mailing list. Receivers of reports SHOULD accept only reports that they can correlate with a Message they sent (). Senders that act on reports automatically SHOULD use unguessable values of "envid", so that only servers that have handled the Message can produce a matching report. The same considerations apply to DSN messages, which are not authenticated at all; reports are an improvement in that they identify the reporting domain.

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. For the same reason, the results of an earlier request that accompany the "id-conflict" problem type () are disclosed only to a sender in the same scope. Within a scope that is shared by several senders, such as a domain and its email service providers, the randomness of Transfer Identifiers also prevents one sender from predicting the identifiers of another. The limit on the length of Transfer Identifiers bounds the storage that a Receiving Server needs for them. Transfer Identifiers prevent duplicate delivery only among hosts that share the stored Transfer Identifiers (). If a host accepts a Message and becomes unreachable before the Sending Server receives the response, the Sending Server retries the request at another host of the domain. A host that does not share the stored Transfer Identifiers, such as a backup host operated by a third party, accepts the retry as a new request and relays the Message to the domain with its own signature, that is, with a Transfer Identifier in the scope of its own Sending Domain. The Message is then delivered twice. This risk is comparable to the duplication that a lost reply to the DATA command causes in SMTP. Domains that use such backup hosts accept this risk. Final delivery agents can reduce its impact, for example by detecting duplicate Message-ID header fields.

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 whose domains are served by the same set of hosts (). 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 (). 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 (), 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. 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 . Submission Servers MAY replace the IP address of the Client in the Received header field with a placeholder () to protect the privacy of the user.

IANA Considerations

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 :

RR Type	_NODE NAME	Reference
SVCB	_hmtp	RFC XXXX

Well-Known URI IANA is requested to add the following entry to the "Well-Known URIs" registry :

URI Suffix:: hmtp
Change Controller:: IETF
Specification Document(s):: of RFC XXXX
Status:: permanent
Related Information:: None

DKIM Service Type IANA is requested to add the following entry to the "DKIM Service Types" registry :

Type	Reference	Status
hmtp	RFC XXXX	active

HTTP Signature Metadata Parameter IANA is requested to add the following entry to the "HTTP Signature Metadata Parameters" registry :

Name:: domain
Description:: The domain name under which the key identified by the "keyid" parameter is published, as a DKIM key record, at the name <keyid>._domainkey.<domain>.
Reference:: of RFC XXXX

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 type	Description	Reference
HMTP	HTTP Mail Transfer Protocol, transfer	RFC XXXX
HMTPA	HTTP Mail Transfer Protocol, submission with client authentication	RFC XXXX

URN Sub-namespace IANA is requested to register the following entry in the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" registry :

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:<name> 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.

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 . 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 .

HMTP Capabilities The registry contains capabilities with registered names. Capabilities identified by URIs are not registered (see ). The registry records the following fields for each capability:

Name: the registered name of the capability, with the syntax defined in .
Description: a brief description.
Must-Understand: "yes" or "no", as defined in .
Reference: the specification of the capability.
Change Controller: the party responsible for the capability.

The registry is initially empty.

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:

Name	Description	Reference
transfer	Transfer of Messages between servers, and delivery status reports	, , and of RFC XXXX
submission	Submission of Messages by Clients, and identities of an authenticated Client	and of RFC XXXX

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 characters separated by CRLF	of RFC XXXX

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:<name>.
Scope: "Request", "Recipient", or "Both".
HTTP Status: the HTTP status code used for request-level failures.
Enhanced Status: the enhanced status code or codes.
SMTP Reply: the SMTP reply code or codes.
Reference: the specification of the problem type.

The initial contents are the problem types listed in , each with the reference of RFC XXXX.

References Normative References Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies This initial document specifies the various headers used to describe the structure of MIME messages. [STANDARDS-TRACK] SMTP Service Extensions for Transmission of Large and Binary MIME Messages This memo defines two extensions to the SMTP (Simple Mail Transfer Protocol) service. [STANDARDS-TRACK] Date and Time on the Internet: Timestamps This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) This memo defines an extension to the Simple Mail Transfer Protocol (SMTP) service, which allows an SMTP client to specify (a) that Delivery Status Notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [STANDARDS-TRACK] Enhanced Mail System Status Codes This document defines a set of extended status codes for use within the mail system for delivery status reports, tracking, and improved diagnostics. In combination with other information provided in the Delivery Status Notification (DSN) delivery report, these codes facilitate media and language independent rendering of message delivery status. [STANDARDS-TRACK] An Extensible Message Format for Delivery Status Notifications This memo defines a Multipurpose Internet Mail Extensions (MIME) content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. This content-type is intended as a machine-processable replacement for the various types of delivery status notifications currently used in Internet electronic mail. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called "Local Area Network (LAN)-based" systems), the Delivery Status Notification (DSN) protocol is designed to be useful in a multi-protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses and error codes, in addition to those normally used in Internet mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet mail. [STANDARDS-TRACK] An IETF URN Sub-namespace for Registered Protocol Parameters This document describes a new sub-delegation for the 'ietf' URN namespace for registered protocol items. The 'ietf' URN namespace is defined in RFC 2648 as a root for persistent URIs that refer to IETF- defined resources. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Uniform Resource Identifier (URI): Generic Syntax A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] DNS Security Introduction and Requirements The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] The Base16, Base32, and Base64 Data Encodings This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] Simple Mail Transfer Protocol This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK] Internet Message Format This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK] Internet Mail Architecture Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. This memo provides information for the Internet community. Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK] SMTP Service Extension for 8-bit MIME Transport This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US-ASCII octet range (hex 00-7F) may be relayed using SMTP. [STANDARDS-TRACK] DomainKeys Identified Mail (DKIM) Signatures DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] Message Submission for Mail This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server. Message relay is unaffected, and continues to use SMTP over port 25. When conforming to this document, message submission uses the protocol specified here, normally over port 587. This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. [STANDARDS-TRACK] SMTP Extension for Internationalized Email This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. [STANDARDS-TRACK] Internationalized Email Headers Internet mail was originally limited to 7-bit ASCII. MIME added support for the use of 8-bit character sets in body parts, and also defined an encoded-word construct so other character sets could be used in certain header field values. However, full internationalization of electronic mail requires additional enhancements to allow the use of Unicode, including characters outside the ASCII repertoire, in mail addresses as well as direct use of Unicode in header fields like "From:", "To:", and "Subject:", without requiring the use of complex encoded-word constructs. This document specifies an enhancement to the Internet Message Format and to MIME that allows use of Unicode in mail addresses and most header field content. This specification updates Section 6.4 of RFC 2045 to eliminate the restriction prohibiting the use of non-identity content-transfer- encodings on subtypes of "message/". [STANDARDS-TRACK] Additional HTTP Status Codes This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations. [STANDARDS-TRACK] The OAuth 2.0 Authorization Framework The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] The OAuth 2.0 Authorization Framework: Bearer Token Usage This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK] The I-JSON Message Format I-JSON (short for "Internet JSON") is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results. The 'Basic' HTTP Authentication Scheme This document defines the "Basic" Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/ password pairs, encoded using Base64. Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. The JavaScript Object Notation (JSON) Data Interchange Format JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM) This document adds a new signing algorithm, Ed25519-SHA256, to "DomainKeys Identified Mail (DKIM) Signatures" (RFC 6376). DKIM verifiers are required to implement this algorithm. Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. Well-Known Uniform Resource Identifiers (URIs) This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. SMTP Require TLS Option The SMTP STARTTLS option, used in negotiating transport-level encryption of SMTP connections, is not as useful from a security standpoint as it might be because of its opportunistic nature; message delivery is, by default, prioritized over security. This document describes an SMTP service extension, REQUIRETLS, and a message header field, TLS-Required. If the REQUIRETLS option or TLS-Required message header field is used when sending a message, it asserts a request on the part of the message sender to override the default negotiation of TLS, either by requiring that TLS be negotiated when the message is relayed or by requesting that recipient-side policy mechanisms such as MTA-STS and DNS-Based Authentication of Named Entities (DANE) be ignored when relaying a message for which security is unimportant. HTTP Semantics The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. HTTP Caching The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234. HTTP/2 This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740. HTTP Message Signatures This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. Problem Details for HTTP APIs This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs. This document obsoletes RFC 7807. Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. Service Identity in TLS Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with Internet Public Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions. This document obsoletes RFC 6125. Digest Fields This document defines HTTP fields that support integrity digests. The Content-Digest field can be used for the integrity of HTTP message content. The Repr-Digest field can be used for the integrity of HTTP representations. Want-Content-Digest and Want-Repr-Digest can be used to indicate a sender's interest and preferences for receiving the respective Integrity fields. This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP fields. OAuth 2.0 Protected Resource Metadata This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References SMTP Service Extension for Returning Enhanced Error Codes This memo defines an extension to the SMTP service [RFC-821, RFC-1869] whereby an SMTP server augments its responses with the enhanced mail system status codes defined in RFC 1893. [STANDARDS-TRACK] Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK] SMTP Service Extension for Secure SMTP over Transport Layer Security This document describes an extension to the SMTP (Simple Mail Transfer Protocol) service that allows an SMTP server and client to use TLS (Transport Layer Security) to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS-TRACK] SMTP Submission Service Extension for Future Message Release This memo defines an extension to the SMTP submission protocol for a client to indicate a future time for the message to be released for delivery. This extension permits a client to use server-based storage for a message that should be held in queue until an appointed time in the future. This is useful for clients which do not have local storage or are otherwise unable to release a message for delivery at an appointed time. [STANDARDS-TRACK] SMTP Service Extension for Authentication This document defines a Simple Mail Transport Protocol (SMTP) extension whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session. This extension includes a profile of the Simple Authentication and Security Layer (SASL) for SMTP. This document obsoletes RFC 2554. [STANDARDS-TRACK] An Extensible Format for Email Feedback Reports This document defines an extensible format and MIME type that may be used by mail operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email. [STANDARDS-TRACK] Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization. This document obsoletes RFC 4408. Domain-based Message Authentication, Reporting, and Conformance (DMARC) Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse. DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection. The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages The multipart/report Multipurpose Internet Mail Extensions (MIME) media type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the multipart/report media type with respect to delivery status reports, mail processing programs will benefit if a single media type is used for all kinds of reports. This memo obsoletes "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, and marks RFC 3462 and its predecessor as "Historic". [STANDARDS-TRACK] Internationalized Delivery Status and Disposition Notifications Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3464, RFC 6522) are presently limited to ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type. This document extends RFC 3461, RFC 3464, RFC 3798, and RFC 6522. [STANDARDS-TRACK] HTTP Strict Transport Security (HSTS) This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example. [STANDARDS-TRACK] A "Null MX" No Service Resource Record for Domains That Accept No Mail Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for an A/AAAA record as a fallback. Unfortunately, this means that the A/AAAA record is taken to be mail server address even when that address does not accept mail. The No Service MX RR, informally called "null MX", formalizes the existing mechanism by which a domain announces that it accepts no mail, without having to provide a mail server; this permits significant operational efficiencies. SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) This memo describes a downgrade-resistant protocol for SMTP transport security between Message Transfer Agents (MTAs), based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS). Message Disposition Notification This memo defines a MIME content type that may be used by a Mail User Agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content type is intended to be machine processable. Additional message header fields are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and are often referred to as "read receipts," "acknowledgements," or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multiprotocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. This document is an Internet Standard. It obsoletes RFC 3798 and updates RFC 2046 (message/partial media type handling) and RFC 3461 (Original-Recipient header field generation requirement). Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM) The cryptographic algorithm and key size requirements included when DomainKeys Identified Mail (DKIM) was designed a decade ago are functionally obsolete and in need of immediate revision. This document updates DKIM requirements to those minimally suitable for operation with currently specified algorithms. Happy Eyeballs Version 2: Better Connectivity Using Concurrency Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document obsoletes the original algorithm description in RFC 6555. SMTP MTA Strict Transport Security (MTA-STS) SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers (SPs) to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate. Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. Message Header Field for Indicating Message Authentication Status This document specifies a message header field called "Authentication-Results" for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. This document obsoletes RFC 7601. The JSON Meta Application Protocol (JMAP) This document specifies a protocol for clients to efficiently query, fetch, and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation and for out-of- band binary data upload/download. The JSON Meta Application Protocol (JMAP) for Mail This document specifies a data model for synchronising email data with a server using the JSON Meta Application Protocol (JMAP). Clients can use this to efficiently search, access, organise, and send messages, and to get push notifications for fast resynchronisation when new messages are delivered or a change is made in another client. Handling Long Lines in Content of Internet-Drafts and RFCs This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. Internet Message Access Protocol (IMAP) - Version 4rev2 The Internet Message Access Protocol Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; removing messages permanently; setting and clearing flags; parsing per RFCs 5322, 2045, and 2231; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as the one specified in RFC 6409. HTTP/3 The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. OpenPGP This document specifies the message formats used in OpenPGP. OpenPGP provides encryption with public key or symmetric cryptographic algorithms, digital signatures, compression, and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. This document obsoletes RFCs 4880 ("OpenPGP Message Format"), 5581 ("The Camellia Cipher in OpenPGP"), and 6637 ("Elliptic Curve Cryptography (ECC) in OpenPGP"). HTTP submission Halon Security AB Amazon Simple Email Service API Reference: SendEmail Amazon Web Services Email Delivery Oracle

Examples This appendix contains complete examples of HMTP exchanges. As noted in , base64 data, digests, and signature values are abbreviated or illustrative.

Discovery A Sending Server that has a Message for "bob@example.net" queries DNS and retrieves the Capabilities Document of the target host:

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:

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:

Retried Request The connection is lost before the Sending Server receives the response to the request in . 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:

Delivery Status Report The Receiving Server "mx.example.net" has accepted a Message from "alice@example.com" for two recipients. The Recipient Object of "dan@example.net" requests notification on success, and the Recipient Object of "bob@example.net" requests notification on delay. The Envelope requests the return of the header section ("ret" is "hdrs"). After four hours, the Message has been delivered to "dan@example.net", while delivery to "bob@example.net" is still being retried. "mx.example.net" reports both events in one report to the "reports" endpoint of "example.com" (). The report for "dan@example.net" contains no problem details object, because the action is "delivered": ", "arrivalDate": "2026-01-01T13:00:02Z", "recipients": [ { "finalRecipient": "dan@example.net", "originalRecipient": "rfc822;dan@example.net", "action": "delivered", "lastAttempt": "2026-01-01T16:59:58Z" }, { "finalRecipient": "bob@example.net", "action": "delayed", "problem": { "type": "urn:ietf:params:hmtp:error:mailbox-full", "title": "Mailbox full", "detail": "The mailbox bob@example.net is over quota.", "smtpStatus": "4.2.2", "smtpReply": 452 }, "lastAttempt": "2026-01-01T17:00:00Z", "willRetryUntil": "2026-01-06T13:00:02Z" } ], "returnedContent": { "data": "UmVjZWl2ZWQ6IGZyb20g..." } } HTTP/1.1 204 No Content ]]> The server of "example.com" correlates the report with its Message through the "envid" member. If "alice@example.com" is read with a mail client, the server converts the report into a DSN message as described in : the recipient "dan@example.net" receives the "Status" field "2.0.0", the recipient "bob@example.net" the "Status" field "4.2.2", and the "returnedContent" member becomes a "text/rfc822-headers" part.

Acknowledgments The author thanks John Klensin and John Levine for their comments on an earlier version of this document, in particular on its relationship to SMTP and on related work.