rfc821 (2 of 8)
ron at brl-adm.UUCP
ron at brl-adm.UUCP
Mon May 19 14:00:10 AEST 1986
RFC 821 August 1982
Simple Mail Transfer Protocol
3.2. FORWARDING
There are some cases where the destination information in the
<forward-path> is incorrect, but the receiver-SMTP knows the
correct destination. In such cases, one of the following replies
should be used to allow the sender to contact the correct
destination.
251 User not local; will forward to <forward-path>
This reply indicates that the receiver-SMTP knows the user's
mailbox is on another host and indicates the correct
forward-path to use in the future. Note that either the
host or user or both may be different. The receiver takes
responsibility for delivering the message.
551 User not local; please try <forward-path>
This reply indicates that the receiver-SMTP knows the user's
mailbox is on another host and indicates the correct
forward-path to use. Note that either the host or user or
both may be different. The receiver refuses to accept mail
for this user, and the sender must either redirect the mail
according to the information provided or return an error
response to the originating user.
Example 2 illustrates the use of these responses.
-------------------------------------------------------------
Example of Forwarding
Either
S: RCPT TO:<Postel at USC-ISI.ARPA>
R: 251 User not local; will forward to <Postel at USC-ISIF.ARPA>
Or
S: RCPT TO:<Paul at USC-ISIB.ARPA>
R: 551 User not local; please try <Mockapetris at USC-ISIF.ARPA>
Example 2
-------------------------------------------------------------
Postel [Page 7]
August 1982 RFC 821
Simple Mail Transfer Protocol
3.3. VERIFYING AND EXPANDING
SMTP provides as additional features, commands to verify a user
name or expand a mailing list. This is done with the VRFY and
EXPN commands, which have character string arguments. For the
VRFY command, the string is a user name, and the response may
include the full name of the user and must include the mailbox of
the user. For the EXPN command, the string identifies a mailing
list, and the multiline response may include the full name of the
users and must give the mailboxes on the mailing list.
"User name" is a fuzzy term and used purposely. If a host
implements the VRFY or EXPN commands then at least local mailboxes
must be recognized as "user names". If a host chooses to
recognize other strings as "user names" that is allowed.
In some hosts the distinction between a mailing list and an alias
for a single mailbox is a bit fuzzy, since a common data structure
may hold both types of entries, and it is possible to have mailing
lists of one mailbox. If a request is made to verify a mailing
list a positive response can be given if on receipt of a message
so addressed it will be delivered to everyone on the list,
otherwise an error should be reported (e.g., "550 That is a
mailing list, not a user"). If a request is made to expand a user
name a positive response can be formed by returning a list
containing one name, or an error can be reported (e.g., "550 That
is a user name, not a mailing list").
In the case of a multiline reply (normal for EXPN) exactly one
mailbox is to be specified on each line of the reply. In the case
of an ambiguous request, for example, "VRFY Smith", where there
are two Smith's the response must be "553 User ambiguous".
The case of verifying a user name is straightforward as shown in
example 3.
[Page 8] Postel
RFC 821 August 1982
Simple Mail Transfer Protocol
-------------------------------------------------------------
Example of Verifying a User Name
Either
S: VRFY Smith
R: 250 Fred Smith <Smith at USC-ISIF.ARPA>
Or
S: VRFY Smith
R: 251 User not local; will forward to <Smith at USC-ISIQ.ARPA>
Or
S: VRFY Jones
R: 550 String does not match anything.
Or
S: VRFY Jones
R: 551 User not local; please try <Jones at USC-ISIQ.ARPA>
Or
S: VRFY Gourzenkyinplatz
R: 553 User ambiguous.
Example 3
-------------------------------------------------------------
Postel [Page 9]
August 1982 RFC 821
Simple Mail Transfer Protocol
The case of expanding a mailbox list requires a multiline reply as
shown in example 4.
-------------------------------------------------------------
Example of Expanding a Mailing List
Either
S: EXPN Example-People
R: 250-Jon Postel <Postel at USC-ISIF.ARPA>
R: 250-Fred Fonebone <Fonebone at USC-ISIQ.ARPA>
R: 250-Sam Q. Smith <SQSmith at USC-ISIQ.ARPA>
R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith at ISI-VAXA.ARPA>
R: 250-<joe at foo-unix.ARPA>
R: 250 <xyz at bar-unix.ARPA>
Or
S: EXPN Executive-Washroom-List
R: 550 Access Denied to You.
Example 4
-------------------------------------------------------------
The character string arguments of the VRFY and EXPN commands
cannot be further restricted due to the variety of implementations
of the user name and mailbox list concepts. On some systems it
may be appropriate for the argument of the EXPN command to be a
file name for a file containing a mailing list, but again there is
a variety of file naming conventions in the Internet.
The VRFY and EXPN commands are not included in the minimum
implementation (Section 4.5.1), and are not required to work
across relays when they are implemented.
[Page 10] Postel
RFC 821 August 1982
Simple Mail Transfer Protocol
3.4. SENDING AND MAILING
The main purpose of SMTP is to deliver messages to user's
mailboxes. A very similar service provided by some hosts is to
deliver messages to user's terminals (provided the user is active
on the host). The delivery to the user's mailbox is called
"mailing", the delivery to the user's terminal is called
"sending". Because in many hosts the implementation of sending is
nearly identical to the implementation of mailing these two
functions are combined in SMTP. However the sending commands are
not included in the required minimum implementation
(Section 4.5.1). Users should have the ability to control the
writing of messages on their terminals. Most hosts permit the
users to accept or refuse such messages.
The following three command are defined to support the sending
options. These are used in the mail transaction instead of the
MAIL command and inform the receiver-SMTP of the special semantics
of this transaction:
SEND <SP> FROM:<reverse-path> <CRLF>
The SEND command requires that the mail data be delivered to
the user's terminal. If the user is not active (or not
accepting terminal messages) on the host a 450 reply may
returned to a RCPT command. The mail transaction is
successful if the message is delivered the terminal.
SOML <SP> FROM:<reverse-path> <CRLF>
The Send Or MaiL command requires that the mail data be
delivered to the user's terminal if the user is active (and
accepting terminal messages) on the host. If the user is
not active (or not accepting terminal messages) then the
mail data is entered into the user's mailbox. The mail
transaction is successful if the message is delivered either
to the terminal or the mailbox.
SAML <SP> FROM:<reverse-path> <CRLF>
The Send And MaiL command requires that the mail data be
delivered to the user's terminal if the user is active (and
accepting terminal messages) on the host. In any case the
mail data is entered into the user's mailbox. The mail
transaction is successful if the message is delivered the
mailbox.
Postel [Page 11]
August 1982 RFC 821
Simple Mail Transfer Protocol
The same reply codes that are used for the MAIL commands are used
for these commands.
[Page 12] Postel
RFC 821 August 1982
Simple Mail Transfer Protocol
3.5. OPENING AND CLOSING
At the time the transmission channel is opened there is an
exchange to ensure that the hosts are communicating with the hosts
they think they are.
The following two commands are used in transmission channel
opening and closing:
HELO <SP> <domain> <CRLF>
QUIT <CRLF>
In the HELO command the host sending the command identifies
itself; the command may be interpreted as saying "Hello, I am
<domain>".
-------------------------------------------------------------
Example of Connection Opening
R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
S: HELO USC-ISIF.ARPA
R: 250 BBN-UNIX.ARPA
Example 5
-------------------------------------------------------------
-------------------------------------------------------------
Example of Connection Closing
S: QUIT
R: 221 BBN-UNIX.ARPA Service closing transmission channel
Example 6
-------------------------------------------------------------
Postel [Page 13]
August 1982 RFC 821
Simple Mail Transfer Protocol
3.6. RELAYING
The forward-path may be a source route of the form
"@ONE, at TWO:JOE at THREE", where ONE, TWO, and THREE are hosts. This
form is used to emphasize the distinction between an address and a
route. The mailbox is an absolute address, and the route is
information about how to get there. The two concepts should not
be confused.
Conceptually the elements of the forward-path are moved to the
reverse-path as the message is relayed from one server-SMTP to
another. The reverse-path is a reverse source route, (i.e., a
source route from the current location of the message to the
originator of the message). When a server-SMTP deletes its
identifier from the forward-path and inserts it into the
reverse-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 server-SMTP is known by different names in
different environments.
If when the message arrives at an SMTP the first element of the
forward-path is not the identifier of that SMTP the element is not
deleted from the forward-path and is used to determine the next
SMTP to send the message to. In any case, the SMTP adds its own
identifier to the reverse-path.
Using source routing the receiver-SMTP receives mail to be relayed
to another server-SMTP The receiver-SMTP may accept or reject the
task of relaying the mail in the same way it accepts or rejects
mail for a local user. The receiver-SMTP transforms the command
arguments by moving its own identifier from the forward-path to
the beginning of the reverse-path. The receiver-SMTP then becomes
a sender-SMTP, establishes a transmission channel to the next SMTP
in the forward-path, and sends it the mail.
The first host in the reverse-path should be the host sending the
SMTP commands, and the first host in the forward-path should be
the host receiving the SMTP commands.
Notice that the forward-path and reverse-path appear in the SMTP
commands and replies, but not necessarily in the message. That
is, there is no need for these paths and especially this syntax to
appear in the "To:" , "From:", "CC:", etc. fields of the message
header.
If a server-SMTP has accepted the task of relaying the mail and
[Page 14] Postel
RFC 821 August 1982
Simple Mail Transfer Protocol
later finds that the forward-path is incorrect or that the mail
cannot be delivered for whatever reason, then it must construct an
"undeliverable mail" notification message and send it to the
originator of the undeliverable mail (as indicated by the
reverse-path).
This notification message must be from the server-SMTP at this
host. Of course, server-SMTPs should not send notification
messages about problems with notification messages. One way to
prevent loops in error reporting is to specify a null reverse-path
in the MAIL command of a notification message. When such a
message is relayed it is permissible to leave the reverse-path
null. A MAIL command with a null reverse-path appears as follows:
MAIL FROM:<>
An undeliverable mail notification message is shown in example 7.
This notification is in response to a message originated by JOE at
HOSTW and sent via HOSTX to HOSTY with instructions to relay it on
to HOSTZ. What we see in the example is the transaction between
HOSTY and HOSTX, which is the first step in the return of the
notification message.
Postel [Page 15]
August 1982 RFC 821
Simple Mail Transfer Protocol
-------------------------------------------------------------
Example Undeliverable Mail Notification Message
S: MAIL FROM:<>
R: 250 ok
S: RCPT TO:<@HOSTX.ARPA:JOE at HOSTW.ARPA>
R: 250 ok
S: DATA
R: 354 send the mail data, end with .
S: Date: 23 Oct 81 11:22:33
S: From: SMTP at HOSTY.ARPA
S: To: JOE at HOSTW.ARPA
S: Subject: Mail System Problem
S:
S: Sorry JOE, your message to SAM at HOSTZ.ARPA lost.
S: HOSTZ.ARPA said this:
S: "550 No Such User"
S: .
R: 250 ok
Example 7
-------------------------------------------------------------
[Page 16] Postel
More information about the Mod.sources.doc
mailing list