📄 rfc753.txt
字号:
Reasons
These could be mailbox does not exist, mailbox full, etc.
LIST ( TEXT )
Stamp
Each MPM that handles the message must add a unique identifier
(ihn, see above) to the list. This will prevent messages from
being sent back and forth through the internet mail system without
eventually either being delivered or returned to the sender.
LIST ( ihn, ihn, ... )
Trail
When a message is sent through the internetwork environment, it
acquires a list of MPMs that have handled the message in "Stamp".
This list is then carried as "Trail" upon reply or acknowledgment
of that message. More simply, requests and replies always have a
"Stamp" and each MPM adds its ihn to this "Stamp." Replies, in
addition, have a "Trail" which is the complete "Stamp" of the
original message.
LIST ( ihn, ihn, ... )
Type
The command type, e.g., request or reply.
INDEX
Document
In this section, we define some objects useful in message document
headers. The ones we use are taken from the current ARPANET message
syntax standard [6,8].
CC
When copies of a message are sent to others in addition to the
addresses in the To object, those to whom the copies are sent will
have their addresses recorded here. CC will be a single TEXT
element.
TEXT
[Page 20] Postel
March 1979
Internet Message Protocol
Specification
Date
The date and time are represented according to the International
Standards Organization (ISO) recommendations [13,14,15]. Taken
together the ISO recommendations 2014, 3307, and 4031 result in
the following representation of the date and time:
yyyy-mm-dd-hh:mm:ss,fff+hh:mm
Where yyyy is the 4 digit year, mm is the two digit month, dd is
the two digit day, hh is the two digit hour in 24 hour time, mm is
the two digit minute, ss is the two digit second, and fff is the
decimal fraction of the second. To this basic date and time is
appended the offset from Greenwich as plus or minus hh hours and
mm minutes.
TEXT
Document-Body
The document body will contain that portion of the message
commonly thought of as the text portion. It will be composed of a
list of elements. This will allow transmission of data other than
pure text if such capabilities are needed. We can, for instance,
envision digital voice communication through the transmission of
BITSTR element, or transmission of graphic data, etc. Information
regarding control of such features could be included in the header
for cooperating sites, or in the body itself but such protocols
would depend upon agreement among those sites involved. It is
expected of course that the majority of messages will contain body
portions comprised of TEXT elements.
LIST ( --- )
Document-Header
The document header contains the memo header presented to the
user. In principle this may be of any style or structure. In
this specification it is recommended that a PROPLIST be used and
that the name-value pairs correspond to the header fields of
RFC 733 [6].
PROPLIST ( --- )
Postel [Page 21]
March 1979
Internet Message Protocol
Specification
From
The From is meant to be the name of the author of a document. It
will be one TEXT element.
TEXT
Reply-To
Sometimes it will be desired to direct the replies of a message to
some address other than the From or the Sender. In such a case
the Reply-To object can be used.
TEXT
Sender
The Sender will contain the address of the individual who sent the
message. In some cases this is NOT the same as the author of the
message. Under such a condition, the author should be specified in
the From object. The Sender is a single TEXT element.
TEXT
Subject
The subject of the message.
TEXT
To
To identifies the addressees of the message. The To object is one
TEXT element.
TEXT
[Page 22] Postel
March 1979
Internet Message Protocol
Specification
3.4. Command
This section describes the commands which processes in the internet
message system can use to communicate. Several aspects of the command
structure are based on the NSW Transaction Protocol [19]. The
commands come in pairs, with each request having a corresponding
reply.
A command is a list:
LIST ( mailbox, stamp, type, operation, arguments, error-list )
The arguments are described generally here and more specifically, if
necessary, in the description of each command.
mailbox: PROPLIST
This is the "to" specification of the message. Mailbox takes the
form of a property list of general information, some of which is
the essential information for delivery, and some of which could be
extra information which may be helpful for delivery. Mailbox is
different from address in that address is a very specific list
without extra information.
stamp: LIST ( INTEGER, ... )
This is a list of the MPMs that have handled the message. Each
MPM must add its 32 bit Internet Host Number (ihn) to the LIST.
type: INDEX
type=1 a REQUEST operation.
type=2 a REPLY operation.
type=3 an ALARM operation. (A high priority message.)
type=4 a RESPONSE to an alarm operation.
operation: TEXT
Operation is the name of the operation or procedure to be
performed. This string must be interpreted in an upper/lower case
independent manner.
Postel [Page 23]
March 1979
Internet Message Protocol
Specification
arguments: LIST
This is a list of arguments to the above operation.
error-list: LIST
If message is type 1 or 3 (a request or an alarm):
LIST ( ) (a zero length list)
If message is a type 2 or 4 (a response or response to alarm)
LIST ( error-class, error-string ) indicates what,if any, error
occured
error-class: INDEX
=0: indicates success, no error
=1: partial results returned.
This error class is used when several steps are performed by
one operation and some of them fail.
=2: failure, resources unavailable.
=3: failure, user error.
=4: failure, MPM error. Recoverable.
=5: failure, MPM error. Fatal.
=6: User abort requested
error-string: TEXT
This is a human readable character string describing the error.
Possible errors:
error-string error-class
No errors 0
Command not implemented 2
Syntax error, command unrecognized 3
Syntax error, in arguments 3
Server error, try again later 4
No service available 5
User requested abort 6
[Page 24] Postel
March 1979
Internet Message Protocol
Specification
command: DELIVER
type: 1
function: Sends message to a mailbox
reply: The reply is ACKNOWLEDGE
arguments: LIST ( options )
options: one or more of the following
"REGULAR" regular delivery
"FORWARD" message forwarding
"GENDEL" general delivery
other options which may be defined later
argument structure:
LIST ( LIST ( TEXT, ... ))
Postel [Page 25]
March 1979
Internet Message Protocol
Specification
command: ACKNOWLEDGE
type: 2
function: reply to DELIVER
arguments: LIST ( tid, trail, answer, reasons, how-delivered )
tid: tid of the originating message
trail: the stamp from the deliver command
answer: yes if delivered successfully,
no if error in delivery.
reasons: if the answer is yes, the reason is "ok", if the answer
is no the reason could be one of "no such user", "no such host",
"no such network", "address ambiguous", or a similar response
how-delivered: one or more of the following:
"FORWARD" message was accepted for forwarding
"GENDEL" message was accepted for general delivery
"ACCEPT" message was accepted for normal delivery
other types of delivery may be defined later
argument structure:
LIST ( LIST ( INDEX, INTEGER ),
LIST ( INTEGER, ... ),
BOOLEAN,
LIST ( TEXT ),
LIST ( TEXT ))
[Page 26] Postel
March 1979
Internet Message Protocol
Specification
command: PROBE
type: 1
function: finds out if specified mailbox (specified in mailbox of
the command) exists at a host
reply: the reply is RESPONSE
arguments: LIST ( --none-- )
argument structure:
LIST ( )
Postel [Page 27]
March 1979
Internet Message Protocol
Specification
command: RESPONSE
type: 2
function: reply to PROBE
arguments: LIST ( tid, trail, answer, address OR reasons )
tid: the tid which came from the originating PROBE
trail: the stamp which came from the originating PROBE
answer: Yes if mailbox found, or no for invalid mailbox
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -