Luthienstar Networks Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== SMTP FOR USE OVER STANAG 5066 TRANSPORT (HMTP) ======

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.

===== Introduction =====

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 SMTP MODEL =====

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.

==== Example of the HMTP Procedure ====

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 SPECIFICATIONS =====

==== HMTP COMMANDS ====

=== COMMAND SEMANTICS ===

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

=== COMMAND SYNTAX ===

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>

=== SMTP REPLIES ===

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.

== REPLY CODES BY FUNCTION GROUPS ==

  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

==== TRANSPARENCY ====

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.