Copyright Xerox Corporation 1979Inter-Office MemorandumToCommunication ProtocolsDateFebruary 11, 1979FromEd TaftLocationPARC/CSLSubjectPup Mail Transfer ProtocolFile[Maxc1]MailTransfer.bravo(Edition 6)XEROX The Mail Transfer Protocol (MTP) is a means by which messages may physically be transmittedbetween machines. Mail transfer involves two operations that cannot be characterized as ordinaryfile access operations (such as those available via FTP or Pine). These operations are the appendingof new messages to a user's mailbox and the retrieval of the mailbox contents for absorption into aLaurel mail file.The MTP, in conjunction with a file access protocol (FTP or Pine), is sufficient to support the Laurelmessage system. All facilities described in this document are now (or will shortly be) implementedby the Maxc and IFS mail servers. Note that this is the interim transport protocol; some of themechanisms defined within it are admittedly clumsy and inflexible. The distributed transportmechanism now under development will be substantially different.Changes to this edition: Recipient names may be qualified by .host to invoke forwarding; Senderproperty now mandatory.Overview of the ProtocolA mail transfer is an interaction between a user process desiring to append a message to or extractthe contents of a mailbox and a server process residing in the machine in which the mailbox islocated. The interaction is initiated by the user.The protocol is a variant of the File Transfer Protocol. The user establishes a BSP connection withthe server at a well-known socket. Commands and responses consist of a BSP Mark byte followed bysome data and terminating at the next Mark. Depending on the command, the data may consist ofa property list, a mail file being transferred, or explanatory text. In the third case, the text may bepreceded by a machine-readable code byte intended to facilitate mechanical processing of thecommand or response.The reader should consult the FTP specification (file FTPSpec.press) for complete informationon command/response sequences and property list syntax. The MTP, while using the FTPframework, assigns some additional command/response Mark types and property names. Therefore,MTP and FTP can coexist in any particular implementation.Mail DeliveryThis portion of the protocol is used to transport a message from user to server for one of twopurposes: delivery of the message to a mailbox residing in the server system, or forwarding of themessage to another server. Not all mail servers need implement forwarding, but those that do notare useful only to support self-contained user communities with a single central mail server.In general, a mailbox name is in the form SimpleName.Host, where Host is the name of the host on &pX]g~qi cr]pX-r5`p \r]p-r5`p Vr]p-r5`]Tp Osp Iprp6 GJ Ff3rp. Dtp@ C\tp @wrp-rp. >): =mrptp ;2+ :c@ 7~tp"tp 5 1lu .p,tp -tp8 +}3 (Prp '0rp %^ $ ^ "U  vt p3 =rpr pS rprp. u p3+  tp?t p U H tptptp >/d JPup Mail Transfer Protocol2which the mailbox is located and SimpleName is the name by which the mailbox is known on thathost. It is the user's responsibility to determine the host at which a mailbox resides. Experts willrecognize the similarity between this and the SimpleName.NamingAuthority scheme of the distributed transport mechanism.However, this similarity is syntactic only; the NamingAuthority is independent of mailbox location.A SimpleName unqualified by .Host, or qualified by .Host where Host is the name of the mailserver involved in the delivery transaction, implies a request to deliver a message to a mailboxlocated on the server machine. The server should immediately reject the request (by means of the[Mailbox-exception] mechanism described below) if no such mailbox actually exists.A SimpleName qualified by some other Host implies a request to forward a copy of the message tothe mail server at that Host. In this case (assuming Host is valid), the mail server should accept amessage for SimpleName.Host and, at the earliest convenient time, invoke a MTP user process todeliver the message to Host. It is intended that this forwarding operation be accomplished througha single hop, not multiple hops.A message to be forwarded to an Arpanet recipient is addressed to Name@ArpaHost.ArpaGateway, where ArpaGateway issimply an alias for Maxc1. From the viewpoint of the MTP, Name@ArpaHost is the SimpleName for a mailbox locatedat the host named ArpaGateway.Since in general the attempt to forward the message to Host takes place after the initial delivery ofthe message to this mail server, the forwarder must be prepared to cope with the possibility that therecipient name will be rejected by the ultimate Host or that the message will otherwise beundeliverable within a reasonable time. The MTP therefore requires that the message beaccompanied by a Sender property that may be used to direct a failure notification to the sender ofthe message.The mail delivery protocol is as follows:User: [Store-mail] ... [EOC]Server (optional): [Mailbox-exception] Server: [Yes] [EOC] or [No] [EOC]If the server said [Yes], thenUser: [Here-is-file] [Yes] [EOC]Server (optional): [Mailbox-exception] Server: [Yes] [EOC] or [No] [EOC]Each of the s in the [Store-mail] command designates a mailbox to which the messageis to be delivered. The use of multiple property lists, rather than a single property list containing multiple recipientnames, is an artifact of an earlier design of the protocol; it is no longer useful but is retained for compatibility reasons.The following properties are defined:(Mailbox name)Designates the desired recipient of the message. A Mailbox property is required ineach property list. In general, name should be in the complete formSimpleName.Host, but .Host may be omitted if the recipient's mailbox is located atthis mail server.(Sender name)Designates the name of the sender of the message, i.e., the name of the mailbox towhich notification should be sent if the message cannot be delivered. In general,name should be in the complete form SimpleName.Host, but .Host may be omittedif the sender's mailbox is located at this mail server (as it ordinarily will be for amessage delivered by Laurel).This property must appear once in one of the s. Current practice is thatthe Sender need not be authenticated or otherwise registered as a user of this mail server. The servershould require only that the Sender property be well-formed. fpXG b!t p$ `&2r _8.vr % ]0vr$ [:pt ptptptp YA X0D VR St ptp. RAtptp P tp-rp O7tpH M Jr3v r" Iv rv r Hv Eptp* D0R B0tp A&-rp ?=& > ;7)8RtpX3rp6tp*5Htprptprp3t2>p/rp0tp*/4tprptprp ,OC *ra )E} 'p%$tp! E qQ!tpRtptp1gtp<E tptptp?>r C[  <R ?/\'Pup Mail Transfer Protocol3The should conform to the default FTP text file format (i.e., Type Text, End-of-line-convention CR, though these parameters need not be specified in the ). Furthermore,the message should include an Arpanet-style message header (see RFC #733, "Standard for theformat of Arpa network text messages") to facilitate mechanical processing of the message. There aresome subtle problems involved in constructing addressee fields in a fashion that permits mechanical generation of replies.See the memo "Interim IFS Mail Forwarding", file [Maxc1]IFSForwarding.press, for details.The should not include a leading stamp; it is the server's responsibility to insert anyrequired message-separating information at the moment the message is actually appended to themailbox. Such information is specific to the server machine and is never sent over the network. On Maxc, the mailserver prefixes a standard Tenex-format message stamp for compatibility with existing programs that manipulate mailboxes.The server may respond [No] to the [Store-mail] request due to an error in the (e.g.,bad format or absence of any valid mailbox name). The server may respond [No] to the [Here-is-file] command due to failure to receive the correctly, implying that the message was notdelivered to any mailbox. Generally the server should buffer the message until it has been successfully received inits entirety before beginning to append it to mailboxes. This ensures that if the transfer fails in the middle no mailboxeswill have been damaged.The server may precede the [Yes] response to either [Store-mail] or [Here-is-file] with one or more[Mailbox-exception] replies that refer to specific mailboxes to which the server cannot deliver themessage for some reason. The parameters of this reply are:Optionally provides a machine-interpretable error code that may facilitate automatichandling of the error condition. The is an 8-bit byte analogous to [Yes] and[No] codes, though taken from a different space. Zero indicates an unspecifiederror.Identifies the affected property list in the user's [Store-mail] command. The firstproperty list is numbered 1, the second 2, and so on. Unlike the , the is expressed as a decimal number represented by Ascii digits, followed by aspace. This peculiar encoding is used, rather than a property list, for the convenience of existingTenex mail-sending software that does not presently have an FTP property-list parser.Provides a text string for human consumption. Inclusion of an informative messageis strongly encouraged.The server will typically generate [Mailbox-exception] replies in response to [Store-mail] formailboxes it cannot locate (or that do not reside on the server machine, if the server does notprovide forwarding). [Mailbox-exception] replies in response to [Here-is-file] should becomparatively rare; they indicate unexpected failure to deliver mail to known mailboxes. Thenumbering of mailbox property lists in the second case is unaffected by any previous [Mailbox-exception]s.Important: The server must not begin generating [Mailbox-exception]s until it has received the entire[Store-mail] argument list; otherwise a deadlock may result. This comment actually applies to the FTP as awhole: the user and server are expected to transmit alternately, never simultaneously.Mail RetrievalThis portion of the protocol is used to retrieve (send from server to user) the contents of a mailboxand then to reset the mailbox to empty. The two operations must be done atomically so as toprevent loss of new messages.The command/response sequence is as follows: fpXG b,rp ` rpI _3 rp ] Lr \.q Z^ X0ptp2 VD U&r47 S5D QpN OC M^ Lu tprB KF6 I Gp[ E): D ;A'>BJ <P;82963T2d=0N/Zr=-U+8p(S2& # ^ "d? WOX Z8!r j 8t pP  [EOC]Server: [No] [EOC] orServer: [Here-is-property-list] [Here-is-file] [Here-is-property-list] [Here-is-file] ...[Yes] [EOC] or [No] [EOC]If the server sent the file, thenUser: [Flush-mailbox] [EOC]Server: [Yes] [EOC] or [No] [EOC]The in the [Retrieve-mail] command must contain a Mailbox property identifying themailbox to be operated upon, plus any User-name, User-Password, etc., properties required to gainaccess to the mailbox.The preceding each message provides auxiliary information about the message thatmay be of use to the user. The properties include:(Length )Gives the length of the message in bytes. This property is required. It has beenincluded for the convenience of Laurel. Its usefulness is presently in some doubt, and generating it issomewhat inconvenient for the Maxc mail server because it requires two passes over the message.(Date-received )Gives the date and time at which the message actually arrived at the mailbox.(Opened Yes|No)Indicates whether or not the message has already been "opened", i.e., examinedwhile still residing in the mailbox. The default is No. This is relevant only for mailboxesstored on Maxc, since they may be examined by Msg.(Deleted Yes|No)Indicates whether or not the message has been "deleted" before being removedfrom the mailbox. Again, this is relevant only for mailboxes stored on Maxc.The contents of the mailbox are retrieved in the default FTP text format. Any server-specificinformation in the mailbox (such as separators or stamps) should be stripped off by the server. The[Here-is-property-list] and [Here-is-file] marks serve to delimit the individual messages.Note that the server must either prevent delivery of new messages to the mailbox during the intervalbetween receipt of the [Retrieve-mail] and [Flush-mailbox] commands, or else take measures toensure that [Flush-mailbox] deletes only those messages that were retrieved in response to [Retrieve-mail].Opcode AssignmentsThe well-known socket number for a mail server is 7.The following Mark types are assigned, in addition to the ones in the FTP specification (all numbersoctal):20[Store-mail]21[Retrieve-mail]22[Flush-mailbox]23[Mailbox-exception] fpXGbtp"rp`tprpt_pG]G\ ZprptprpYt!W{prpUtprptprp SI Q\ P M"3- K3HE2r DrSC5M@tp= ?:756@8r%422p/9D-r< *p)rp" )J13 'Z $[ #[Q !#B Q u p4 &rp u    >/[P$Pup Mail Transfer Protocol5Assigned [No] codes, in addition to the ones defined in the FTP specification, are:40No valid Mailbox in property list.41Illegal Mailbox property syntax.42Illegal Sender property.The following [No] codes are added to the FTP specification:107Transient, non-specific server or file-system failure.110Permanent, non-specifiec server or file-system failure.In general, all [No] codes except those in the range 40-43 and 110 signify transient rather thanpermanent failures, and the user should persist in attempting to deliver the mail (e.g., queue it forlater transmission).The following codes are defined for [Mailbox-exception] replies. Note that every [Mailbox-exception] reply indicates failure to deliver a message to the designated mailbox, regardless of thecode; the purpose of the code is to facilitate automatic diagnosis and handling of exceptionalconditions.0Unspecified failure.1Cannot locate Mailbox.2Mailbox not resident on server machine and no forwarding provided.3Cannot deliver to mailbox due to transient error condition.4Cannot deliver to mailbox due to permanent error condition.Related ProtocolsTwo mail-related protocols exist as part of the Miscellaneous Services collection. These are the MailCheck request, for determining quickly whether or not a mailbox contains new mail, and the UserAuthentication request, for determining the validity of a name/password combination. See theMiscellaneous Services specification for complete information. fpXG b" PvN N L H J] IA G} DCAB@ ;>; 9u 7p/7 5 Q 4U 2tp( 2<>/5 TIMESROMAN  TIMESROMAN  TIMESROMANLOGO TIMESROMAN  TIMESROMAN  TIMESROMAN k #R'j/*(kmailtransfer.bravoTaftSeptember 3, 1979 6:07 PM