| Internet-Draft | Email in Deep Space | July 2025 |
| Blanchet | Expires 22 January 2026 | [Page] |
This document is an assessment on the email protocols to be used in deep space and provides recommendations to deploy and use email in deep space.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 22 January 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Deep space communications involve long delays (e.g. Earth to Mars is 4-22 minutes) and intermittent communications, because of orbital dynamics. As discussed in [I-D.many-tiptop-ip-architecture], IP packets are stored by forwarders facing intermittent links, instead of dropping them. So packets travelling from Earth to a celestial body surface network may take a long time to arrive at destination, such as minutes, hours, days, weeks. The QUIC transport protocol, profiled for space delays, is used for reliable transport.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The source of this document is located at https://github.com/marcblanchet/draft-tiptop-email. Comments or changes are welcomed by filing a PR or an issue against that repository.¶
This subject should be discussed on the IETF tiptop working group mailing list.¶
On Internet, to forward an email from the sender to the receipient server, the SMTP protocol is used over TCP. Prior to sending, the IP address of the recipient server is found by quering the MX records and then the IP address records (A, AAAA) of the MX returned values. SMTP goes through a series of messages between the client and the server to exchange capabilities, sender and recipient email addresses and then content of the email. These multiple exchanges result to multiple RTT to send the whole email. To get its email, a user uses IMAP or POP, both over TCP, or a web interface. Given TCP is not appropriate for deep space links[I-D.many-tiptop-usecase], another email forwarding solution has to be found using a transport protocol suited for deep space, such as a space profiled QUIC[I-D.many-tiptop-quic-profile].¶
A more recent email protocol is JMAP [RFC8621] which uses REST over HTTP. In deep space, JMAP could be run over HTTP3 over a space profiled QUIC.¶
DNS insfrastructure need to be properly deployed and setup to avoid DNS requests through deep space links as discussed in [I-D.many-tiptop-dns].¶
Since TCP is not appropriate, HTTP over QUIC is used to transfer email over deep space.¶
On Earth, current SMTP infrastructure is used. For email to be forwarded from Earth to deep space, the following steps SHOULD be taken:¶
Reversely, an email sent from a celestial body surface network to Earth SHOULD follow these steps:¶
The Earth HTTP endpoint may be statically configured on the celestial body gateway.¶
Given the low number of celestial body networks, the use of DNS lookup may be avoided by having a static map of destination domains to HTTP endpoints, configured on the Earth mail gateway.¶
Given the use of HTTP which requires specifying a full URI, the DNS MX resource record (RR) only provides the hostname of the mail server, not the full URI.¶
The DNS URI resource record[RFC7553] SHOULD be used instead of MX rRR. The URI RR provides similar facility of the MX or SRV records enabling specifying multiple equivalent mail servers with weights, as well as multiple servers with different priorities. The service name used in the query should be "_bsmtp._https". As discussed in Section 8, the "bsmtp" service name is registered in IANA service names registry.¶
For example, the last email hop on Earth receiving an SMTP message to be forwarded to user1@moon.spaceagency.int have to find the URI and IP address of the email server on Moon. It queries the DNS for the URI RR of "_bsmtp._http.moon.spaceagency.in". The DNS response is as follows:¶
The URI RRs received above indicate with the highest priority, noted with the lowest priority number (10 instead of 20) that the host moonmailgateway1.spaceagency.int should be contacted first for email delivery and if not available, then the next priority will be used (moonmailgateway2.spaceagency.int). The Earth email server will then query the DNS for IP address records (A and AAAA) of moonmailgateway1.spaceagency.int. When received, it will connect moonmailgateway1.spaceagency.int using HTTP3 over QUIC at the full URI received previously "https://moonmailgateway1.spaceagency.int/inboundmail".¶
As noted in [I-D.many-tiptop-ip-architecture], the transport of BSMTP email over HTTP on deep space links should be accomplished over QUIC with proper transport configuration, as specified in [I-D.many-tiptop-quic-profile].¶
For emails sent from Earth, if the DNS is used, the looked up URI records and their corresponding IP address records should point to the gateway on the target celestial body network. Those records should be located or cached on the DNS infrastructure on Earth.¶
Similarly, if the DNS is used on the celestial body network, it is assumed that there will be a local DNS infrastructure that has a cache of the related records, as discussed in [I-D.many-tiptop-dns].¶
Mail headers such as Received and others contain domain names of the whole email path, which may contain various hosts on Internet. Lookup of those names on the celestial body network SHOULD NOT be done as the local cache cannot contain all the possible mail server names on Internet.¶
To minimize use of scarce deep space bandwidth, strong anti-spamming should be done before leaving Earth.¶
An anti-spamming system on the celestial body network should not rely on any database or DNS lookup located on Earth.¶
By this specification, the "bsmtp" service name, referring to [RFC2442] BSMTP specification, is registered as a service name under RFC6335 policy.¶
Initial discussions on this subject were with John Levine who helped a lot in ironing out many aspects and Pete Resnick.¶