This annex defines a set of primitives which support acknowledged transfer of SMTP email messages over a radio link using the HF subnet described in the mandatory part of this STANAG. This would be suitable, for example, to provide the HF communications service for an application-level gateway of email to HF radio.

Note: source routing will not be supported. Routing will be the responsibility of the HMTP server, which enjoys better access to shore directory services.

The objective of HF Mail Transfer Protocol (HMTP) is to transfer mail reliably and efficiently over an HF radio link using the system described in the mandatory part of this STANAG.

The HMTP is an adaptation of the SMTP, therefore the SMTP model is presented here. The SMTP design is based on the following model of communication: as the result of a user mail request, the SMTP client establishes a two-way transmission channel to an SMTP server. The SMTP server may be either the ultimate destination or an intermediate. SMTP commands are generated by the SMTP client and sent to the SMTP server. SMTP replies are sent from the SMTP server to the SMTP client in response to the commands.

In order to increase efficiency and reduce response time over low data rate channels, the HMTP combines certain steps which are separate in the SMTP. Once the transmission channel is established, the SMTP client sends a MAIL command indicating the sender of the mail. If the SMTP-server can accept mail it responds with an OK reply. The SMTP client then sends a RCPT command identifying a recipient of the mail. If the SMTP-server can accept mail for that recipient it responds with an OK reply; if not, it responds with a reply rejecting that recipient (but not the whole mail transaction). The SMTP client and SMTPserver may negotiate several recipients. When the recipients have been negotiated the SMTP client sends the mail data, terminating with a special sequence. If the SMTP-server successfully processes the mail data it responds with an OK reply. The SMTP dialog is purposely lock-step, one-at-a-time.

HMTP combines the MAIL, RCPT, and the mail data for multiple mail messages into a single transmission.

The HMTP server shall provide a relay capability for the client. The argument to the MAIL command is in the form “user@hostname”, which specifies who the mail is from. The argument to the RCPT command is in the same form and specifies the ultimate destination of the mail. The HMTP server shall forward mail. A destination will only be rejected if it cannot be understood by the server. Source routing shall not be used; the argument for the RCPT command shall be the ultimate destination of the mail.

This example shows mail sent by Smith at host Alpha, to Jones, Green, and Brown at different domains. Each individual message is terminated with a <CRLF>.<CRLF>, and the sequence with <CRLF>.<CRLF><CRLF>.<CRLF>.

C: MAIL MULTIPLE
C: MAIL FROM:<Smith@Alpha >
C: RCPT TO:<Jones@Beta>
C: RCPT TO:<Green@gamma>
C: RCPT TO:<Brown@delta>
C: DATA
C: Blah blah blah...
C: ...etc. etc. etc.
C: <CRLF>.<CRLF>
C: MAIL FROM: etc
C: …
C: <CRLF>.<CRLF><CRLF>.<CRLF>

S: 250 Source <Smith@Alpha> OK
S: 250 Destination <Jones@Beta.> OK
S: 550 Destination <Green@gamma> not known
S: 250 Destination <Brown@delta> OK
S: 250 DATA OK
S: etc

The mail has now been accepted for Jones and Brown.

The HMTP commands define the mail transfer or the mail system function requested by the user. HMTP commands are character strings terminated by <CRLF>. The command codes themselves are alphabetic characters terminated by <SP> if parameters follow and <CRLF> otherwise. The syntax of mailboxes must conform to server site conventions. The HMTP commands are discussed below. The HMTP replies are discussed in the Section 4.2.

A mail transaction involves several data objects which are communicated as arguments to different commands. The reverse-path is the argument of the MAIL command, the forwardpath is the argument of the RCPT command, and the mail data is the argument of theDATA command. These arguments or data objects must be transmitted and held pending the confirmation communicated by the end of mail data indication which finalizes the transaction. The model for this is that distinct buffers are provided to hold the types of data objects, that is, there is a reverse-path buffer, a forward-path buffer, and a mail data buffer. Specific commands cause information to be appended to a specific buffer, or cause one or more buffers to be cleared.

HELLO (HELO)

This command is used to identify the HMTP client to the HMTP server. The argument field contains the host name of the HMTP client.

The HMTP server identifies itself to the HMTP client in the connection greeting reply, and in the response to this command.

This command and an OK reply to it confirm that both the HMTP client and the HMTP server are in the initial state, that is, there is no transaction in progress and all state tables and buffers are cleared.

MAIL MULTIPLE

This command is used to advise the server that a sequence of more than one MAIL transaction will follow. The default, if this command is not sent, is a single MAIL transaction. MAIL (MAIL) This command is used to initiate a mail transaction in which the mail data is delivered to one or more mailboxes. The argument field contains a reverse-path. The reverse-path consists of an optional list of hosts and the sender mailbox. When the list of hosts is present is a “reverse” source route and indicates that the mail was relayed through each host on the list (the first host in the list was the most recent relay). This list is used as a source route to return non-delivery notices to the sender. As each relay host adds itself to the beginning of the list, it must use its name as known in the IPCE to which it is relaying the mail rather than the IPCE from which the mail came (if they are different). In some types of