MAIL TRANSFER PROTOCOL Suzanne Sluizer and Jonathan B. Postel RFC 780 May 1981 Information Sciences Institute University of Southern California 4676 Admiralty Way Marina del Rey, California 90291 (213) 822-1511 May 1981 RFC 780 Mail Transfer Protocol TABLE OF CONTENTS 1. INTRODUCTION .................................................. 1 2. THE MTP MODEL ................................................. 2 3. BASIC MAIL .................................................... 4 3.1. Forwarding ............................................... 5 3.2. Source Routing ........................................... 6 4. MULTI-RECIPIENT MAIL .......................................... 8 4.1. Scheme Selection: MRSQ ................................... 8 4.2. Message Text Specification: MAIL ......................... 9 4.3. Recipient Specification: MRCP ........................... 10 4.4. Scheme Mechanics: Recipients First ...................... 10 4.5. Scheme Mechanics: Text First ............................ 12 4.6. Discussion .............................................. 12 5. SPECIFICATIONS ............................................... 16 5.1. MTP Commands ............................................ 16 5.1.1. Command Semantics ..................................... 16 5.1.2. Command Syntax ........................................ 18 5.2. MTP Replies ............................................. 22 5.2.1. Reply Codes by Function Group ......................... 23 5.2.2. Reply Codes in Numeric Order .......................... 24 5.3. Sequencing of Commands and Replies ...................... 25 5.4. State Diagrams .......................................... 28 5.5. Details ................................................. 30 5.5.1. Minimum Implementation ................................ 30 5.5.2. Transparency .......................................... 30 5.5.3. Sizes ................................................. 30 APPENDIX A: TCP ................................................. 32 APPENDIX B: NCP ................................................. 33 APPENDIX C: NITS ................................................ 34 APPENDIX D: X.25 ................................................ 35 APPENDIX E: Theory of Reply Codes ............................... 36 GLOSSARY ......................................................... 39 REFERENCES ....................................................... 42 Network Working Group S. Sluizer Request for Comments: 780 J. Postel ISI Replaces: RFC 772 May 1981 MAIL TRANSFER PROTOCOL 1. INTRODUCTION The objective of Mail Transfer Protocol (MTP) is to transfer mail reliably and efficiently. MTP is designed to be independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. Appendices describe the use of MTP with various transport services. A Glossary provides the definitions of terms as used in this document. An important feature of MTP is its capability to relay mail from one transport environment to another. A transport service provides an interprocess communication environment (IPCE). An IPCE may cover one network, several networks, or a subset of a network. A process can communicate directly with another process anywhere in its own IPCE. Mail is a special case of interprocess communication. Mail can be communicated between proceses in different IPCEs by relaying through a process connected to two (or more) IPCEs. More specifically, mail can be relayed between hosts on different transport systems by a host on both transport systems. It is important to realize that transport systems (or IPCEs) are not one-to-one with networks. Sluizer & Postel [Page 1] May 1981 RFC 780 Mail Transfer Protocol 2. THE MTP MODEL The MTP design is based on the following model of communication: at the initiation of the user, the sender-MTP establishes the full-duplex transmission channel. MTP commands are generated by the sender-MTP and sent to the receiver-MTP. MTP replies are sent from the receiver-MTP to the sender-MTP in response to the commands. In the simplest case, once the transmission channel is established the MTP-sender sends a MAIL command indicating the sender and receiver of the mail. If the MTP-receiver can accept the mail it responds with a go ahead reply. Then the MTP-sender sends the mail data, terminating with a special sequence. If the MTP-receiver successfully processes the mail it responds with an OK reply. ------------------------------------------------------------- +----------+ +----------+ +------+ | | | | | User |<-->| | MTP | | +------+ | Sender- |Commands/Replies| Receiver-| +------+ | MTP |<-------------->| MTP | +------+ | File |<-->| | and Mail | |<-->| File | |System| | | | | |System| +------+ +----------+ +----------+ +------+ Sender-MTP Receiver-MTP Model for MTP Use Figure 1 ------------------------------------------------------------- The MTP provides mechanisms for the transmission of mail; directly from the sending user's host to the receiving user's host when the two host are connected to the same transport service, or via one or more relay MTP-servers when the source and destination hosts are not connected to the same transport service. To be able to provide the relay capability the MTP-server must be supplied with the name of the ultimate destination host as well as the destination mailbox name. [Page 2] Sluizer & Postel RFC 780 May 1981 Mail Transfer Protocol The arguments to the MAIL command are a FROM path and a TO path. The TO path is a source route while the FROM path is a return route (which may be used to return a message to the sender when an error occurs with a relayed message). The preceding discussion has outlined the transmission of one copy of one message from a source to a destination host and the possibility of relaying messages between different transport services. The MTP additionally supports the transmission of one copy of a message addressed to multiple recipients. In order for mail to be successfully transmitted the destination users must be known at the destination receiver-MTP and the mail data must be correctly received and stored. In the single recipient case discussed above the positive response to the MAIL command indicated the recipient was known, and the final OK response indicated the mail was received and stored. To support multi-recipient mail, MTP provides two procedures: Text-First, and Recipients-First. In the text-first scheme the mail data is sent and acknowledged, then each recipient identification is sent and acknowledged (or refused) separately. In the recipients-first scheme the recipients are negotiated first, then the text is sent and acknowledged (for all recipients at once). The choice of scheme is up to the MTP-receiver, and depends on the way mail is handled in the destination host. The multi-recipient mail procedures are optional and the determination of which scheme to use is negotiated. The use of the multi-recipient schemes is strongly encouraged by the economy they provide in transmission and processing. The mail commands and replies have a rigid syntax. Replies also have a numeric code. In the following, examples appear which use actual commands and replies. The complete lists of commands and replies appears in Section 5 on specifications. Commands and replies are not case sensitive. That is, a command or reply word may be upper case, lower case, or any mixture of upper and lower case. Note that this is not true of mailbox user names. For some hosts the user name is case sensitive, and MTP implementations must take case to preserve the case of user names as they appear in mailbox arguments. Sluizer & Postel [Page 3] May 1981 RFC 780 Mail Transfer Protocol 3. BASIC MAIL The basic command for transmitting mail is MAIL. This command causes the transmitted data to be entered into the recipient's mailbox, or accepted for relaying to the destination host. The mail text is also sent on the transmission channel. This requires that the end of the text be signalled so that the command and reply dialog can be resumed. MTP signals the end of the mail text by sending a line containing only a period. A transparency procedure is used to prevent this interfering with the users text (see Section 5.5.2). MAIL FROM: TO: The contains the source mailbox; the contains the destination mailbox. If accepted, the receiver-MTP returns a 354 reply and considers all succeeding lines to be the message text. The message text is terminated by a line containing only a period, upon which a 250 completion reply is returned. Various errors are possible. Actually the and are more than just the mailboxes, they may be source routes. The is a source routing list of hosts and destination mailbox; the is a reverse source routing list of hosts and source mailbox. [Page 4] Sluizer & Postel RFC 780 May 1981 Mail Transfer Protocol ------------------------------------------------------------- Example of MAIL (Basic Mail) This MAIL command specifies the mail is sent by Waldo at host A, and is to be delivered to Foo at host Y. Here we assume that host A contacts host Y directly. S: MAIL FROM: TO: R: 354 Start mail input; end with . S: Blah blah blah blah....etc. etc. etc. S: . R: 250 Mail sent The mail text has now been sent to "Foo". Example 1 ------------------------------------------------------------- 3.1. FORWARDING There are two possible preliminary replies that a receiver may use to indicate that it is accepting mail for a user whose mailbox is not at that host. 151 User not local; will forward to @ This reply indicates that the receiver-MTP knows the user's mailbox is on another host and will take responsibility for forwarding the mail to that host. This reply is only sent when the sender would not expect the mail to be forwarded. That is, when as given in the command indicates mail relaying, this reply will not be used. This reply could be used for an organization with several hosts when each has a list of many of the users on the hosts. A host can accept mail for any user on its list and forward it to the correct host. 152 User Unknown; mail will be forwarded by the operator This reply indicates that the host does not recognize the user name, but that it will accept the mail and have the operator attempt to deliver it. This is useful if the user name is misspelled, but may be a disservice if the mail is really undeliverable. Sluizer & Postel [Page 5] May 1981 RFC 780 Mail Transfer Protocol If forwarding by the operator is unacceptable or if the sending-user would prefer to send the mail directly to the recipient's actual host, the action may be aborted. The MTP-sender must accept or reject the proposal in the preliminary reply by sending a continue (CONT) or abort (ABRT) command. In the case of the continue, the next reply from the MTP-receiver will be any of the replies expected for the MAIL command, most likely "354 Start mail input, ...". In the case of the abort, the next reply from the MTP-receiver will be "201 Command okay, action aborted". 3.2. SOURCE ROUTING The receiver-path may be a source route of the form "@ONE,@TWO,JOE@THREE", where ONE, TWO, and THREE are hosts. This form is used to emphasize the distinction between an address and a route. At some distant future time it might be necessary to expand the mailbox format to include a region identifier, such as "user@host@region". If this occured the MTP path convention could be expanded to "host@region,host@region,...user@host@region". For example, "ONE@R1,TWO@R2,JOE@THREE@R3". The mailbox is an absolute address, and the route is information about how to get there. The two concepts should not be confused. The elements of the receiver-path are to be moved to the sender-path as the message is relayed from one MTP to another. The sender-path is a reverse source route, that is, a source route to the originator of the message. When an MTP deletes its identifier from the receiver-path and inserts it into the sender-path, it must use the name it is known by in the environment it is sending into, not the environment the mail came from, in case the MTP is k