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 the DATA 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 error reporting messages (for example, undeliverable mail notifications) the reverse-path may be null (see Example 7).
This command clears the reverse-path buffer, the forward-path buffer, and the mail data buffer; and inserts the reverse-path information from this command into the reverse-path buffer.
RECIPIENT (RCPT)
This command is used to identify an individual recipient of the mail data; multiple recipients are specified by multiple use of this command.
The forward-path consists of a required destination mailbox. Source routing shall not be used.
When mail is relayed, the relay host must put itself at the beginning of the reverse-path. When mail reaches its ultimate destination, the HMTP server inserts it into the destination mailbox in accordance with its host mail conventions.
DATA (DATA)
The server treats the lines following the command as mail data from the sender. This command causes the mail data from this command to be appended to the mail data buffer. The mail data may contain any of the 128 ASCII character codes.
The mail data is terminated by a line containing only a period, that is the character sequence “<CRLF>.<CRLF>” (see Section 4.5.2 on Transparency). This is the end of mail data indication.
The end of mail data indication requires that the server must now process the stored mail transaction information. This processing consumes the information in the reverse-path buffer, the forward-path buffer, and the mail data buffer, and on the completion of this command these buffers are cleared. If the processing is successful the server must send an OK reply. If the processing fails completely the server must send a failure reply.
When the HMTP server accepts a message either for relaying or for final delivery it inserts at the beginning of the mail data a time stamp line. The time stamp line indicates the identity of the host that sent the message, and the identity of the host that received the message (and is inserting this time stamp), and the date and time the message was received. Relayed messages will have multiple time stamp lines.
When the HMTP server makes the “final delivery” of a message it inserts at the beginning of the mail data a return path line. The return path line preserves the information in the <reverse-path> from the MAIL command. Here, final delivery means the message leaves the HMTP world. Normally, this would mean it has been delivered to the destination user, but in some cases it may be further processed and transmitted by another mail system.
It is possible for the mailbox in the return path be different from the actual sender's mailbox, for example, if error responses are to be delivered a special error handling mailbox rather than the message senders.
The preceding two paragraphs imply that the final mail data will begin with a return path line, followed by one or more time stamp lines. These lines will be followed by the mail data header and body [2]. See Example 8.
Special mention is needed of the response and further action required when the processing following the end of mail data indication is partially successful. This could arise if after accepting several recipients and the mail data, the HMTP server finds that the mail data can be successfully delivered to some of the recipients, but it cannot be to others (for example, due to mailbox space allocation problems). In such a situation, the response to the DATA command must be an OK reply. But, the HMTP server must compose and send an “undeliverable mail” notification message to the originator of the message. Either a single notification which lists all of the recipients that failed to get the message, or separate notification messages must be sent for each failed recipient (see Example 7). All undeliverable mail notification messages are sent using the MAIL command (even if they result from processing a SEND, SOML, or SAML command).
RESET (RSET)
This command specifies that the current mail transaction is to be aborted. Any stored sender, recipients, and mail data must be discarded, and all buffers and state tables cleared. The server must send an OK reply.
QUIT (QUIT)
This command specifies that the server must send an OK reply, and then close the transmission channel.
The server should not close the transmission channel until it receives and replies to a QUIT command (even if there was an error). The client should not close the transmission channel until it send a QUIT command and receives the reply (even if there was an error response to a previous command). If the connection is closed prematurely the server should act as if a RSET command had been received (canceling any pending transaction, but not undoing any previously completed transaction), the client should act as if the command or transaction in progress had received a temporary error (4xx).
The commands consist of a command code followed by an argument field. Command codes are four alphabetic characters. Upper and lower case alphabetic characters are to be treated identically. Thus, any of the following may represent the mail command:
MAIL Mail mail MaIl mAIl
This also applies to any symbols representing parameter values, such as “TO” or “to” for the forward-path. Command codes and the argument fields are separated by one or more spaces.
However, within the reverse-path and destination arguments case is important. In particular, in some hosts the user “smith” is different from the user “Smith”.
The argument field consists of a variable length character string ending with the character sequence <CRLF>. The receiver is to take no action until this sequence is received.
Square brackets denote an optional argument field. If the option is not taken, the appropriate default is implied.
The following are the HMTP commands:
HELO HMTP <SP> <domain> <CRLF> MAIL MULTIPLE MAIL <SP> FROM:<reverse-path> <CRLF> RCPT <SP> TO:<destination> <CRLF> DATA <CRLF> RSET <CRLF> QUIT <CRLF>
Replies to HMTP commands are devised to ensure the synchronization of requests and actions in the process of mail transfer, and to guarantee that the HMTP client always knows the state of the HMTP server. Every command must generate exactly one reply.
An HMTP reply consists of a three digit number (transmitted as three alphanumeric characters) followed by some text. The number is intended for use by automata to determine what state to enter next; the text is meant for the human user. It is intended that the three digits contain enough encoded information that the HMTP client need not examine the text and may either discard it or pass it on to the user, as appropriate. In particular, the text may be server-dependent and context dependent, so there are likely to be varying texts for each reply code. A discussion of the theory of reply codes can be found in Appendix E to RFC 822. Formally, a reply is defined to be the sequence: a three-digit code, <SP>, one line of text, and <CRLF>. In general, replies in HMTP will be multiline replies.
500 Syntax error, command unrecognized [This may include errors such as command line too long] 501 Syntax error in parameters or arguments 502 Command not implemented 503 Bad sequence of commands 504 Command parameter not implemented 220 <domain> HMTP Service ready 221 <domain> Service closing transmission channel 421 <domain> Service not available, closing transmission channel [This may be a reply to any command if the service knows it must shut down] 250 Requested mail action okay, completed 450 Requested mail action not taken: mailbox unavailable [E.g., mailbox busy] 550 Requested action not taken: mailbox unavailable [E.g., mailbox not found, no access] 451 Requested action aborted: error in processing 452 Requested action not taken: insufficient system storage 552 Requested mail action aborted: exceeded storage allocation 553 Requested action not taken: mailbox name not allowed [E.g., mailbox syntax incorrect] 354 Start mail input; end with <CRLF>.<CRLF> 554 Transaction failed
Without some provision for data transparency the character sequence “<CRLF>.<CRLF>” ends the mail text and cannot be sent by the user. In general, users are not aware of such “forbidden” sequences. To allow all user composed text to be transmitted transparently the following procedures are used.
1. Before sending a line of mail text the sender-HMTP checks the first character of the line. If it is a period, one additional period is inserted at the beginning of the line.
2. When a line of mail text is received by the receiver-HMTP it checks the line. If the line is composed of a single period it is the end of mail. If the first character is a period and there are other characters on the line, the first character is deleted.
The mail data may contain any of the 128 ASCII characters. All characters are to be delivered to the recipient's mailbox including format effectors and other control characters. If the transmission channel provides an 8-bit byte (octets) data stream, the 7-bit ASCII codes are transmitted right justified in the octets with the high order bits cleared to zero.
In some systems it may be necessary to transform the data as it is received and stored. This may be necessary for hosts that use a different character set than ASCII as their local character set, or that store data in records rather than strings. If such transforms are necessary, they must be reversible – especially if such transforms are applied to mail being relayed.