!****************************************************************************
!*									    *
!*  COPYRIGHT (c) 1978, 1980, 1982, 1984 BY				    *
!*  DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASSACHUSETTS.		    *
!*  ALL RIGHTS RESERVED.						    *
!* 									    *
!*  THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIED   *
!*  ONLY IN  ACCORDANCE WITH  THE  TERMS  OF  SUCH  LICENSE  AND WITH THE   *
!*  INCLUSION OF THE ABOVE COPYRIGHT NOTICE. THIS SOFTWARE OR  ANY  OTHER   *
!*  COPIES THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY   *
!*  OTHER PERSON.  NO TITLE TO AND OWNERSHIP OF  THE  SOFTWARE IS  HEREBY   *
!*  TRANSFERRED.							    *
!* 									    *
!*  THE INFORMATION IN THIS SOFTWARE IS  SUBJECT TO CHANGE WITHOUT NOTICE   *
!*  AND  SHOULD  NOT  BE  CONSTRUED AS  A COMMITMENT BY DIGITAL EQUIPMENT   *
!*  CORPORATION.							    *
!* 									    *
!*  DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE  OR  RELIABILITY OF ITS   *
!*  SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL.		    *
!* 									    *
!*									    *
!****************************************************************************

	    MAIL-11 Network Protocol
		  18-Jul-1983

Below is a brief, graphic description of the MAIL-11 network protocol.
It shows the order and direction of the various messages exchanged
between the Master MAIL (the sending MAIL) and the Slave MAIL (the
receiving MAIL).  The numbering on the left hand side refers to
the descriptive text sections that follow.

	Master MAIL		Direction	Slave MAIL
	-----------		---------	----------

1)	Connect initiate	 ------>

2)				 <------	Connect confirm

3)	Sender's name		 ------>

4)	Addressee #1		 ------>

5)				 <------	Success/fail message(s) for
						addressee #1 legality

				    :
				    :
				    :

	Addressee #n		 ------>

				 <------	Success/fail message(s) for
						addressee #n legality

6)	End-of-addressees	 ------>

7)	TO: line		 ------>

8)	CC: line		 ------>

9)	SUBJ: line		 ------>

10)	Message record #1	 ------>
				    :
				    :
				    :
	Message record #n	 ------>

11)	End-of-message		 ------>

12)				 <------	Success/fail message(s) for
						addressee #1 reception
				    :
				    :
				    :
				 <------	Success/fail message(s) for
						addressee #n reception

13)	Disconnect		 ------>

14)				 <------	Disconnect

1) Connection initiated by Master MAIL.

    The Master (sending) MAIL initiates the connection to the Slave
    (receiving) MAIL.  The MAIL-11 DECnet object type number is 27.
    The Master MAIL uses the DECnet optional connect initiate data
    to pass configuration data to the Slave MAIL.  This configuration
    data includes the MAIL-11 protocol version in use, the Master's
    operating system type, how the Master wishes to send the message,
    what options the Master desires, and, if a block mode send is
    requested, a description of the message file.

2) Connection accepted by Slave MAIL.

    The Slave (receiving) MAIL accepts the connection using the DECnet
    optional connect accept data to pass configuration data back to the
    Master (sending) MAIL.  This configuration data includes the MAIL-11
    protocol in use, the Slave's operating system type, how the Slave
    will receive the message, what options the Slave desires, and, if
    a block mode send is accepted, how many block are sent in each message
    record.

The exchange of configuration data allows the Master (sending) and Slave
(receiving) MAILs to correctly mail the message.  The original MAIL-11
network protocol (I'll call it V0.0) did not exchange configuration data.
Therefore, a Slave MAIL should assume that the Master MAIL will use
protocol V0.0 if no (or illegal) configuration data appears in the connect
initiate.  Also, if a Slave MAIL doesn't understand the protocol version
being specified in the configuration data, it should also revert to
protocol V0.0.  The Slave MAIL reverts to protocol V0.0 by accepting the
connection without supplying any configuration data.  In the same vein,
if a Master MAIL gets a connection acceptance that doesn't have any
configuration data (or has illegal or non-understandable configuration
data) then it should revert to V0.0 of the protocol.

The following versions of the protocol have been defined at one time
or another:

    V0.0	Original "versionless" protocol, implemented by:
		    VAXmail through VAX/VMS V3.x
		    and many others...
    V2.1	Initial try at a "versioned" protocol, implemented by:
		    DECmail/RSTS V1.0
    V3.0	The protocol described in this document, implemented by:
		    VMSmail in VAX/VMS V4.0
		    DECmail/RSTS V2.0

Configuration data general format:

	Byte	Format			Meaning

	 1	Value, byte, unsigned	MAIL-11 Protocol Version
	 2	Value, byte, unsigned	MAIL-11 Protocol ECO Level
	 3	Value, byte, unsigned	MAIL-11 Procotol Customer ECO Level
	 4	Value, byte, unsigned	Operating System Type
	5-8	Bitmask, longword	Options
	9-12	Bitmask, longword	Message Protocol Modes
	 13	Value, byte, unsigned	Message Record Format
	 14	Bitmask, byte		Message Record Attributes
	 15				***RESERVED***
	 16				***RESERVED***

MAIL-11 Protocol Version (byte #1)
    The value of three (3).  This is MAIL-11 Protocol Version 3.

MAIL-11 Protocol ECO Level (byte #2)
    The value of zero (0).  This is MAIL-11 Protocol ECO Level 0.

MAIL-11 Protocol Customer ECO Level (byte #3)
    The value of zero (0).  This is MAIL-11 Protocol Customer ECO
    Level 0.

Operating System Type (byte #4)
    The value from the standard DECnet list corresponding to the
    operating system.  RSTS/E has a value of two (2); VAX/VMS has
    a value of seven (7).

Options (bytes #5 through #8)
    Bit	Meaning
     0	"Receiving user has been notified" messages should be sent back
	 to Master MAIL as part of the success message, if possible.
	 Valid ONLY for the Master (sending) MAIL.
    1-31 ***RESERVED***

Message Protocol Modes (bytes #9 through #12)
    Bit	Meaning
     0	Master MAIL wishes to send the message in blocks; the
	 Message Record Format and Message Record Attributes
	 bytes describe the format of the to be received message
	 (normally, the message is sent one line at a time).
	 Valid ONLY for the Master (sending) MAIL.
     1	Slave MAIL is willing to accept the message as described
	 by the Master in blocks; the largest number of blocks that
	 can be sent as a single message record is contained in
	 the "Message Record Format" byte.
	 Valid ONLY for the Slave (receiving) MAIL.
     2	Master MAIL wishes to prefix the sender's name with the
	 sender's node name himself (normally, Slave MAIL would do it).
	 Valid ONLY for the Master (sending) MAIL.
     3	Slave MAIL is willing to accept the sender's name already
	 prefixed with the sender's node name; he won't do it.
	 Valid ONLY for the Slave (receiving) MAIL.
     4	Master MAIL wishes to send a CC: line (normally, no CC: line
	 is sent).
	 Valid ONLY for the Master (sending) MAIL.
     5	Slave MAIL is willing to accept a CC: line at the proper place
	 in the protocol.
	 Valid ONLY for the Slave (receiving) MAIL.
    6-31 ***RESERVED***

    Please note that the even bits (0, 2, 4) are ONLY for Master MAIL
    and the odd bits (1, 3, 5) are ONLY for Slave MAIL.  Each Master
    MAIL even bit is paired with the next higher Slave MAIL odd bit.
    Each Master MAIL bit represents some request the Master MAIL is
    making of the Slave MAIL; each Slave MAIL bit represents the Slave
    MAIL's response to that request.

    Bits <0> and <1> control message record transmission (see #10).
    Bits <2> and <3> control the sender's name transmission (see #3).
    Bits <4> and <5> control the CC: line transmission (see #8).

Message Record Format (byte #13)
    Record Format of the message the Master MAIL wishes to send in blocks.
    This value is one of the standard RMS RFM values.
    Valid ONLY for the Master (sending) MAIL and ONLY if bit <0> of the
    Message Protocol Modes is true, but, then, it's required.

    The Slave MAIL uses this byte to return to the Master MAIL the largest
    number of blocks that can be sent in a single message record.
    Valid ONLY for the Slave (receiving) MAIL and ONLY if bit <1> of the
    Message Protocol Modes is true, but, then, it's required.

Message Record Attributes (byte #14)
    Record Attributes of the message the Master MAIL wishes to send in blocks.
    This is the standard RMS RAT field.
    Valid ONLY for the Master (sending) MAIL and ONLY if bit <0> of the
    Message Protocol Modes is true, but, then, it's required.

***RESERVED*** (bytes #15 and #16)

You'll note that the data is different for the Master (sending) and Slave
(receiving) MAILs.  This is done ON PURPOSE.  If the Slave (receiving) MAIL
should simply "reflect" the Master (sending) MAIL's configuration data then
the Master (sending) MAIL can detect that fact and assume that the Slave
(receiving) MAIL is not correctly using the MAIL-11 protocol.

3) Sender's name sent to Slave MAIL.

    The sender's name is sent to Slave MAIL as DEC Multinational text
    without any trailing carriage control.  It is normally the Slave MAIL's
    responsibility to prefix the sender's name with the sender's node name.
    But, if the Master requested that he do it (Message Protocol Modes
    bit <2>) and the Slave agreed (Message Protocol Modes bit <3>) then
    the sender's name is accepted by the Slave as is.

4) Addressee sent to Slave MAIL.

    An addressee name is sent to Slave MAIL as DEC Multinational text
    without any trailing carriage control.  The Slave MAIL must parse the
    addressee name, applying any logical name transforms, etc.  If the
    resultant addressee name needs to be routed to another node then the
    Slave MAIL does so, reapplying the MAIL-11 protocol to its Slave...

    To avoid confusion, no addressee name can be of length = 1, value
    = 0 (that's an EOF message).  This should be no problem...

5) Slave MAIL confirms/rejects addressee.

    The Slave MAIL confirms/rejects the addressee name sent to it by
    the Master MAIL using the success/fail message protocol.  See a
    later section for a description of the success/fail message protocol.

6) End of addressees sent to Slave MAIL.

    After the Master MAIL has sent all addressee names to Slave MAIL
    (iterating over steps #4 and #5 above), it sends an EOF message
    to indicate the end of addressees.  An EOF message is a message
    of length one (1) whose contents is a byte of zero (0).

7) TO: line sent to Slave MAIL.

    The TO: line is sent to Slave MAIL as DEC Multinational text without
    any trailing carriage control.

8) CC: line sent to Slave MAIL.

    If the Master requested that he send a CC: line (Message Protocol
    Modes bit <4>) and the Slave agreed (Message Protocol Modes bit <5>)
    then the CC: line is sent to Slave MAIL as DEC Multinational text
    without any trailing carriage control.

9) SUBJ: line sent to Slave MAIL.

    The SUBJ: line is sent to Slave MAIL as DEC Multinational text without
    any trailing carriage control.

10) Message records sent to Slave MAIL.

    If the Master requested block mode transmission of the message
    (Message Protocol Modes bit <0>) and the Slave agreed (Message
    Protocol Modes bit <1>) then the Master sends the message file
    in records that are blocks (512 bytes) or multiples of blocks.
    The Master MAIL can always send the file in single block (512
    byte) records.  It can use multiple block records up to the
    maximum number returned by the Slave MAIL in the "Message Record
    Format" byte.  If multiple block records are sent, they need
    not all be of the same length.  Specifically, the final record
    will have to be whatever is correct for the message file's
    actual length.

    Elsewise, the Master MAIL sends the message one line at a time
    as DEC Multinational text without any trailing carriage control.

    To avoid confusion, no text record can be of length = 1, value
    = 0 (that's an EOF message).  Such records should be arbitrarily
    changed to something else (like a zero length record) by the
    Master MAIL.

    If the Slave MAIL should receive a text record that ends with
    RETURN/LINEFEED (octal 015/octal 012) then it should arbitrarily
    strip the RETURN/LINEFEED from the received record.  This can
    happen when the Master MAIL blindly sends a message as records
    from an embedded carriage control file (e.g., a RUNOFF file).

    A Slave MAIL receiving a message in block mode should probably
    guard against this too...

11) End of message sent to Slave MAIL.

    After the Master MAIL has sent all of the message to Slave MAIL
    (step #10 above), it sends an EOF message to indicate the end of
    the message.  An EOF message is a message of length one (1) whose
    contents is a byte of zero (0).

12) Slave MAIL indicates success/failure of message delivery.

    The Slave MAIL indicates the success or failure of message delivery
    for each confirmed addressee using the success/fail message protocol.
    See a later section for a description of the success/fail message
    protocol.

13) Master MAIL breaks the connection.

    The Master MAIL breaks the connection first; if the Slave MAIL
    did then it's possible for the connection to be broken before
    all of the message delivery success/fail message(s) have arrived
    at the Master.

14) Slave MAIL breaks the connection.

    The Slave MAIL breaks the connection when it notices that the
    Master has done so.

Success/fail message protocol for success:

	Master MAIL		Direction	Slave MAIL
	-----------		---------	----------

				 <------	4 byte status:
						  low bit set = success
						Success text record

    A success message is used for confirming an addressee or for
    confirming successful delivery of a message to a confirmed addressee.

    The only requirement on the 4 byte status is that the lowest order
    bit (bit <0> of the first byte) be true.  But, by convention,
    the 4 byte status is either a longword of 1 or a longword that
    is a VAX condition code with a severity field of success (1).

    If the Master (sending) MAIL requested "user notified" messages
    (Options bit <0>) then the Slave (receiving) MAIL may append
    a "user notified" text record to the 4 byte status.  This "user
    notified" text record is DEC Multinational text without any
    trailing carriage control.  The Master MAIL assumes any data beyond
    the 4 byte status is a "user notified" text record.  "User
    notified" text records are usually used during the confirmation
    of delivery of a message.  But, they could be used at addressee
    confirmation time to announce special conditions, e.g., "Message
    for xxxxx being forwarded to node yyyyy".

Success/fail message protocol for failure:

	Master MAIL		Direction	Slave MAIL
	-----------		---------	----------

				 <------	4 byte status:
						  low bit clear = failure

				 <------	Failure text record #1
				    :
				    :
				    :
				 <------	Failure text record #n

				 <------	End-of-failure-text

    A failure message is used for rejecting an addressee or for
    saying delivery of a message to a confirmed addressee erred.

    The only requirement on the 4 byte status is that the lowest order
    bit (bit <0> of the first byte) be false.  But, by convention,
    the 4 byte status is either a longword of 2 or a longword that
    is a VAX condition code with a severity field of error (2).

    The failue text records are DEC Multinational text without any
    trailing carriage control.

    To avoid confusion, no failure text record can be of length = 1, value
    = 0 (that's an EOF message).  This should be no problem...

    The end of failure text records is an EOF message.  An EOF message
    is a message of length one (1) whose contents is a byte of zero (0).
