A method for delivery of SMTP messages over Bundle Protocol networks.

3.1.1. Planet to Planet Use Case

This use case considers an email sent from Earth to Mars, for example. This requires, on Earth, an SMTP transaction between an MTA with a "gateway" MTA which interfaces with a BPA. This initial SMTP transaction can be secured by TLS, with authenticity and integrity provided by DMARC components SPF and DKIM. The initial SMTP transaction can be considered complete at this time, although it is RECOMMENDED that it return an autoreply to the sender indicating the potentially delayed final delivery and response. The gateway MTA should be configured to accept mail for *.mars. An MX record for *.mars should exist in the stub zone file for .mars in the Earth DNS. The MTA delivers the SMTP message to the BPA, possibly through an intermediary shim, for bundling and delivery to the node on the remote world responsible for BPA/MTA operations. The BPA (or shim) SHOULD implement Delay Tolerant Payload Conditioning (DTPC) to ensure in-order reassembly of fragmented mail application data. Upon receipt, the Mars BPA/MTA gateway parses the bundle payload and any associated extension blocks, and creates a new email delivered by SMTP to the Mars-local MX for the appropriate .mars domain, having found it's IPv6 address in the Mars DNS network. The new mail's transit of the Mars IP network can be secured by TLS.¶

The MTA/BPA interface can occur via a variety of methods, including the implementation of a "BP Transport" in the MTA to deeply integrate with the BPA API directly, or"shim" applications which exist between the MTA and the BPA for both sent and received mails, employing MTA "pipe" transport and BP enabled MUAs. An example implementation flowchart for a shim method can be found here. No matter the interface method for sending, the following SMTP header components, along with the body MUST be preserved during any parsing in preparation for bundle encoding: From, To, Subject, Content Type, Date and Message ID. This allows the construction of a new email once the bundle exits the BP network. If end-to-end integrity is required, the DMARC components, specifically the DNS DKIM TXT record lookup result for the sending domain (containing the public key for the DKIM signer) MAY be included in an extension block of the mail-carrying bundle. Upon receipt of such an extension block, the BPA interfacing application MUST publish a record in the local stub for the sending domain before the mail is sent to it's ultimate destination, such that the local recipient MTA can query the key as normal from local DNS resources. Such end to end integrity requires that the entire mail header and body MUST be retained intact to pass the remote integrity test, which significantly increases the network capacity used.¶

Alternatively, a segmented integrity approach requires much less network overhead, at the expense of trusting the MTA/BPA stack on the interplanetary email gateway. Practically, integrity is supplied by native protocols in each network segment with this approach; DKIM protects the originating and final remote delivery SMTP over IP transactions, while BPSEC BIB protects the mail data while in transit of the BP network. As regards the final delivery SMTP transaction using this segmented integrity technique, the DKIM signature and hence integrity originates at the gateway BPA/MTA. As a result, only those SMTP header and body components listed above need be included in the bundle.¶

3.2.1. Planet to Free Ranging Spacecraft Use Case

This use case considers an email sent from Earth to a mining craft in transit between the Moon and an asteroid to be mined, as an example. In this case, there is no reliable, accurate DNS service which the spacecraft can viably access, nor does it's have a top level domain designated for it's sole use. A TLD dedicated to general use for free ranging spacecraft is RECOMMENDED, to enable simpler routing of mail by disambiguated destination TLD; i.e. there is no doubt that a mail addressed to [email protected] is intended to be delivered to a free ranging spacecraft whose method of connectivity is via BP transit. Notwithstanding the previous sentence, this writing provides a solution in which the existence of such a TLD does not exist. The concepts presented remain the same in either case. The craft's MTA can be represented, however, in any world's DNS using the IPN RRTYPE to associate a Node Number with a domain. As the craft has no IP connectivity, A BPA/MTA is required on Earth to send/receive mail to/from the craft. This IP connected BPA/MTA can be accessed by IP based MUAs using a variety of existing methods. The BPA/MTA can also be configured by existing means to relay mail for specified domains, allowing wider reach of the ability to contact the craft, if desired. If a domain published in the Earth DNS has no A or AAAA and does have an IPN record, the sending BPA/MTA SHOULD process the Node Number in the IPN record for the domain as the destination of the email, and reflect it in the appropriate headers. The IP address of a suitable BPA/MTA SHOULD be published in an MX record for the (sub)domain representing the spacecraft. This allows correct interoperability with non-BP enabled terrestrial MTAs. Such free ranging craft SHOULD deploy a DNS root server with stub entries for all valid top level domains. Such stub zones in the craft's nameserver(s) SHOULD include wildcard entries in each tld's zone listing the node number of a BPA/MTA on the world on which they are deployed in an IPN record. Alternatively, a craft MAY employ a similar mechanism to that of /etc/hosts to record hostname to Node Number naming and provide local resolution source. The RECOMMENDED location for this local file is /etc/nodes, which BP enabled applications MAY query for node number to hostname indentification information.¶

In this fashion, a mail destined for spacecraft.foo.org (or foo.spacecraft) can be processed as follows: An MUA, or MTA from a domain for which the BPA/MTA will relay, makes an initial SMTP transaction with the BPA/MTA, which accepts the mail and queries the local DNS for an IPN entry for the destination hostname. A custom transport and router in the MTA can accomplish this function without modification to the MTA codebase by employing the pipe transport infrastructure to pass the mail to an external application for parsing and bundling, or these functions can be integrated into the MTA along with a deep integration with the BPA via it's API. The bundles produced can be properly directed to the correct EID for the spacecraft, using the queried Node Number component in this fashion. The former is predicated upon a well known Service Number component to the EID allocated for SMTP transit of BP networks. These bundles, upon receipt on the spacecraft, are parsed into emails, which are delivered locally on the spacecraft BPA/MTA host, to be accessed by the users by standard MUAs using existing means.¶

A mail originating from spacecraft.foo.org (or foo.spacecraft) destined for a user of bar.org, a terrestrial organization, can be processed in the following way: An MUA on the spacecraft makes an initial SMTP transaction with the BPA/MTA, which accepts the mail and queries the local DNS (or /etc/nodes) for an IPN entry for the destination hostname. The wildcard record in the local DNS stub for the destination hostname's TLD returns the Node Number of a BPA/MTA gateway on the world to which that TLD is native. The mail is parsed as in the IP-BP-IP use case, and bundled for delivery via the BP network to the terrestrial BPA/MTA gateway. Upon receipt, the terrestrial BPA/MTA parses the bundle, and delivers to the addresses domain, performing a normal lookup of it's IP address, and initiating a normal terrestrial SMTP transaction with the MTA of the addressed recipient.¶

3.3.1. Spacecraft to Spacecraft Use Case

This use case considers email communication between two free ranging spacecraft with no access to a DNS network communicating through fixed relays. In this case the spacecraft MUST have pre-knowledge of one another in the form of an /etc/nodes entry or an entry in the local nameserver's stub for the domain in question, and have occasional contact with other relay nodes to forward its bundles. Direct craft to craft communication via means of a neighbor discovery mechanism is beyond the scope of this writing. We presume the existance of an unroutable IP network deployed on the spacecraft, as in the previous use case. With the exception of node number discovery mechanism, this process is identical to the previous use case, in that the sending BPA/MTA performs a local query, and finding an IPN number associated with the destination hostname, addresses the bundles appropriately for delivery. The recieving BPA/MTA accepts these bundles, and delivers them to the local mail spool for the addressed user.¶