rfc780.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,923 行 · 第 1/5 页
TXT
1,923 行
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 <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
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?