Deploying and Using Email in Deep Space

Deploying and Using Email in Deep Space Viagenie

Canada marc.blanchet@viagenie.ca

Internet Internet Engineering Task Force dtn email space deep space smtp jmap 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.

Introduction 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 , 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. Email protocols such as SMTP and IMAP use TCP as transport, which is not suitable for space. Moreover, the chatiness of SMTP, which results in multiple round trips to send an email make it not suitable over very long delays. This document describes a framework to deploy and use email in deep space.

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

Document and Discussion Locations 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.

Assessment 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, another email forwarding solution has to be found using a transport protocol suited for deep space, such as a space profiled QUIC. A more recent email protocol is JMAP 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 .

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

an Earth mail gateway, as the last hop for email on Earth, receives email by SMTP
the gateway converts the email to Batch SMTP (BSMTP) MIME object
the gateway sends the BSMTP object using HTTP3/QUIC to the corresponding gateway on the celestial body surface network
the celestial body email gateway receives the BSMTP, disassemble it and then forwards it using SMTP to the final mail server on the celestial body network.

Reversely, an email sent from a celestial body surface network to Earth SHOULD follow these steps:

email is forwarded to the SMTP gateway on that network
The SMTP gateway converts the email to Batch SMTP MIME object
The gateway sends it using HTTP3/QUIC to the corresponding gateway on Earth.

The Earth HTTP endpoint may be statically configured on the celestial body gateway.

Discovering the Next Mail Server 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 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 , 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:

_bsmtp._https IN URI 10 1 "https://moonmailgateway1.spaceagency.int/inboundmail"
_bsmtp._https IN URI 20 1 "https://moonmailgateway2.spaceagency.int/inboundmail"

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

Transport Considerations As noted in , the transport of BSMTP email over HTTP on deep space links should be accomplished over QUIC with proper transport configuration, as specified in .

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

Unwanted Email Considerations 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.

IANA Considerations By this specification, the "bsmtp" service name, referring to BSMTP specification, is registered as a service name under RFC6335 policy.

Security Considerations TBD

References Normative References Informative References

Acknowledgements Initial discussions on this subject were with John Levine who helped a lot in ironing out many aspects and Pete Resnick.