📄 rfc772.txt
字号:
Network Working Group S. Sluizer
Request for Comments: 772 J. Postel
ISI
September 1980
MAIL TRANSFER PROTOCOL
PREFACE
This is a first draft of this protocol and comments are very
definitely requested.
INTRODUCTION
The objective of Mail Transfer Protocol (MTP) is to transfer mail
reliably and efficiently.
This paper assumes knowledge of the following protocols described in
the ARPA Internet Protocol Handbook. The reader will note strong
similarities to portions of the File Transfer Protocol; in part, this
is due to the original ARPA Network implementation of computer mail
as a feature of FTP.
The ARPANET Host-to-Host Protocol [Network Control Protocol] (NCP)
The Transmission Control Protocol (TCP)
The TELNET Protocol (TELNET)
The File Transfer Protocol (FTP)
DISCUSSION
In this section, the terminology and the MTP model are discussed.
The terms defined in this section are only those that have special
significance in MTP. Some of the terminology is very specific to the
MTP model; some readers may wish to turn to the section on the MTP
model while reviewing the terminology.
TERMINOLOGY
ASCII
The ASCII character set as defined in the ARPA Internet
Protocol Handbook. In MTP, ASCII characters are defined to be
the lower half of an eight-bit code set (i.e., the most
significant bit is zero) and is called NVT-ASCII.
1
September 1980 RFC 772
Mail Transfer Protocol
control connection
The TCP full-duplex communication path or two NCP simplex
communication paths between a sender-MTP and a receiver-MTP for
the exchange of commands, replies, and mail text. The control
connection operates according to the TELNET Protocol.
data mode
The mail is transmitted over the control connection as a stream
of octets. (In FTP terminology this is called stream mode.)
data structure
The internal structure of mail is considered to be a continuous
sequence of data octets. (In FTP terminology this is called
file-structure.)
data representation
The internal representation of all data (i.e., mail) is in
NVT-ASCII.
host
A computer in the internetwork environment on which mailboxes
reside.
MTP commands
A set of commands which comprise the control information
flowing from the sender-MTP to the receiver-MTP.
mail
An ordered set of computer data of arbitrary length, which
conforms to the standard set in RFC 733 (Standard for the
Format of ARPA Network Text Messages).
mailbox
A character string (address) which identifies a user to whom
mail is to be sent. Mailbox normally consists of the host and
user specifications. The standard mailbox naming convention is
defined to be "user@host". Additionally, the "container" in
which mail is stored.
2
RFC 772 September 1980
Mail Transfer Protocol
NVT
The Network Virtual Terminal as defined in the TELNET Protocol.
octet
Bytes in MTP are octets (8 bits). This is not necessarily the
same byte size in which data is stored in a host.
reply
A reply is an acknowledgment (positive or negative) sent from
receiver to sender via the control connection in response to a
MTP command. The general form of a reply is a completion code
(including error codes) followed by a text string. The codes
are for use by programs and the text is usually intended for
human users.
receiver-MTP process
A process which transfers mail in cooperation with a sender-MTP
process. It "listens" on its port/socket L for a connection
from a sender-MTP and establishes a control connection using
the TELNET Protocol. It receives MTP commands from the
sender-MTP, sends replies, and governs the transfer of mail.
sender-MTP process
A process which transfers mail in cooperation with a
receiver-MTP process. A local language may be used in the user
interface command/reply dialogue. The sender-MTP initiates the
control connection from its port/socket U to the receiver-MTP
process. It initiates MTP commands, receives replies, and
governs the transfer of mail.
user
A human being (or a process on behalf of a human being) wishing
to obtain mail transfer service. In addition, a recipient of
computer mail.
3
September 1980 RFC 772
Mail Transfer Protocol
THE MTP MODEL
With the above definitions in mind, the following model (shown in
Figure 1) may be diagrammed for an MTP service.
------------ ------------
| | | | --------
| | MTP | |<-->| User |
| Receiver-|Commands/Replies| Sender- | --------
-------- | MTP |<-------------->| MTP | --------
| Mail |<-->| | Mail | |<-->| Mail |
|System| | | | | |System|
-------- ------------ ------------ --------
Receiver-MTP Sender-MTP
Model for MTP Use
Figure 1
In the model described in Figure 1, the sender-MTP initiates the
TCP/NCP control connection which follows the TELNET Protocol. At
the initiation of the user, standard MTP commands are generated by
the sender-MTP and transmitted to the receiver-MTP via the control
connection. Standard replies are sent from the receiver-MTP to
the sender-MTP over the control connection in response to the
commands. In addition, mail is sent over the control connection.
MAIL TRANSFER FUNCTIONS
The control connection is used for the transfer of commands which
describe the functions to be performed, the replies to commands, as
well as the actual transfer of mail. Mail is transferred only via
the control connection.
The communication channel from the sender-MTP to the receiver-MTP is
established by a TCP/NCP control connection from the sender to a
standard receiver port/socket. The sender-MTP is responsible for
sending MTP commands, interpreting the replies received, and sending
the mail; the receiver-MTP interprets commands, sends replies, and
receives the mail.
4
RFC 772 September 1980
Mail Transfer Protocol
MAIL REPRESENTATION AND STORAGE
Mail is transferred from a storage device in the sending host to a
storage device in the receiving host. It may be necessary to
perform certain transformations on the mail because data storage
representations in the two systems are different. For example,
NVT-ASCII has different data storage representations in different
systems. PDP-10's generally store NVT-ASCII as five 7-bit ASCII
characters, left-justified in a 36-bit word. 360's store
NVT-ASCII as four 8-bit EBCDIC codes in a 32-bit word. Multics
stores NVT-ASCII as four 9-bit characters in a 36-bit word.
For the sake of simplicity, all data must be represented in MTP as
NVT-ASCII. This means that characters must be converted into the
standard NVT-ASCII representation when transmitting text,
regardless of whether the sending and receiving hosts are
dissimilar. The sender converts the data from its internal
character representation to the standard 8-bit NVT-ASCII
representation (see the TELNET specification). The receiver
converts the data from the standard form to its own internal form.
In accordance with this standard, the <CRLF> sequence should be
used to denote the end of a line of text.
The mail in MTP has no internal structure and is considered to be
a continuous sequence of data octets.
ERROR RECOVERY AND RESTART
There is no provision for detecting bits lost or scrambled in data
transfer; this level of error control is handled by the TCP/NCP.
In addition, there is no restart procedure provided to protect
senders from gross system failures (including failures of a host,
an MTP-process, or the underlying network).
MTP COMMANDS
COMMAND SEMANTICS
The MTP commands define the mail transfer or the mail system
function requested by the user. The syntax of mailboxes must
conform to receiver site conventions (with standard defaults
applicable). In response to an MTP transfer command, the mail
shall always be transferred over the control connection.
The Mail Transfer Protocol follows the specifications of the
TELNET Protocol for all communications over the control
5
September 1980 RFC 772
Mail Transfer Protocol
connection. Although the language used for TELNET communication
can be a negotiated option, the "TELNET language" and the
corresponding "TELNET end of line code" are required to be
NVT-ASCII and <CRLF> respectively. No other specifications of the
TELNET Protocol will be cited.
MTP commands are NVT-ASCII strings terminated by <CRLF>. The
command codes themselves are alphabetic characters terminated by
the character <SP> (space) if parameters follow and <CRLF>
otherwise.
The MTP commands are discussed below. In the description of a few
of the commands in this section the possible replies are given
explicitly. MTP replies are discussed in the next section.
MAIL (MAIL)
This command allows a sender-MTP to send mail over the
control connection. The argument field contains a sender
and optional path sequence. If the path sequence is
present, it consists of an optional list of hosts and a
destination mailbox. When the list of hosts is present, it
is source routing information and indicates that the mail
must be forwarded to the first host on the list. Following
this command line the receiver treats all subsequent
characters as mail text from the sender. The mail text is
terminated by the character sequence "CRLF.CRLF".
As mail is forwarded along the path sequence, each
forwarding host must remove itself from the list. When mail
reaches its ultimate destination (the path sequence has only
a (possibly empty) destination mailbox), the receiver
inserts it into the destination mailbox in accordance with
its host mail conventions. If the second argument field is
blank (one or more spaces) or empty (<CRLF>), the mail is
destined for a printer or other designated place for site
general delivery mail. The mail may be marked as sent from
the sender as specified by the first argument field.
MAIL RECIPIENT SCHEME QUESTION (MRSQ)
This MTP command is used to select a scheme for the
transmission of mail to several users at the same host. The
schemes are to list the recipients first, or to send the
mail first.
6
RFC 772 September 1980
Mail Transfer Protocol
MAIL RECIPIENT (MRCP)
This command is used to identify the individual recipients
of the mail in the transmission of mail for multiple users
at one host.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -