
Network Working Group                                       D. Bernstein
Request for Comments: NNNN                                            IR
Category: Experimental                                     20 March 1996


                Quick Mail Transfer Protocol (QMTP)


Status of this memo

   This memo defines an experimental protocol for the Internet
   community. This memo does not specify an Internet standard of any
   kind. Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.


1. Introduction

   The Quick Mail Transfer Protocol (QMTP) is a replacement for the
   Simple Mail Transfer Protocol (SMTP). QMTP eliminates any need for
   end-of-line scanning between hosts with the same end-of-line
   convention. It features automatic pipelining and chunking, 8-bit
   transmission, and prior declaration of the message size. It is
   designed to be very easy to implement.

   In this document, a string of 8-bit bytes may be written in two
   different forms: as a series of hexadecimal numbers between angle
   brackets, or as a sequence of ASCII characters between double quotes.
   For example, <68 65 6c 6c 6f 20 77 6f 72 6c 64 21> is a string of
   length 12; it is the same as the string "hello world!".


2. Protocol

   A QMTP client connects to a QMTP server, as discussed in section 5,
   over a reliable stream protocol allowing transmission of 8-bit bytes.

   Protocol outline: the client sends a mail message, an envelope sender
   address, and one or more envelope recipient addresses; the server
   sends back one response per envelope recipient.

   The client sends data to the server in the following order:

      an encoded mail message
      an encoded envelope sender address
      an encoded series of encoded envelope recipient addresses

   The mail message is discussed in section 3. The envelope sender
   address is a string of 8-bit bytes; it is encoded as a netstring, as
   discussed in section 4. Each envelope recipient address is a string
   of 8-bit bytes, encoded as a netstring; the series of encoded
   envelope recipient addresses is in turn encoded as a netstring.




Bernstein                                                       [Page 1]

RFC NNNN           Quick Mail Transfer Protocol               March 1996


   When the server sees the end of the client data, it sends a series
   of responses, one response for each envelope recipient address, in
   the same order as given by the client. The server is not permitted to
   change the order under any circumstances, even if two addresses are
   the same or an address is syntactically invalid.

   Each response is a nonempty string of 8-bit bytes, encoded as a
   netstring. The first byte of the string is one of the following:

      "K" The message has been accepted for delivery to this envelope
          recipient. This is morally equivalent to the 250 response to
          DATA in SMTP; it is subject to the reliability requirements
          of RFC 1123, section 5.3.3. Note that a server must not accept
	  a message if it cannot store the message without corruption.

      "Z" Temporary failure. The client should try again later.

      "D" Permanent failure.

   The remaining bytes should be between <20> and <7e> inclusive; the
   client is permitted to discard bytes outside this range. It is
   expected that these bytes will, when interpreted as ASCII characters,
   be a human-readable description of what happened. The description
   need not repeat the envelope recipient address. Descriptions
   beginning with <20>, and descriptions containing "#", are reserved
   for future extensions.

   The server is permitted to close the connection before sending its
   complete series of responses, or even before reading everything from
   the client. Any response not received in toto by the client must be
   treated as a temporary failure.

   The server is not permitted to send data until it reads everything
   from the client.

   The client is permitted to close the connection before sending a
   complete envelope. In this case the server must throw away the data
   received so far.

   The client is permitted to close the connection before reading
   everything from the server. The server must be prepared to handle
   this. Of course, it must not treat client failure as a reason to
   throw away a previously accepted message.

   A QMTP session should take at most 1 hour. Both sides are expected
   to close the connection after this time.








Bernstein                                                       [Page 2]

RFC NNNN           Quick Mail Transfer Protocol               March 1996


3. Mail messages

   A mail message is a sequence of lines; a line is a sequence of
   characters, i.e., nonnegative integers. A message can be transmitted
   over QMTP if (1) every character in the message fits into 8 bits and
   (2) none of the characters in the message are <0a>. There are no
   inherent line length or message size limits in QMTP.

   A mail message is encoded as a string of 8-bit bytes in one of two
   ways:

      Encoding #1 is <0a> followed by the native UNIX line encoding.
      Each character is unencoded; each line is terminated by <0a>.

      Encoding #2 is <0d> followed by the traditional RFC 822 line
      encoding. Each character is unencoded; each line is terminated by
      <0d 0a>.

   This string of 8-bit bytes is in turn encoded as a netstring, as
   discussed in section 5.

   Every server must be prepared to handle both encoding #1 and encoding
   #2, and if necessary to convert the incoming message to a new format.
   A server must not reject a message merely because of its encoding.

   Any sequence of bytes that begins and ends with <0a> is a valid
   message in encoding #1. The client is permitted to send a sequence of
   bytes that does not end with <0a>; if the server notices this, it
   should indicate permanent failure. Similarly, the client is permitted
   to send a sequence of bytes that is not a valid message in encoding
   #2; if the server notices this, it should indicate permanent failure.


4. Netstrings

   Any string of 8-bit bytes may be encoded as <len>":"<string>",".
   Here <string> is the string and <len> is a nonempty sequence of ASCII
   digits giving the length of <string> in decimal. The ASCII digits are
   <30> for 0, <31> for 1, and so on up through <39> for 9. Extra zeros
   at the front of <len> are prohibited: <len> begins with <30> exactly
   when <string> is empty.

   For example, the string "hello world!" is encoded as <31 32 3a 68
   65 6c 6c 6f 20 77 6f 72 6c 64 21 2c>, i.e., "12:hello world!,". The
   empty string is encoded as "0:,".

   <len>":"<string>"," is called a netstring. <string> is called the
   interpretation of the netstring.






Bernstein                                                       [Page 3]

RFC NNNN           Quick Mail Transfer Protocol               March 1996


5. Encapsulation

   QMTP may be used on top of TCP. A QMTP-over-TCP server listens for
   TCP connections on port 209.


6. Examples

   The following example should be compared with the example in RFC
   821, page 54.

      Client sends (in one TCP send operation):
         "15:JQP@MIT-AI.ARPA,22:18:Jones@BBN-VAX.ARPA,,"
         "238:" <0a>
         "Date: 2 Nov 81 22:33:44" <0a>
         "From: John Q. Public <JQP@MIT-AI.ARPA>" <0a>
         "Subject:  The Next Meeting of the Board" <0a>
         "To: Jones@BBN-Vax.ARPA" <0a>
         <0a>
         "Bill:" <0a>
         "The next meeting of the board of directors will be" <0a>
         "on Tuesday." <0a>
         "                                             John." <0a>
         ","
      Server sends:
         "3:" <4b> "OK,"

   The same example, with a DOS client instead of a UNIX client:

      Client sends:
         "15:JQP@MIT-AI.ARPA,22:18:Jones@BBN-VAX.ARPA,,"
         "247:" <0d>
         "Date: 2 Nov 81 22:33:44" <0d 0a>
         "From: John Q. Public <JQP@MIT-AI.ARPA>" <0d 0a>
         "Subject:  The Next Meeting of the Board" <0d 0a>
         "To: Jones@BBN-Vax.ARPA" <0d 0a>
         <0d 0a>
         "Bill:" <0d 0a>
         "The next meeting of the board of directors will be" <0d 0a>
         "on Tuesday." <0d 0a>
         "                                             John." <0d 0a>
         ","
      Server sends:
         "3:" <4b> "OK,"

   The server is indicating success, with a human-readable "OK".








Bernstein                                                       [Page 4]

RFC NNNN           Quick Mail Transfer Protocol               March 1996


7. Security considerations

   Security issues are not discussed in this memo.


Author's address

   D. J. Bernstein

   Email:  djb@pobox.com












































Bernstein                                                       [Page 5]

