📄 rfc780.txt
字号:
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 780Mail 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. SluizerRequest for Comments: 780 J. Postel ISIReplaces: RFC 772 May 1981 MAIL TRANSFER PROTOCOL1. 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 780Mail 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 780Mail 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 <SP> FROM:<sender-path> <SP> TO:<receiver-path> <CRLF> The <sender-path> contains the source mailbox; the <receiver-path> 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 <sender-path> and <receiver-path> are more than just the mailboxes, they may be source routes. The <receiver-path> is a source routing list of hosts and destination mailbox; the <sender-path> 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:<waldo@A> TO:<Foo@Y> <CRLF> R: 354 Start mail input; end with <CRLF>.<CRLF> S: Blah blah blah blah....etc. etc. etc. S: <CRLF>.<CRLF> 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 <user>@<host> 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 <receiver-path> 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 780Mail 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⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -