| blob | d877b72cff94d496f2a65ccb4e79e59b044af66f |
4 RFC 821
10 SIMPLE MAIL TRANSFER PROTOCOL
14 Jonathan B. Postel
44 August 1982
48 Information Sciences Institute
49 University of Southern California
50 4676 Admiralty Way
51 Marina del Rey, California 90291
53 (213) 822-1511
54 \f
55 \f
58 RFC 821 August 1982
59 Simple Mail Transfer Protocol
63 TABLE OF CONTENTS
65 1. INTRODUCTION .................................................. 1
67 2. THE SMTP MODEL ................................................ 2
69 3. THE SMTP PROCEDURE ............................................ 4
71 3.1. Mail ..................................................... 4
72 3.2. Forwarding ............................................... 7
73 3.3. Verifying and Expanding .................................. 8
74 3.4. Sending and Mailing ..................................... 11
75 3.5. Opening and Closing ..................................... 13
76 3.6. Relaying ................................................ 14
77 3.7. Domains ................................................. 17
78 3.8. Changing Roles .......................................... 18
80 4. THE SMTP SPECIFICATIONS ...................................... 19
82 4.1. SMTP Commands ........................................... 19
83 4.1.1. Command Semantics ..................................... 19
84 4.1.2. Command Syntax ........................................ 27
85 4.2. SMTP Replies ............................................ 34
86 4.2.1. Reply Codes by Function Group ......................... 35
87 4.2.2. Reply Codes in Numeric Order .......................... 36
88 4.3. Sequencing of Commands and Replies ...................... 37
89 4.4. State Diagrams .......................................... 39
90 4.5. Details ................................................. 41
91 4.5.1. Minimum Implementation ................................ 41
92 4.5.2. Transparency .......................................... 41
93 4.5.3. Sizes ................................................. 42
95 APPENDIX A: TCP ................................................. 44
96 APPENDIX B: NCP ................................................. 45
97 APPENDIX C: NITS ................................................ 46
98 APPENDIX D: X.25 ................................................ 47
99 APPENDIX E: Theory of Reply Codes ............................... 48
100 APPENDIX F: Scenarios ........................................... 51
102 GLOSSARY ......................................................... 64
104 REFERENCES ....................................................... 67
105 \f
106 \f
109 Network Working Group J. Postel
110 Request for Comments: DRAFT ISI
111 Replaces: RFC 788, 780, 772 August 1982
113 SIMPLE MAIL TRANSFER PROTOCOL
116 1. INTRODUCTION
118 The objective of Simple Mail Transfer Protocol (SMTP) is to transfer
119 mail reliably and efficiently.
121 SMTP is independent of the particular transmission subsystem and
122 requires only a reliable ordered data stream channel. Appendices A,
123 B, C, and D describe the use of SMTP with various transport services.
124 A Glossary provides the definitions of terms as used in this
125 document.
127 An important feature of SMTP is its capability to relay mail across
128 transport service environments. A transport service provides an
129 interprocess communication environment (IPCE). An IPCE may cover one
130 network, several networks, or a subset of a network. It is important
131 to realize that transport systems (or IPCEs) are not one-to-one with
132 networks. A process can communicate directly with another process
133 through any mutually known IPCE. Mail is an application or use of
134 interprocess communication. Mail can be communicated between
135 processes in different IPCEs by relaying through a process connected
136 to two (or more) IPCEs. More specifically, mail can be relayed
137 between hosts on different transport systems by a host on both
138 transport systems.
163 Postel [Page 1]
164 \f
167 August 1982 RFC 821
168 Simple Mail Transfer Protocol
172 2. THE SMTP MODEL
174 The SMTP design is based on the following model of communication: as
175 the result of a user mail request, the sender-SMTP establishes a
176 two-way transmission channel to a receiver-SMTP. The receiver-SMTP
177 may be either the ultimate destination or an intermediate. SMTP
178 commands are generated by the sender-SMTP and sent to the
179 receiver-SMTP. SMTP replies are sent from the receiver-SMTP to the
180 sender-SMTP in response to the commands.
182 Once the transmission channel is established, the SMTP-sender sends a
183 MAIL command indicating the sender of the mail. If the SMTP-receiver
184 can accept mail it responds with an OK reply. The SMTP-sender then
185 sends a RCPT command identifying a recipient of the mail. If the
186 SMTP-receiver can accept mail for that recipient it responds with an
187 OK reply; if not, it responds with a reply rejecting that recipient
188 (but not the whole mail transaction). The SMTP-sender and
189 SMTP-receiver may negotiate several recipients. When the recipients
190 have been negotiated the SMTP-sender sends the mail data, terminating
191 with a special sequence. If the SMTP-receiver successfully processes
192 the mail data it responds with an OK reply. The dialog is purposely
193 lock-step, one-at-a-time.
195 -------------------------------------------------------------
198 +----------+ +----------+
199 +------+ | | | |
200 | User |<-->| | SMTP | |
201 +------+ | Sender- |Commands/Replies| Receiver-|
202 +------+ | SMTP |<-------------->| SMTP | +------+
203 | File |<-->| | and Mail | |<-->| File |
204 |System| | | | | |System|
205 +------+ +----------+ +----------+ +------+
208 Sender-SMTP Receiver-SMTP
210 Model for SMTP Use
212 Figure 1
214 -------------------------------------------------------------
216 The SMTP provides mechanisms for the transmission of mail; directly
217 from the sending user's host to the receiving user's host when the
221 [Page 2] Postel
222 \f
225 RFC 821 August 1982
226 Simple Mail Transfer Protocol
230 two host are connected to the same transport service, or via one or
231 more relay SMTP-servers when the source and destination hosts are not
232 connected to the same transport service.
234 To be able to provide the relay capability the SMTP-server must be
235 supplied with the name of the ultimate destination host as well as
236 the destination mailbox name.
238 The argument to the MAIL command is a reverse-path, which specifies
239 who the mail is from. The argument to the RCPT command is a
240 forward-path, which specifies who the mail is to. The forward-path
241 is a source route, while the reverse-path is a return route (which
242 may be used to return a message to the sender when an error occurs
243 with a relayed message).
245 When the same message is sent to multiple recipients the SMTP
246 encourages the transmission of only one copy of the data for all the
247 recipients at the same destination host.
249 The mail commands and replies have a rigid syntax. Replies also have
250 a numeric code. In the following, examples appear which use actual
251 commands and replies. The complete lists of commands and replies
252 appears in Section 4 on specifications.
254 Commands and replies are not case sensitive. That is, a command or
255 reply word may be upper case, lower case, or any mixture of upper and
256 lower case. Note that this is not true of mailbox user names. For
257 some hosts the user name is case sensitive, and SMTP implementations
258 must take case to preserve the case of user names as they appear in
259 mailbox arguments. Host names are not case sensitive.
261 Commands and replies are composed of characters from the ASCII
262 character set [1]. When the transport service provides an 8-bit byte
263 (octet) transmission channel, each 7-bit character is transmitted
264 right justified in an octet with the high order bit cleared to zero.
266 When specifying the general form of a command or reply, an argument
267 (or special symbol) will be denoted by a meta-linguistic variable (or
268 constant), for example, "<string>" or "<reverse-path>". Here the
269 angle brackets indicate these are meta-linguistic variables.
270 However, some arguments use the angle brackets literally. For
271 example, an actual reverse-path is enclosed in angle brackets, i.e.,
272 "<John.Smith@USC-ISI.ARPA>" is an instance of <reverse-path> (the
273 angle brackets are actually transmitted in the command or reply).
279 Postel [Page 3]
280 \f
283 August 1982 RFC 821
284 Simple Mail Transfer Protocol
288 3. THE SMTP PROCEDURES
290 This section presents the procedures used in SMTP in several parts.
291 First comes the basic mail procedure defined as a mail transaction.
292 Following this are descriptions of forwarding mail, verifying mailbox
293 names and expanding mailing lists, sending to terminals instead of or
294 in combination with mailboxes, and the opening and closing exchanges.
295 At the end of this section are comments on relaying, a note on mail
296 domains, and a discussion of changing roles. Throughout this section
297 are examples of partial command and reply sequences, several complete
298 scenarios are presented in Appendix F.
300 3.1. MAIL
302 There are three steps to SMTP mail transactions. The transaction
303 is started with a MAIL command which gives the sender
304 identification. A series of one or more RCPT commands follows
305 giving the receiver information. Then a DATA command gives the
306 mail data. And finally, the end of mail data indicator confirms
307 the transaction.
309 The first step in the procedure is the MAIL command. The
310 <reverse-path> contains the source mailbox.
312 MAIL <SP> FROM:<reverse-path> <CRLF>
314 This command tells the SMTP-receiver that a new mail
315 transaction is starting and to reset all its state tables and
316 buffers, including any recipients or mail data. It gives the
317 reverse-path which can be used to report errors. If accepted,
318 the receiver-SMTP returns a 250 OK reply.
320 The <reverse-path> can contain more than just a mailbox. The
321 <reverse-path> is a reverse source routing list of hosts and
322 source mailbox. The first host in the <reverse-path> should be
323 the host sending this command.
325 The second step in the procedure is the RCPT command.
327 RCPT <SP> TO:<forward-path> <CRLF>
329 This command gives a forward-path identifying one recipient.
330 If accepted, the receiver-SMTP returns a 250 OK reply, and
331 stores the forward-path. If the recipient is unknown the
332 receiver-SMTP returns a 550 Failure reply. This second step of
333 the procedure can be repeated any number of times.
337 [Page 4] Postel
338 \f
341 RFC 821 August 1982
342 Simple Mail Transfer Protocol
346 The <forward-path> can contain more than just a mailbox. The
347 <forward-path> is a source routing list of hosts and the
348 destination mailbox. The first host in the <forward-path>
349 should be the host receiving this command.
351 The third step in the procedure is the DATA command.
353 DATA <CRLF>
355 If accepted, the receiver-SMTP returns a 354 Intermediate reply
356 and considers all succeeding lines to be the message text.
357 When the end of text is received and stored the SMTP-receiver
358 sends a 250 OK reply.
360 Since the mail data is sent on the transmission channel the end
361 of the mail data must be indicated so that the command and
362 reply dialog can be resumed. SMTP indicates the end of the
363 mail data by sending a line containing only a period. A
364 transparency procedure is used to prevent this from interfering
365 with the user's text (see Section 4.5.2).
367 Please note that the mail data includes the memo header
368 items such as Date, Subject, To, Cc, From [2].
370 The end of mail data indicator also confirms the mail
371 transaction and tells the receiver-SMTP to now process the
372 stored recipients and mail data. If accepted, the
373 receiver-SMTP returns a 250 OK reply. The DATA command should
374 fail only if the mail transaction was incomplete (for example,
375 no recipients), or if resources are not available.
377 The above procedure is an example of a mail transaction. These
378 commands must be used only in the order discussed above.
379 Example 1 (below) illustrates the use of these commands in a mail
380 transaction.
395 Postel [Page 5]
396 \f
399 August 1982 RFC 821
400 Simple Mail Transfer Protocol
404 -------------------------------------------------------------
406 Example of the SMTP Procedure
408 This SMTP example shows mail sent by Smith at host Alpha.ARPA,
409 to Jones, Green, and Brown at host Beta.ARPA. Here we assume
410 that host Alpha contacts host Beta directly.
412 S: MAIL FROM:<Smith@Alpha.ARPA>
413 R: 250 OK
415 S: RCPT TO:<Jones@Beta.ARPA>
416 R: 250 OK
418 S: RCPT TO:<Green@Beta.ARPA>
419 R: 550 No such user here
421 S: RCPT TO:<Brown@Beta.ARPA>
422 R: 250 OK
424 S: DATA
425 R: 354 Start mail input; end with <CRLF>.<CRLF>
426 S: Blah blah blah...
427 S: ...etc. etc. etc.
428 S: <CRLF>.<CRLF>
429 R: 250 OK
431 The mail has now been accepted for Jones and Brown. Green did
432 not have a mailbox at host Beta.
434 Example 1
436 -------------------------------------------------------------
453 [Page 6] Postel
454 \f
457 RFC 821 August 1982
458 Simple Mail Transfer Protocol
462 3.2. FORWARDING
464 There are some cases where the destination information in the
465 <forward-path> is incorrect, but the receiver-SMTP knows the
466 correct destination. In such cases, one of the following replies
467 should be used to allow the sender to contact the correct
468 destination.
470 251 User not local; will forward to <forward-path>
472 This reply indicates that the receiver-SMTP knows the user's
473 mailbox is on another host and indicates the correct
474 forward-path to use in the future. Note that either the
475 host or user or both may be different. The receiver takes
476 responsibility for delivering the message.
478 551 User not local; please try <forward-path>
480 This reply indicates that the receiver-SMTP knows the user's
481 mailbox is on another host and indicates the correct
482 forward-path to use. Note that either the host or user or
483 both may be different. The receiver refuses to accept mail
484 for this user, and the sender must either redirect the mail
485 according to the information provided or return an error
486 response to the originating user.
488 Example 2 illustrates the use of these responses.
490 -------------------------------------------------------------
492 Example of Forwarding
494 Either
496 S: RCPT TO:<Postel@USC-ISI.ARPA>
497 R: 251 User not local; will forward to <Postel@USC-ISIF.ARPA>
499 Or
501 S: RCPT TO:<Paul@USC-ISIB.ARPA>
502 R: 551 User not local; please try <Mockapetris@USC-ISIF.ARPA>
504 Example 2
506 -------------------------------------------------------------
511 Postel [Page 7]
512 \f
515 August 1982 RFC 821
516 Simple Mail Transfer Protocol
520 3.3. VERIFYING AND EXPANDING
522 SMTP provides as additional features, commands to verify a user
523 name or expand a mailing list. This is done with the VRFY and
524 EXPN commands, which have character string arguments. For the
525 VRFY command, the string is a user name, and the response may
526 include the full name of the user and must include the mailbox of
527 the user. For the EXPN command, the string identifies a mailing
528 list, and the multiline response may include the full name of the
529 users and must give the mailboxes on the mailing list.
531 "User name" is a fuzzy term and used purposely. If a host
532 implements the VRFY or EXPN commands then at least local mailboxes
533 must be recognized as "user names". If a host chooses to
534 recognize other strings as "user names" that is allowed.
536 In some hosts the distinction between a mailing list and an alias
537 for a single mailbox is a bit fuzzy, since a common data structure
538 may hold both types of entries, and it is possible to have mailing
539 lists of one mailbox. If a request is made to verify a mailing
540 list a positive response can be given if on receipt of a message
541 so addressed it will be delivered to everyone on the list,
542 otherwise an error should be reported (e.g., "550 That is a
543 mailing list, not a user"). If a request is made to expand a user
544 name a positive response can be formed by returning a list
545 containing one name, or an error can be reported (e.g., "550 That
546 is a user name, not a mailing list").
548 In the case of a multiline reply (normal for EXPN) exactly one
549 mailbox is to be specified on each line of the reply. In the case
550 of an ambiguous request, for example, "VRFY Smith", where there
551 are two Smith's the response must be "553 User ambiguous".
553 The case of verifying a user name is straightforward as shown in
554 example 3.
569 [Page 8] Postel
570 \f
573 RFC 821 August 1982
574 Simple Mail Transfer Protocol
578 -------------------------------------------------------------
580 Example of Verifying a User Name
582 Either
584 S: VRFY Smith
585 R: 250 Fred Smith <Smith@USC-ISIF.ARPA>
587 Or
589 S: VRFY Smith
590 R: 251 User not local; will forward to <Smith@USC-ISIQ.ARPA>
592 Or
594 S: VRFY Jones
595 R: 550 String does not match anything.
597 Or
599 S: VRFY Jones
600 R: 551 User not local; please try <Jones@USC-ISIQ.ARPA>
602 Or
604 S: VRFY Gourzenkyinplatz
605 R: 553 User ambiguous.
607 Example 3
609 -------------------------------------------------------------
627 Postel [Page 9]
628 \f
631 August 1982 RFC 821
632 Simple Mail Transfer Protocol
636 The case of expanding a mailbox list requires a multiline reply as
637 shown in example 4.
639 -------------------------------------------------------------
641 Example of Expanding a Mailing List
643 Either
645 S: EXPN Example-People
646 R: 250-Jon Postel <Postel@USC-ISIF.ARPA>
647 R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA>
648 R: 250-Sam Q. Smith <SQSmith@USC-ISIQ.ARPA>
649 R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
650 R: 250-<joe@foo-unix.ARPA>
651 R: 250 <xyz@bar-unix.ARPA>
653 Or
655 S: EXPN Executive-Washroom-List
656 R: 550 Access Denied to You.
658 Example 4
660 -------------------------------------------------------------
662 The character string arguments of the VRFY and EXPN commands
663 cannot be further restricted due to the variety of implementations
664 of the user name and mailbox list concepts. On some systems it
665 may be appropriate for the argument of the EXPN command to be a
666 file name for a file containing a mailing list, but again there is
667 a variety of file naming conventions in the Internet.
669 The VRFY and EXPN commands are not included in the minimum
670 implementation (Section 4.5.1), and are not required to work
671 across relays when they are implemented.
685 [Page 10] Postel
686 \f
689 RFC 821 August 1982
690 Simple Mail Transfer Protocol
694 3.4. SENDING AND MAILING
696 The main purpose of SMTP is to deliver messages to user's
697 mailboxes. A very similar service provided by some hosts is to
698 deliver messages to user's terminals (provided the user is active
699 on the host). The delivery to the user's mailbox is called
700 "mailing", the delivery to the user's terminal is called
701 "sending". Because in many hosts the implementation of sending is
702 nearly identical to the implementation of mailing these two
703 functions are combined in SMTP. However the sending commands are
704 not included in the required minimum implementation
705 (Section 4.5.1). Users should have the ability to control the
706 writing of messages on their terminals. Most hosts permit the
707 users to accept or refuse such messages.
709 The following three command are defined to support the sending
710 options. These are used in the mail transaction instead of the
711 MAIL command and inform the receiver-SMTP of the special semantics
712 of this transaction:
714 SEND <SP> FROM:<reverse-path> <CRLF>
716 The SEND command requires that the mail data be delivered to
717 the user's terminal. If the user is not active (or not
718 accepting terminal messages) on the host a 450 reply may
719 returned to a RCPT command. The mail transaction is
720 successful if the message is delivered the terminal.
722 SOML <SP> FROM:<reverse-path> <CRLF>
724 The Send Or MaiL command requires that the mail data be
725 delivered to the user's terminal if the user is active (and
726 accepting terminal messages) on the host. If the user is
727 not active (or not accepting terminal messages) then the
728 mail data is entered into the user's mailbox. The mail
729 transaction is successful if the message is delivered either
730 to the terminal or the mailbox.
732 SAML <SP> FROM:<reverse-path> <CRLF>
734 The Send And MaiL command requires that the mail data be
735 delivered to the user's terminal if the user is active (and
736 accepting terminal messages) on the host. In any case the
737 mail data is entered into the user's mailbox. The mail
738 transaction is successful if the message is delivered the
739 mailbox.
743 Postel [Page 11]
744 \f
747 August 1982 RFC 821
748 Simple Mail Transfer Protocol
752 The same reply codes that are used for the MAIL commands are used
753 for these commands.
801 [Page 12] Postel
802 \f
805 RFC 821 August 1982
806 Simple Mail Transfer Protocol
810 3.5. OPENING AND CLOSING
812 At the time the transmission channel is opened there is an
813 exchange to ensure that the hosts are communicating with the hosts
814 they think they are.
816 The following two commands are used in transmission channel
817 opening and closing:
819 HELO <SP> <domain> <CRLF>
821 QUIT <CRLF>
823 In the HELO command the host sending the command identifies
824 itself; the command may be interpreted as saying "Hello, I am
825 <domain>".
827 -------------------------------------------------------------
829 Example of Connection Opening
831 R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
832 S: HELO USC-ISIF.ARPA
833 R: 250 BBN-UNIX.ARPA
835 Example 5
837 -------------------------------------------------------------
839 -------------------------------------------------------------
841 Example of Connection Closing
843 S: QUIT
844 R: 221 BBN-UNIX.ARPA Service closing transmission channel
846 Example 6
848 -------------------------------------------------------------
859 Postel [Page 13]
860 \f
863 August 1982 RFC 821
864 Simple Mail Transfer Protocol
868 3.6. RELAYING
870 The forward-path may be a source route of the form
871 "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE are hosts. This
872 form is used to emphasize the distinction between an address and a
873 route. The mailbox is an absolute address, and the route is
874 information about how to get there. The two concepts should not
875 be confused.
877 Conceptually the elements of the forward-path are moved to the
878 reverse-path as the message is relayed from one server-SMTP to
879 another. The reverse-path is a reverse source route, (i.e., a
880 source route from the current location of the message to the
881 originator of the message). When a server-SMTP deletes its
882 identifier from the forward-path and inserts it into the
883 reverse-path, it must use the name it is known by in the
884 environment it is sending into, not the environment the mail came
885 from, in case the server-SMTP is known by different names in
886 different environments.
888 If when the message arrives at an SMTP the first element of the
889 forward-path is not the identifier of that SMTP the element is not
890 deleted from the forward-path and is used to determine the next
891 SMTP to send the message to. In any case, the SMTP adds its own
892 identifier to the reverse-path.
894 Using source routing the receiver-SMTP receives mail to be relayed
895 to another server-SMTP The receiver-SMTP may accept or reject the
896 task of relaying the mail in the same way it accepts or rejects
897 mail for a local user. The receiver-SMTP transforms the command
898 arguments by moving its own identifier from the forward-path to
899 the beginning of the reverse-path. The receiver-SMTP then becomes
900 a sender-SMTP, establishes a transmission channel to the next SMTP
901 in the forward-path, and sends it the mail.
903 The first host in the reverse-path should be the host sending the
904 SMTP commands, and the first host in the forward-path should be
905 the host receiving the SMTP commands.
907 Notice that the forward-path and reverse-path appear in the SMTP
908 commands and replies, but not necessarily in the message. That
909 is, there is no need for these paths and especially this syntax to
910 appear in the "To:" , "From:", "CC:", etc. fields of the message
911 header.
913 If a server-SMTP has accepted the task of relaying the mail and
917 [Page 14] Postel
918 \f
921 RFC 821 August 1982
922 Simple Mail Transfer Protocol
926 later finds that the forward-path is incorrect or that the mail
927 cannot be delivered for whatever reason, then it must construct an
928 "undeliverable mail" notification message and send it to the
929 originator of the undeliverable mail (as indicated by the
930 reverse-path).
932 This notification message must be from the server-SMTP at this
933 host. Of course, server-SMTPs should not send notification
934 messages about problems with notification messages. One way to
935 prevent loops in error reporting is to specify a null reverse-path
936 in the MAIL command of a notification message. When such a
937 message is relayed it is permissible to leave the reverse-path
938 null. A MAIL command with a null reverse-path appears as follows:
940 MAIL FROM:<>
942 An undeliverable mail notification message is shown in example 7.
943 This notification is in response to a message originated by JOE at
944 HOSTW and sent via HOSTX to HOSTY with instructions to relay it on
945 to HOSTZ. What we see in the example is the transaction between
946 HOSTY and HOSTX, which is the first step in the return of the
947 notification message.
975 Postel [Page 15]
976 \f
979 August 1982 RFC 821
980 Simple Mail Transfer Protocol
984 -------------------------------------------------------------
986 Example Undeliverable Mail Notification Message
988 S: MAIL FROM:<>
989 R: 250 ok
990 S: RCPT TO:<@HOSTX.ARPA:JOE@HOSTW.ARPA>
991 R: 250 ok
992 S: DATA
993 R: 354 send the mail data, end with .
994 S: Date: 23 Oct 81 11:22:33
995 S: From: SMTP@HOSTY.ARPA
996 S: To: JOE@HOSTW.ARPA
997 S: Subject: Mail System Problem
998 S:
999 S: Sorry JOE, your message to SAM@HOSTZ.ARPA lost.
1000 S: HOSTZ.ARPA said this:
1001 S: "550 No Such User"
1002 S: .
1003 R: 250 ok
1005 Example 7
1007 -------------------------------------------------------------
1033 [Page 16] Postel
1034 \f
1037 RFC 821 August 1982
1038 Simple Mail Transfer Protocol
1042 3.7. DOMAINS
1044 Domains are a recently introduced concept in the ARPA Internet
1045 mail system. The use of domains changes the address space from a
1046 flat global space of simple character string host names to a
1047 hierarchically structured rooted tree of global addresses. The
1048 host name is replaced by a domain and host designator which is a
1049 sequence of domain element strings separated by periods with the
1050 understanding that the domain elements are ordered from the most
1051 specific to the most general.
1053 For example, "USC-ISIF.ARPA", "Fred.Cambridge.UK", and
1054 "PC7.LCS.MIT.ARPA" might be host-and-domain identifiers.
1056 Whenever domain names are used in SMTP only the official names are
1057 used, the use of nicknames or aliases is not allowed.
1091 Postel [Page 17]
1092 \f
1095 August 1982 RFC 821
1096 Simple Mail Transfer Protocol
1100 3.8. CHANGING ROLES
1102 The TURN command may be used to reverse the roles of the two
1103 programs communicating over the transmission channel.
1105 If program-A is currently the sender-SMTP and it sends the TURN
1106 command and receives an ok reply (250) then program-A becomes the
1107 receiver-SMTP.
1109 If program-B is currently the receiver-SMTP and it receives the
1110 TURN command and sends an ok reply (250) then program-B becomes
1111 the sender-SMTP.
1113 To refuse to change roles the receiver sends the 502 reply.
1115 Please note that this command is optional. It would not normally
1116 be used in situations where the transmission channel is TCP.
1117 However, when the cost of establishing the transmission channel is
1118 high, this command may be quite useful. For example, this command
1119 may be useful in supporting be mail exchange using the public
1120 switched telephone system as a transmission channel, especially if
1121 some hosts poll other hosts for mail exchanges.
1149 [Page 18] Postel
1150 \f
1153 RFC 821 August 1982
1154 Simple Mail Transfer Protocol
1158 4. THE SMTP SPECIFICATIONS
1160 4.1. SMTP COMMANDS
1162 4.1.1. COMMAND SEMANTICS
1164 The SMTP commands define the mail transfer or the mail system
1165 function requested by the user. SMTP commands are character
1166 strings terminated by <CRLF>. The command codes themselves are
1167 alphabetic characters terminated by <SP> if parameters follow
1168 and <CRLF> otherwise. The syntax of mailboxes must conform to
1169 receiver site conventions. The SMTP commands are discussed
1170 below. The SMTP replies are discussed in the Section 4.2.
1172 A mail transaction involves several data objects which are
1173 communicated as arguments to different commands. The
1174 reverse-path is the argument of the MAIL command, the
1175 forward-path is the argument of the RCPT command, and the mail
1176 data is the argument of the DATA command. These arguments or
1177 data objects must be transmitted and held pending the
1178 confirmation communicated by the end of mail data indication
1179 which finalizes the transaction. The model for this is that
1180 distinct buffers are provided to hold the types of data
1181 objects, that is, there is a reverse-path buffer, a
1182 forward-path buffer, and a mail data buffer. Specific commands
1183 cause information to be appended to a specific buffer, or cause
1184 one or more buffers to be cleared.
1186 HELLO (HELO)
1188 This command is used to identify the sender-SMTP to the
1189 receiver-SMTP. The argument field contains the host name of
1190 the sender-SMTP.
1192 The receiver-SMTP identifies itself to the sender-SMTP in
1193 the connection greeting reply, and in the response to this
1194 command.
1196 This command and an OK reply to it confirm that both the
1197 sender-SMTP and the receiver-SMTP are in the initial state,
1198 that is, there is no transaction in progress and all state
1199 tables and buffers are cleared.
1207 Postel [Page 19]
1208 \f
1211 August 1982 RFC 821
1212 Simple Mail Transfer Protocol
1216 MAIL (MAIL)
1218 This command is used to initiate a mail transaction in which
1219 the mail data is delivered to one or more mailboxes. The
1220 argument field contains a reverse-path.
1222 The reverse-path consists of an optional list of hosts and
1223 the sender mailbox. When the list of hosts is present, it
1224 is a "reverse" source route and indicates that the mail was
1225 relayed through each host on the list (the first host in the
1226 list was the most recent relay). This list is used as a
1227 source route to return non-delivery notices to the sender.
1228 As each relay host adds itself to the beginning of the list,
1229 it must use its name as known in the IPCE to which it is
1230 relaying the mail rather than the IPCE from which the mail
1231 came (if they are different). In some types of error
1232 reporting messages (for example, undeliverable mail
1233 notifications) the reverse-path may be null (see Example 7).
1235 This command clears the reverse-path buffer, the
1236 forward-path buffer, and the mail data buffer; and inserts
1237 the reverse-path information from this command into the
1238 reverse-path buffer.
1240 RECIPIENT (RCPT)
1242 This command is used to identify an individual recipient of
1243 the mail data; multiple recipients are specified by multiple
1244 use of this command.
1246 The forward-path consists of an optional list of hosts and a
1247 required destination mailbox. When the list of hosts is
1248 present, it is a source route and indicates that the mail
1249 must be relayed to the next host on the list. If the
1250 receiver-SMTP does not implement the relay function it may
1251 user the same reply it would for an unknown local user
1252 (550).
1254 When mail is relayed, the relay host must remove itself from
1255 the beginning forward-path and put itself at the beginning
1256 of the reverse-path. When mail reaches its ultimate
1257 destination (the forward-path contains only a destination
1258 mailbox), the receiver-SMTP inserts it into the destination
1259 mailbox in accordance with its host mail conventions.
1265 [Page 20] Postel
1266 \f
1269 RFC 821 August 1982
1270 Simple Mail Transfer Protocol
1274 For example, mail received at relay host A with arguments
1276 FROM:<USERX@HOSTY.ARPA>
1277 TO:<@HOSTA.ARPA,@HOSTB.ARPA:USERC@HOSTD.ARPA>
1279 will be relayed on to host B with arguments
1281 FROM:<@HOSTA.ARPA:USERX@HOSTY.ARPA>
1282 TO:<@HOSTB.ARPA:USERC@HOSTD.ARPA>.
1284 This command causes its forward-path argument to be appended
1285 to the forward-path buffer.
1287 DATA (DATA)
1289 The receiver treats the lines following the command as mail
1290 data from the sender. This command causes the mail data
1291 from this command to be appended to the mail data buffer.
1292 The mail data may contain any of the 128 ASCII character
1293 codes.
1295 The mail data is terminated by a line containing only a
1296 period, that is the character sequence "<CRLF>.<CRLF>" (see
1297 Section 4.5.2 on Transparency). This is the end of mail
1298 data indication.
1300 The end of mail data indication requires that the receiver
1301 must now process the stored mail transaction information.
1302 This processing consumes the information in the reverse-path
1303 buffer, the forward-path buffer, and the mail data buffer,
1304 and on the completion of this command these buffers are
1305 cleared. If the processing is successful the receiver must
1306 send an OK reply. If the processing fails completely the
1307 receiver must send a failure reply.
1309 When the receiver-SMTP accepts a message either for relaying
1310 or for final delivery it inserts at the beginning of the
1311 mail data a time stamp line. The time stamp line indicates
1312 the identity of the host that sent the message, and the
1313 identity of the host that received the message (and is
1314 inserting this time stamp), and the date and time the
1315 message was received. Relayed messages will have multiple
1316 time stamp lines.
1318 When the receiver-SMTP makes the "final delivery" of a
1319 message it inserts at the beginning of the mail data a
1323 Postel [Page 21]
1324 \f
1327 August 1982 RFC 821
1328 Simple Mail Transfer Protocol
1332 return path line. The return path line preserves the
1333 information in the <reverse-path> from the MAIL command.
1334 Here, final delivery means the message leaves the SMTP
1335 world. Normally, this would mean it has been delivered to
1336 the destination user, but in some cases it may be further
1337 processed and transmitted by another mail system.
1339 It is possible for the mailbox in the return path be
1340 different from the actual sender's mailbox, for example,
1341 if error responses are to be delivered a special error
1342 handling mailbox rather than the message senders.
1344 The preceding two paragraphs imply that the final mail data
1345 will begin with a return path line, followed by one or more
1346 time stamp lines. These lines will be followed by the mail
1347 data header and body [2]. See Example 8.
1349 Special mention is needed of the response and further action
1350 required when the processing following the end of mail data
1351 indication is partially successful. This could arise if
1352 after accepting several recipients and the mail data, the
1353 receiver-SMTP finds that the mail data can be successfully
1354 delivered to some of the recipients, but it cannot be to
1355 others (for example, due to mailbox space allocation
1356 problems). In such a situation, the response to the DATA
1357 command must be an OK reply. But, the receiver-SMTP must
1358 compose and send an "undeliverable mail" notification
1359 message to the originator of the message. Either a single
1360 notification which lists all of the recipients that failed
1361 to get the message, or separate notification messages must
1362 be sent for each failed recipient (see Example 7). All
1363 undeliverable mail notification messages are sent using the
1364 MAIL command (even if they result from processing a SEND,
1365 SOML, or SAML command).
1381 [Page 22] Postel
1382 \f
1385 RFC 821 August 1982
1386 Simple Mail Transfer Protocol
1390 -------------------------------------------------------------
1392 Example of Return Path and Received Time Stamps
1394 Return-Path: <@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:JOE@ABC.ARPA>
1395 Received: from GHI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 PST
1396 Received: from DEF.ARPA by GHI.ARPA ; 27 Oct 81 15:15:13 PST
1397 Received: from ABC.ARPA by DEF.ARPA ; 27 Oct 81 15:01:59 PST
1398 Date: 27 Oct 81 15:01:01 PST
1399 From: JOE@ABC.ARPA
1400 Subject: Improved Mailing System Installed
1401 To: SAM@JKL.ARPA
1403 This is to inform you that ...
1405 Example 8
1407 -------------------------------------------------------------
1409 SEND (SEND)
1411 This command is used to initiate a mail transaction in which
1412 the mail data is delivered to one or more terminals. The
1413 argument field contains a reverse-path. This command is
1414 successful if the message is delivered to a terminal.
1416 The reverse-path consists of an optional list of hosts and
1417 the sender mailbox. When the list of hosts is present, it
1418 is a "reverse" source route and indicates that the mail was
1419 relayed through each host on the list (the first host in the
1420 list was the most recent relay). This list is used as a
1421 source route to return non-delivery notices to the sender.
1422 As each relay host adds itself to the beginning of the list,
1423 it must use its name as known in the IPCE to which it is
1424 relaying the mail rather than the IPCE from which the mail
1425 came (if they are different).
1427 This command clears the reverse-path buffer, the
1428 forward-path buffer, and the mail data buffer; and inserts
1429 the reverse-path information from this command into the
1430 reverse-path buffer.
1432 SEND OR MAIL (SOML)
1434 This command is used to initiate a mail transaction in which
1435 the mail data is delivered to one or more terminals or
1439 Postel [Page 23]
1440 \f
1443 August 1982 RFC 821
1444 Simple Mail Transfer Protocol
1448 mailboxes. For each recipient the mail data is delivered to
1449 the recipient's terminal if the recipient is active on the
1450 host (and accepting terminal messages), otherwise to the
1451 recipient's mailbox. The argument field contains a
1452 reverse-path. This command is successful if the message is
1453 delivered to a terminal or the mailbox.
1455 The reverse-path consists of an optional list of hosts and
1456 the sender mailbox. When the list of hosts is present, it
1457 is a "reverse" source route and indicates that the mail was
1458 relayed through each host on the list (the first host in the
1459 list was the most recent relay). This list is used as a
1460 source route to return non-delivery notices to the sender.
1461 As each relay host adds itself to the beginning of the list,
1462 it must use its name as known in the IPCE to which it is
1463 relaying the mail rather than the IPCE from which the mail
1464 came (if they are different).
1466 This command clears the reverse-path buffer, the
1467 forward-path buffer, and the mail data buffer; and inserts
1468 the reverse-path information from this command into the
1469 reverse-path buffer.
1471 SEND AND MAIL (SAML)
1473 This command is used to initiate a mail transaction in which
1474 the mail data is delivered to one or more terminals and
1475 mailboxes. For each recipient the mail data is delivered to
1476 the recipient's terminal if the recipient is active on the
1477 host (and accepting terminal messages), and for all
1478 recipients to the recipient's mailbox. The argument field
1479 contains a reverse-path. This command is successful if the
1480 message is delivered to the mailbox.
1482 The reverse-path consists of an optional list of hosts and
1483 the sender mailbox. When the list of hosts is present, it
1484 is a "reverse" source route and indicates that the mail was
1485 relayed through each host on the list (the first host in the
1486 list was the most recent relay). This list is used as a
1487 source route to return non-delivery notices to the sender.
1488 As each relay host adds itself to the beginning of the list,
1489 it must use its name as known in the IPCE to which it is
1490 relaying the mail rather than the IPCE from which the mail
1491 came (if they are different).
1493 This command clears the reverse-path buffer, the
1497 [Page 24] Postel
1498 \f
1501 RFC 821 August 1982
1502 Simple Mail Transfer Protocol
1506 forward-path buffer, and the mail data buffer; and inserts
1507 the reverse-path information from this command into the
1508 reverse-path buffer.
1510 RESET (RSET)
1512 This command specifies that the current mail transaction is
1513 to be aborted. Any stored sender, recipients, and mail data
1514 must be discarded, and all buffers and state tables cleared.
1515 The receiver must send an OK reply.
1517 VERIFY (VRFY)
1519 This command asks the receiver to confirm that the argument
1520 identifies a user. If it is a user name, the full name of
1521 the user (if known) and the fully specified mailbox are
1522 returned.
1524 This command has no effect on any of the reverse-path
1525 buffer, the forward-path buffer, or the mail data buffer.
1527 EXPAND (EXPN)
1529 This command asks the receiver to confirm that the argument
1530 identifies a mailing list, and if so, to return the
1531 membership of that list. The full name of the users (if
1532 known) and the fully specified mailboxes are returned in a
1533 multiline reply.
1535 This command has no effect on any of the reverse-path
1536 buffer, the forward-path buffer, or the mail data buffer.
1538 HELP (HELP)
1540 This command causes the receiver to send helpful information
1541 to the sender of the HELP command. The command may take an
1542 argument (e.g., any command name) and return more specific
1543 information as a response.
1545 This command has no effect on any of the reverse-path
1546 buffer, the forward-path buffer, or the mail data buffer.
1555 Postel [Page 25]
1556 \f
1559 August 1982 RFC 821
1560 Simple Mail Transfer Protocol
1564 NOOP (NOOP)
1566 This command does not affect any parameters or previously
1567 entered commands. It specifies no action other than that
1568 the receiver send an OK reply.
1570 This command has no effect on any of the reverse-path
1571 buffer, the forward-path buffer, or the mail data buffer.
1573 QUIT (QUIT)
1575 This command specifies that the receiver must send an OK
1576 reply, and then close the transmission channel.
1578 The receiver should not close the transmission channel until
1579 it receives and replies to a QUIT command (even if there was
1580 an error). The sender should not close the transmission
1581 channel until it send a QUIT command and receives the reply
1582 (even if there was an error response to a previous command).
1583 If the connection is closed prematurely the receiver should
1584 act as if a RSET command had been received (canceling any
1585 pending transaction, but not undoing any previously
1586 completed transaction), the sender should act as if the
1587 command or transaction in progress had received a temporary
1588 error (4xx).
1590 TURN (TURN)
1592 This command specifies that the receiver must either (1)
1593 send an OK reply and then take on the role of the
1594 sender-SMTP, or (2) send a refusal reply and retain the role
1595 of the receiver-SMTP.
1597 If program-A is currently the sender-SMTP and it sends the
1598 TURN command and receives an OK reply (250) then program-A
1599 becomes the receiver-SMTP. Program-A is then in the initial
1600 state as if the transmission channel just opened, and it
1601 then sends the 220 service ready greeting.
1603 If program-B is currently the receiver-SMTP and it receives
1604 the TURN command and sends an OK reply (250) then program-B
1605 becomes the sender-SMTP. Program-B is then in the initial
1606 state as if the transmission channel just opened, and it
1607 then expects to receive the 220 service ready greeting.
1609 To refuse to change roles the receiver sends the 502 reply.
1613 [Page 26] Postel
1614 \f
1617 RFC 821 August 1982
1618 Simple Mail Transfer Protocol
1622 There are restrictions on the order in which these command may
1623 be used.
1625 The first command in a session must be the HELO command.
1626 The HELO command may be used later in a session as well. If
1627 the HELO command argument is not acceptable a 501 failure
1628 reply must be returned and the receiver-SMTP must stay in
1629 the same state.
1631 The NOOP, HELP, EXPN, and VRFY commands can be used at any
1632 time during a session.
1634 The MAIL, SEND, SOML, or SAML commands begin a mail
1635 transaction. Once started a mail transaction consists of
1636 one of the transaction beginning commands, one or more RCPT
1637 commands, and a DATA command, in that order. A mail
1638 transaction may be aborted by the RSET command. There may
1639 be zero or more transactions in a session.
1641 If the transaction beginning command argument is not
1642 acceptable a 501 failure reply must be returned and the
1643 receiver-SMTP must stay in the same state. If the commands
1644 in a transaction are out of order a 503 failure reply must
1645 be returned and the receiver-SMTP must stay in the same
1646 state.
1648 The last command in a session must be the QUIT command. The
1649 QUIT command can not be used at any other time in a session.
1651 4.1.2. COMMAND SYNTAX
1653 The commands consist of a command code followed by an argument
1654 field. Command codes are four alphabetic characters. Upper
1655 and lower case alphabetic characters are to be treated
1656 identically. Thus, any of the following may represent the mail
1657 command:
1659 MAIL Mail mail MaIl mAIl
1661 This also applies to any symbols representing parameter values,
1662 such as "TO" or "to" for the forward-path. Command codes and
1663 the argument fields are separated by one or more spaces.
1664 However, within the reverse-path and forward-path arguments
1665 case is important. In particular, in some hosts the user
1666 "smith" is different from the user "Smith".
1671 Postel [Page 27]
1672 \f
1675 August 1982 RFC 821
1676 Simple Mail Transfer Protocol
1680 The argument field consists of a variable length character
1681 string ending with the character sequence <CRLF>. The receiver
1682 is to take no action until this sequence is received.
1684 Square brackets denote an optional argument field. If the
1685 option is not taken, the appropriate default is implied.
1729 [Page 28] Postel
1730 \f
1733 RFC 821 August 1982
1734 Simple Mail Transfer Protocol
1738 The following are the SMTP commands:
1740 HELO <SP> <domain> <CRLF>
1742 MAIL <SP> FROM:<reverse-path> <CRLF>
1744 RCPT <SP> TO:<forward-path> <CRLF>
1746 DATA <CRLF>
1748 RSET <CRLF>
1750 SEND <SP> FROM:<reverse-path> <CRLF>
1752 SOML <SP> FROM:<reverse-path> <CRLF>
1754 SAML <SP> FROM:<reverse-path> <CRLF>
1756 VRFY <SP> <string> <CRLF>
1758 EXPN <SP> <string> <CRLF>
1760 HELP [<SP> <string>] <CRLF>
1762 NOOP <CRLF>
1764 QUIT <CRLF>
1766 TURN <CRLF>
1787 Postel [Page 29]
1788 \f
1791 August 1982 RFC 821
1792 Simple Mail Transfer Protocol
1796 The syntax of the above argument fields (using BNF notation
1797 where applicable) is given below. The "..." notation indicates
1798 that a field may be repeated one or more times.
1800 <reverse-path> ::= <path>
1802 <forward-path> ::= <path>
1804 <path> ::= "<" [ <a-d-l> ":" ] <mailbox> ">"
1806 <a-d-l> ::= <at-domain> | <at-domain> "," <a-d-l>
1808 <at-domain> ::= "@" <domain>
1810 <domain> ::= <element> | <element> "." <domain>
1812 <element> ::= <name> | "#" <number> | "[" <dotnum> "]"
1814 <mailbox> ::= <local-part> "@" <domain>
1816 <local-part> ::= <dot-string> | <quoted-string>
1818 <name> ::= <a> <ldh-str> <let-dig>
1820 <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
1822 <let-dig> ::= <a> | <d>
1824 <let-dig-hyp> ::= <a> | <d> | "-"
1826 <dot-string> ::= <string> | <string> "." <dot-string>
1828 <string> ::= <char> | <char> <string>
1830 <quoted-string> ::= """ <qtext> """
1832 <qtext> ::= "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>
1834 <char> ::= <c> | "\" <x>
1836 <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>
1838 <number> ::= <d> | <d> <number>
1840 <CRLF> ::= <CR> <LF>
1845 [Page 30] Postel
1846 \f
1849 RFC 821 August 1982
1850 Simple Mail Transfer Protocol
1854 <CR> ::= the carriage return character (ASCII code 13)
1856 <LF> ::= the line feed character (ASCII code 10)
1858 <SP> ::= the space character (ASCII code 32)
1860 <snum> ::= one, two, or three digits representing a decimal
1861 integer value in the range 0 through 255
1863 <a> ::= any one of the 52 alphabetic characters A through Z
1864 in upper case and a through z in lower case
1866 <c> ::= any one of the 128 ASCII characters, but not any
1867 <special> or <SP>
1869 <d> ::= any one of the ten digits 0 through 9
1871 <q> ::= any one of the 128 ASCII characters except <CR>,
1872 <LF>, quote ("), or backslash (\)
1874 <x> ::= any one of the 128 ASCII characters (no exceptions)
1876 <special> ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "."
1877 | "," | ";" | ":" | "@" """ | the control
1878 characters (ASCII codes 0 through 31 inclusive and
1879 127)
1881 Note that the backslash, "\", is a quote character, which is
1882 used to indicate that the next character is to be used
1883 literally (instead of its normal interpretation). For example,
1884 "Joe\,Smith" could be used to indicate a single nine character
1885 user field with comma being the fourth character of the field.
1887 Hosts are generally known by names which are translated to
1888 addresses in each host. Note that the name elements of domains
1889 are the official names -- no use of nicknames or aliases is
1890 allowed.
1892 Sometimes a host is not known to the translation function and
1893 communication is blocked. To bypass this barrier two numeric
1894 forms are also allowed for host "names". One form is a decimal
1895 integer prefixed by a pound sign, "#", which indicates the
1896 number is the address of the host. Another form is four small
1897 decimal integers separated by dots and enclosed by brackets,
1898 e.g., "[123.255.37.2]", which indicates a 32-bit ARPA Internet
1899 Address in four 8-bit fields.
1903 Postel [Page 31]
1904 \f
1907 August 1982 RFC 821
1908 Simple Mail Transfer Protocol
1912 The time stamp line and the return path line are formally
1913 defined as follows:
1915 <return-path-line> ::= "Return-Path:" <SP><reverse-path><CRLF>
1917 <time-stamp-line> ::= "Received:" <SP> <stamp> <CRLF>
1919 <stamp> ::= <from-domain> <by-domain> <opt-info> ";"
1920 <daytime>
1922 <from-domain> ::= "FROM" <SP> <domain> <SP>
1924 <by-domain> ::= "BY" <SP> <domain> <SP>
1926 <opt-info> ::= [<via>] [<with>] [<id>] [<for>]
1928 <via> ::= "VIA" <SP> <link> <SP>
1930 <with> ::= "WITH" <SP> <protocol> <SP>
1932 <id> ::= "ID" <SP> <string> <SP>
1934 <for> ::= "FOR" <SP> <path> <SP>
1936 <link> ::= The standard names for links are registered with
1937 the Network Information Center.
1939 <protocol> ::= The standard names for protocols are
1940 registered with the Network Information Center.
1942 <daytime> ::= <SP> <date> <SP> <time>
1944 <date> ::= <dd> <SP> <mon> <SP> <yy>
1946 <time> ::= <hh> ":" <mm> ":" <ss> <SP> <zone>
1948 <dd> ::= the one or two decimal integer day of the month in
1949 the range 1 to 31.
1951 <mon> ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" |
1952 "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"
1954 <yy> ::= the two decimal integer year of the century in the
1955 range 00 to 99.
1961 [Page 32] Postel
1962 \f
1965 RFC 821 August 1982
1966 Simple Mail Transfer Protocol
1970 <hh> ::= the two decimal integer hour of the day in the
1971 range 00 to 24.
1973 <mm> ::= the two decimal integer minute of the hour in the
1974 range 00 to 59.
1976 <ss> ::= the two decimal integer second of the minute in the
1977 range 00 to 59.
1979 <zone> ::= "UT" for Universal Time (the default) or other
1980 time zone designator (as in [2]).
1984 -------------------------------------------------------------
1986 Return Path Example
1988 Return-Path: <@CHARLIE.ARPA,@BAKER.ARPA:JOE@ABLE.ARPA>
1990 Example 9
1992 -------------------------------------------------------------
1994 -------------------------------------------------------------
1996 Time Stamp Line Example
1998 Received: FROM ABC.ARPA BY XYZ.ARPA ; 22 OCT 81 09:23:59 PDT
2000 Received: from ABC.ARPA by XYZ.ARPA via TELENET with X25
2001 id M12345 for Smith@PDQ.ARPA ; 22 OCT 81 09:23:59 PDT
2003 Example 10
2005 -------------------------------------------------------------
2019 Postel [Page 33]
2020 \f
2023 August 1982 RFC 821
2024 Simple Mail Transfer Protocol
2028 4.2. SMTP REPLIES
2030 Replies to SMTP commands are devised to ensure the synchronization
2031 of requests and actions in the process of mail transfer, and to
2032 guarantee that the sender-SMTP always knows the state of the
2033 receiver-SMTP. Every command must generate exactly one reply.
2035 The details of the command-reply sequence are made explicit in
2036 Section 5.3 on Sequencing and Section 5.4 State Diagrams.
2038 An SMTP reply consists of a three digit number (transmitted as
2039 three alphanumeric characters) followed by some text. The number
2040 is intended for use by automata to determine what state to enter
2041 next; the text is meant for the human user. It is intended that
2042 the three digits contain enough encoded information that the
2043 sender-SMTP need not examine the text and may either discard it or
2044 pass it on to the user, as appropriate. In particular, the text
2045 may be receiver-dependent and context dependent, so there are
2046 likely to be varying texts for each reply code. A discussion of
2047 the theory of reply codes is given in Appendix E. Formally, a
2048 reply is defined to be the sequence: a three-digit code, <SP>,
2049 one line of text, and <CRLF>, or a multiline reply (as defined in
2050 Appendix E). Only the EXPN and HELP commands are expected to
2051 result in multiline replies in normal circumstances, however
2052 multiline replies are allowed for any command.
2077 [Page 34] Postel
2078 \f
2081 RFC 821 August 1982
2082 Simple Mail Transfer Protocol
2086 4.2.1. REPLY CODES BY FUNCTION GROUPS
2088 500 Syntax error, command unrecognized
2089 [This may include errors such as command line too long]
2090 501 Syntax error in parameters or arguments
2091 502 Command not implemented
2092 503 Bad sequence of commands
2093 504 Command parameter not implemented
2095 211 System status, or system help reply
2096 214 Help message
2097 [Information on how to use the receiver or the meaning of a
2098 particular non-standard command; this reply is useful only
2099 to the human user]
2101 220 <domain> Service ready
2102 221 <domain> Service closing transmission channel
2103 421 <domain> Service not available,
2104 closing transmission channel
2105 [This may be a reply to any command if the service knows it
2106 must shut down]
2108 250 Requested mail action okay, completed
2109 251 User not local; will forward to <forward-path>
2110 450 Requested mail action not taken: mailbox unavailable
2111 [E.g., mailbox busy]
2112 550 Requested action not taken: mailbox unavailable
2113 [E.g., mailbox not found, no access]
2114 451 Requested action aborted: error in processing
2115 551 User not local; please try <forward-path>
2116 452 Requested action not taken: insufficient system storage
2117 552 Requested mail action aborted: exceeded storage allocation
2118 553 Requested action not taken: mailbox name not allowed
2119 [E.g., mailbox syntax incorrect]
2120 354 Start mail input; end with <CRLF>.<CRLF>
2121 554 Transaction failed
2135 Postel [Page 35]
2136 \f
2139 August 1982 RFC 821
2140 Simple Mail Transfer Protocol
2144 4.2.2. NUMERIC ORDER LIST OF REPLY CODES
2146 211 System status, or system help reply
2147 214 Help message
2148 [Information on how to use the receiver or the meaning of a
2149 particular non-standard command; this reply is useful only
2150 to the human user]
2151 220 <domain> Service ready
2152 221 <domain> Service closing transmission channel
2153 250 Requested mail action okay, completed
2154 251 User not local; will forward to <forward-path>
2156 354 Start mail input; end with <CRLF>.<CRLF>
2158 421 <domain> Service not available,
2159 closing transmission channel
2160 [This may be a reply to any command if the service knows it
2161 must shut down]
2162 450 Requested mail action not taken: mailbox unavailable
2163 [E.g., mailbox busy]
2164 451 Requested action aborted: local error in processing
2165 452 Requested action not taken: insufficient system storage
2167 500 Syntax error, command unrecognized
2168 [This may include errors such as command line too long]
2169 501 Syntax error in parameters or arguments
2170 502 Command not implemented
2171 503 Bad sequence of commands
2172 504 Command parameter not implemented
2173 550 Requested action not taken: mailbox unavailable
2174 [E.g., mailbox not found, no access]
2175 551 User not local; please try <forward-path>
2176 552 Requested mail action aborted: exceeded storage allocation
2177 553 Requested action not taken: mailbox name not allowed
2178 [E.g., mailbox syntax incorrect]
2179 554 Transaction failed
2193 [Page 36] Postel
2194 \f
2197 RFC 821 August 1982
2198 Simple Mail Transfer Protocol
2202 4.3. SEQUENCING OF COMMANDS AND REPLIES
2204 The communication between the sender and receiver is intended to
2205 be an alternating dialogue, controlled by the sender. As such,
2206 the sender issues a command and the receiver responds with a
2207 reply. The sender must wait for this response before sending
2208 further commands.
2210 One important reply is the connection greeting. Normally, a
2211 receiver will send a 220 "Service ready" reply when the connection
2212 is completed. The sender should wait for this greeting message
2213 before sending any commands.
2215 Note: all the greeting type replies have the official name of
2216 the server host as the first word following the reply code.
2218 For example,
2220 220 <SP> USC-ISIF.ARPA <SP> Service ready <CRLF>
2222 The table below lists alternative success and failure replies for
2223 each command. These must be strictly adhered to; a receiver may
2224 substitute text in the replies, but the meaning and action implied
2225 by the code numbers and by the specific command reply sequence
2226 cannot be altered.
2228 COMMAND-REPLY SEQUENCES
2230 Each command is listed with its possible replies. The prefixes
2231 used before the possible replies are "P" for preliminary (not
2232 used in SMTP), "I" for intermediate, "S" for success, "F" for
2233 failure, and "E" for error. The 421 reply (service not
2234 available, closing transmission channel) may be given to any
2235 command if the SMTP-receiver knows it must shut down. This
2236 listing forms the basis for the State Diagrams in Section 4.4.
2238 CONNECTION ESTABLISHMENT
2239 S: 220
2240 F: 421
2241 HELO
2242 S: 250
2243 E: 500, 501, 504, 421
2244 MAIL
2245 S: 250
2246 F: 552, 451, 452
2247 E: 500, 501, 421
2251 Postel [Page 37]
2252 \f
2255 August 1982 RFC 821
2256 Simple Mail Transfer Protocol
2260 RCPT
2261 S: 250, 251
2262 F: 550, 551, 552, 553, 450, 451, 452
2263 E: 500, 501, 503, 421
2264 DATA
2265 I: 354 -> data -> S: 250
2266 F: 552, 554, 451, 452
2267 F: 451, 554
2268 E: 500, 501, 503, 421
2269 RSET
2270 S: 250
2271 E: 500, 501, 504, 421
2272 SEND
2273 S: 250
2274 F: 552, 451, 452
2275 E: 500, 501, 502, 421
2276 SOML
2277 S: 250
2278 F: 552, 451, 452
2279 E: 500, 501, 502, 421
2280 SAML
2281 S: 250
2282 F: 552, 451, 452
2283 E: 500, 501, 502, 421
2284 VRFY
2285 S: 250, 251
2286 F: 550, 551, 553
2287 E: 500, 501, 502, 504, 421
2288 EXPN
2289 S: 250
2290 F: 550
2291 E: 500, 501, 502, 504, 421
2292 HELP
2293 S: 211, 214
2294 E: 500, 501, 502, 504, 421
2295 NOOP
2296 S: 250
2297 E: 500, 421
2298 QUIT
2299 S: 221
2300 E: 500
2301 TURN
2302 S: 250
2303 F: 502
2304 E: 500, 503
2309 [Page 38] Postel
2310 \f
2313 RFC 821 August 1982
2314 Simple Mail Transfer Protocol
2318 4.4. STATE DIAGRAMS
2320 Following are state diagrams for a simple-minded SMTP
2321 implementation. Only the first digit of the reply codes is used.
2322 There is one state diagram for each group of SMTP commands. The
2323 command groupings were determined by constructing a model for each
2324 command and then collecting together the commands with
2325 structurally identical models.
2327 For each command there are three possible outcomes: "success"
2328 (S), "failure" (F), and "error" (E). In the state diagrams below
2329 we use the symbol B for "begin", and the symbol W for "wait for
2330 reply".
2332 First, the diagram that represents most of the SMTP commands:
2335 1,3 +---+
2336 ----------->| E |
2337 | +---+
2338 |
2339 +---+ cmd +---+ 2 +---+
2340 | B |---------->| W |---------->| S |
2341 +---+ +---+ +---+
2342 |
2343 | 4,5 +---+
2344 ----------->| F |
2345 +---+
2348 This diagram models the commands:
2350 HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP,
2351 NOOP, QUIT, TURN.
2367 Postel [Page 39]
2368 \f
2371 August 1982 RFC 821
2372 Simple Mail Transfer Protocol
2376 A more complex diagram models the DATA command:
2379 +---+ DATA +---+ 1,2 +---+
2380 | B |---------->| W |-------------------->| E |
2381 +---+ +---+ ------------>+---+
2382 3| |4,5 |
2383 | | |
2384 -------------- ----- |
2385 | | | +---+
2386 | ---------- -------->| S |
2387 | | | | +---+
2388 | | ------------
2389 | | | |
2390 V 1,3| |2 |
2391 +---+ data +---+ --------------->+---+
2392 | |---------->| W | | F |
2393 +---+ +---+-------------------->+---+
2394 4,5
2397 Note that the "data" here is a series of lines sent from the
2398 sender to the receiver with no response expected until the last
2399 line is sent.
2425 [Page 40] Postel
2426 \f
2429 RFC 821 August 1982
2430 Simple Mail Transfer Protocol
2434 4.5. DETAILS
2436 4.5.1. MINIMUM IMPLEMENTATION
2438 In order to make SMTP workable, the following minimum
2439 implementation is required for all receivers:
2441 COMMANDS -- HELO
2442 MAIL
2443 RCPT
2444 DATA
2445 RSET
2446 NOOP
2447 QUIT
2449 4.5.2. TRANSPARENCY
2451 Without some provision for data transparency the character
2452 sequence "<CRLF>.<CRLF>" ends the mail text and cannot be sent
2453 by the user. In general, users are not aware of such
2454 "forbidden" sequences. To allow all user composed text to be
2455 transmitted transparently the following procedures are used.
2457 1. Before sending a line of mail text the sender-SMTP checks
2458 the first character of the line. If it is a period, one
2459 additional period is inserted at the beginning of the line.
2461 2. When a line of mail text is received by the receiver-SMTP
2462 it checks the line. If the line is composed of a single
2463 period it is the end of mail. If the first character is a
2464 period and there are other characters on the line, the first
2465 character is deleted.
2467 The mail data may contain any of the 128 ASCII characters. All
2468 characters are to be delivered to the recipient's mailbox
2469 including format effectors and other control characters. If
2470 the transmission channel provides an 8-bit byte (octets) data
2471 stream, the 7-bit ASCII codes are transmitted right justified
2472 in the octets with the high order bits cleared to zero.
2474 In some systems it may be necessary to transform the data as
2475 it is received and stored. This may be necessary for hosts
2476 that use a different character set than ASCII as their local
2477 character set, or that store data in records rather than
2483 Postel [Page 41]
2484 \f
2487 August 1982 RFC 821
2488 Simple Mail Transfer Protocol
2492 strings. If such transforms are necessary, they must be
2493 reversible -- especially if such transforms are applied to
2494 mail being relayed.
2496 4.5.3. SIZES
2498 There are several objects that have required minimum maximum
2499 sizes. That is, every implementation must be able to receive
2500 objects of at least these sizes, but must not send objects
2501 larger than these sizes.
2504 ****************************************************
2505 * *
2506 * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION *
2507 * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
2508 * OF THESE OBJECTS SHOULD BE USED. *
2509 * *
2510 ****************************************************
2512 user
2514 The maximum total length of a user name is 64 characters.
2516 domain
2518 The maximum total length of a domain name or number is 64
2519 characters.
2521 path
2523 The maximum total length of a reverse-path or
2524 forward-path is 256 characters (including the punctuation
2525 and element separators).
2527 command line
2529 The maximum total length of a command line including the
2530 command word and the <CRLF> is 512 characters.
2532 reply line
2534 The maximum total length of a reply line including the
2535 reply code and the <CRLF> is 512 characters.
2541 [Page 42] Postel
2542 \f
2545 RFC 821 August 1982
2546 Simple Mail Transfer Protocol
2550 text line
2552 The maximum total length of a text line including the
2553 <CRLF> is 1000 characters (but not counting the leading
2554 dot duplicated for transparency).
2556 recipients buffer
2558 The maximum total number of recipients that must be
2559 buffered is 100 recipients.
2562 ****************************************************
2563 * *
2564 * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION *
2565 * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
2566 * OF THESE OBJECTS SHOULD BE USED. *
2567 * *
2568 ****************************************************
2570 Errors due to exceeding these limits may be reported by using
2571 the reply codes, for example:
2573 500 Line too long.
2575 501 Path too long
2577 552 Too many recipients.
2579 552 Too much mail data.
2599 Postel [Page 43]
2600 \f
2603 August 1982 RFC 821
2604 Simple Mail Transfer Protocol
2608 APPENDIX A
2610 TCP Transport service
2612 The Transmission Control Protocol [3] is used in the ARPA
2613 Internet, and in any network following the US DoD standards for
2614 internetwork protocols.
2616 Connection Establishment
2618 The SMTP transmission channel is a TCP connection established
2619 between the sender process port U and the receiver process port
2620 L. This single full duplex connection is used as the
2621 transmission channel. This protocol is assigned the service
2622 port 25 (31 octal), that is L=25.
2624 Data Transfer
2626 The TCP connection supports the transmission of 8-bit bytes.
2627 The SMTP data is 7-bit ASCII characters. Each character is
2628 transmitted as an 8-bit byte with the high-order bit cleared to
2629 zero.
2657 [Page 44] Postel
2658 \f
2661 RFC 821 August 1982
2662 Simple Mail Transfer Protocol
2666 APPENDIX B
2668 NCP Transport service
2670 The ARPANET Host-to-Host Protocol [4] (implemented by the Network
2671 Control Program) may be used in the ARPANET.
2673 Connection Establishment
2675 The SMTP transmission channel is established via NCP between
2676 the sender process socket U and receiver process socket L. The
2677 Initial Connection Protocol [5] is followed resulting in a pair
2678 of simplex connections. This pair of connections is used as
2679 the transmission channel. This protocol is assigned the
2680 contact socket 25 (31 octal), that is L=25.
2682 Data Transfer
2684 The NCP data connections are established in 8-bit byte mode.
2685 The SMTP data is 7-bit ASCII characters. Each character is
2686 transmitted as an 8-bit byte with the high-order bit cleared to
2687 zero.
2715 Postel [Page 45]
2716 \f
2719 August 1982 RFC 821
2720 Simple Mail Transfer Protocol
2724 APPENDIX C
2726 NITS
2728 The Network Independent Transport Service [6] may be used.
2730 Connection Establishment
2732 The SMTP transmission channel is established via NITS between
2733 the sender process and receiver process. The sender process
2734 executes the CONNECT primitive, and the waiting receiver
2735 process executes the ACCEPT primitive.
2737 Data Transfer
2739 The NITS connection supports the transmission of 8-bit bytes.
2740 The SMTP data is 7-bit ASCII characters. Each character is
2741 transmitted as an 8-bit byte with the high-order bit cleared to
2742 zero.
2773 [Page 46] Postel
2774 \f
2777 RFC 821 August 1982
2778 Simple Mail Transfer Protocol
2782 APPENDIX D
2784 X.25 Transport service
2786 It may be possible to use the X.25 service [7] as provided by the
2787 Public Data Networks directly, however, it is suggested that a
2788 reliable end-to-end protocol such as TCP be used on top of X.25
2789 connections.
2831 Postel [Page 47]
2832 \f
2835 August 1982 RFC 821
2836 Simple Mail Transfer Protocol
2840 APPENDIX E
2842 Theory of Reply Codes
2844 The three digits of the reply each have a special significance.
2845 The first digit denotes whether the response is good, bad or
2846 incomplete. An unsophisticated sender-SMTP will be able to
2847 determine its next action (proceed as planned, redo, retrench,
2848 etc.) by simply examining this first digit. A sender-SMTP that
2849 wants to know approximately what kind of error occurred (e.g.,
2850 mail system error, command syntax error) may examine the second
2851 digit, reserving the third digit for the finest gradation of
2852 information.
2854 There are five values for the first digit of the reply code:
2856 1yz Positive Preliminary reply
2858 The command has been accepted, but the requested action
2859 is being held in abeyance, pending confirmation of the
2860 information in this reply. The sender-SMTP should send
2861 another command specifying whether to continue or abort
2862 the action.
2864 [Note: SMTP does not have any commands that allow this
2865 type of reply, and so does not have the continue or
2866 abort commands.]
2868 2yz Positive Completion reply
2870 The requested action has been successfully completed. A
2871 new request may be initiated.
2873 3yz Positive Intermediate reply
2875 The command has been accepted, but the requested action
2876 is being held in abeyance, pending receipt of further
2877 information. The sender-SMTP should send another command
2878 specifying this information. This reply is used in
2879 command sequence groups.
2881 4yz Transient Negative Completion reply
2883 The command was not accepted and the requested action did
2884 not occur. However, the error condition is temporary and
2885 the action may be requested again. The sender should
2889 [Page 48] Postel
2890 \f
2893 RFC 821 August 1982
2894 Simple Mail Transfer Protocol
2898 return to the beginning of the command sequence (if any).
2899 It is difficult to assign a meaning to "transient" when
2900 two different sites (receiver- and sender- SMTPs) must
2901 agree on the interpretation. Each reply in this category
2902 might have a different time value, but the sender-SMTP is
2903 encouraged to try again. A rule of thumb to determine if
2904 a reply fits into the 4yz or the 5yz category (see below)
2905 is that replies are 4yz if they can be repeated without
2906 any change in command form or in properties of the sender
2907 or receiver. (E.g., the command is repeated identically
2908 and the receiver does not put up a new implementation.)
2910 5yz Permanent Negative Completion reply
2912 The command was not accepted and the requested action did
2913 not occur. The sender-SMTP is discouraged from repeating
2914 the exact request (in the same sequence). Even some
2915 "permanent" error conditions can be corrected, so the
2916 human user may want to direct the sender-SMTP to
2917 reinitiate the command sequence by direct action at some
2918 point in the future (e.g., after the spelling has been
2919 changed, or the user has altered the account status).
2921 The second digit encodes responses in specific categories:
2923 x0z Syntax -- These replies refer to syntax errors,
2924 syntactically correct commands that don't fit any
2925 functional category, and unimplemented or superfluous
2926 commands.
2928 x1z Information -- These are replies to requests for
2929 information, such as status or help.
2931 x2z Connections -- These are replies referring to the
2932 transmission channel.
2934 x3z Unspecified as yet.
2936 x4z Unspecified as yet.
2938 x5z Mail system -- These replies indicate the status of
2939 the receiver mail system vis-a-vis the requested
2940 transfer or other mail system action.
2942 The third digit gives a finer gradation of meaning in each
2943 category specified by the second digit. The list of replies
2947 Postel [Page 49]
2948 \f
2951 August 1982 RFC 821
2952 Simple Mail Transfer Protocol
2956 illustrates this. Each reply text is recommended rather than
2957 mandatory, and may even change according to the command with
2958 which it is associated. On the other hand, the reply codes
2959 must strictly follow the specifications in this section.
2960 Receiver implementations should not invent new codes for
2961 slightly different situations from the ones described here, but
2962 rather adapt codes already defined.
2964 For example, a command such as NOOP whose successful execution
2965 does not offer the sender-SMTP any new information will return
2966 a 250 reply. The response is 502 when the command requests an
2967 unimplemented non-site-specific action. A refinement of that
2968 is the 504 reply for a command that is implemented, but that
2969 requests an unimplemented parameter.
2971 The reply text may be longer than a single line; in these cases
2972 the complete text must be marked so the sender-SMTP knows when it
2973 can stop reading the reply. This requires a special format to
2974 indicate a multiple line reply.
2976 The format for multiline replies requires that every line,
2977 except the last, begin with the reply code, followed
2978 immediately by a hyphen, "-" (also known as minus), followed by
2979 text. The last line will begin with the reply code, followed
2980 immediately by <SP>, optionally some text, and <CRLF>.
2982 For example:
2983 123-First line
2984 123-Second line
2985 123-234 text beginning with numbers
2986 123 The last line
2988 In many cases the sender-SMTP then simply needs to search for
2989 the reply code followed by <SP> at the beginning of a line, and
2990 ignore all preceding lines. In a few cases, there is important
2991 data for the sender in the reply "text". The sender will know
2992 these cases from the current context.
3005 [Page 50] Postel
3006 \f
3009 RFC 821 August 1982
3010 Simple Mail Transfer Protocol
3014 APPENDIX F
3016 Scenarios
3018 This section presents complete scenarios of several types of SMTP
3019 sessions.
3021 A Typical SMTP Transaction Scenario
3023 This SMTP example shows mail sent by Smith at host USC-ISIF, to
3024 Jones, Green, and Brown at host BBN-UNIX. Here we assume that
3025 host USC-ISIF contacts host BBN-UNIX directly. The mail is
3026 accepted for Jones and Brown. Green does not have a mailbox at
3027 host BBN-UNIX.
3029 -------------------------------------------------------------
3031 R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
3032 S: HELO USC-ISIF.ARPA
3033 R: 250 BBN-UNIX.ARPA
3035 S: MAIL FROM:<Smith@USC-ISIF.ARPA>
3036 R: 250 OK
3038 S: RCPT TO:<Jones@BBN-UNIX.ARPA>
3039 R: 250 OK
3041 S: RCPT TO:<Green@BBN-UNIX.ARPA>
3042 R: 550 No such user here
3044 S: RCPT TO:<Brown@BBN-UNIX.ARPA>
3045 R: 250 OK
3047 S: DATA
3048 R: 354 Start mail input; end with <CRLF>.<CRLF>
3049 S: Blah blah blah...
3050 S: ...etc. etc. etc.
3051 S: .
3052 R: 250 OK
3054 S: QUIT
3055 R: 221 BBN-UNIX.ARPA Service closing transmission channel
3057 Scenario 1
3059 -------------------------------------------------------------
3063 Postel [Page 51]
3064 \f
3067 August 1982 RFC 821
3068 Simple Mail Transfer Protocol
3072 Aborted SMTP Transaction Scenario
3074 -------------------------------------------------------------
3076 R: 220 MIT-Multics.ARPA Simple Mail Transfer Service Ready
3077 S: HELO ISI-VAXA.ARPA
3078 R: 250 MIT-Multics.ARPA
3080 S: MAIL FROM:<Smith@ISI-VAXA.ARPA>
3081 R: 250 OK
3083 S: RCPT TO:<Jones@MIT-Multics.ARPA>
3084 R: 250 OK
3086 S: RCPT TO:<Green@MIT-Multics.ARPA>
3087 R: 550 No such user here
3089 S: RSET
3090 R: 250 OK
3092 S: QUIT
3093 R: 221 MIT-Multics.ARPA Service closing transmission channel
3095 Scenario 2
3097 -------------------------------------------------------------
3121 [Page 52] Postel
3122 \f
3125 RFC 821 August 1982
3126 Simple Mail Transfer Protocol
3130 Relayed Mail Scenario
3132 -------------------------------------------------------------
3134 Step 1 -- Source Host to Relay Host
3136 R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
3137 S: HELO MIT-AI.ARPA
3138 R: 250 USC-ISIE.ARPA
3140 S: MAIL FROM:<JQP@MIT-AI.ARPA>
3141 R: 250 OK
3143 S: RCPT TO:<@USC-ISIE.ARPA:Jones@BBN-VAX.ARPA>
3144 R: 250 OK
3146 S: DATA
3147 R: 354 Start mail input; end with <CRLF>.<CRLF>
3148 S: Date: 2 Nov 81 22:33:44
3149 S: From: John Q. Public <JQP@MIT-AI.ARPA>
3150 S: Subject: The Next Meeting of the Board
3151 S: To: Jones@BBN-Vax.ARPA
3152 S:
3153 S: Bill:
3154 S: The next meeting of the board of directors will be
3155 S: on Tuesday.
3156 S: John.
3157 S: .
3158 R: 250 OK
3160 S: QUIT
3161 R: 221 USC-ISIE.ARPA Service closing transmission channel
3179 Postel [Page 53]
3180 \f
3183 August 1982 RFC 821
3184 Simple Mail Transfer Protocol
3188 Step 2 -- Relay Host to Destination Host
3190 R: 220 BBN-VAX.ARPA Simple Mail Transfer Service Ready
3191 S: HELO USC-ISIE.ARPA
3192 R: 250 BBN-VAX.ARPA
3194 S: MAIL FROM:<@USC-ISIE.ARPA:JQP@MIT-AI.ARPA>
3195 R: 250 OK
3197 S: RCPT TO:<Jones@BBN-VAX.ARPA>
3198 R: 250 OK
3200 S: DATA
3201 R: 354 Start mail input; end with <CRLF>.<CRLF>
3202 S: Received: from MIT-AI.ARPA by USC-ISIE.ARPA ;
3203 2 Nov 81 22:40:10 UT
3204 S: Date: 2 Nov 81 22:33:44
3205 S: From: John Q. Public <JQP@MIT-AI.ARPA>
3206 S: Subject: The Next Meeting of the Board
3207 S: To: Jones@BBN-Vax.ARPA
3208 S:
3209 S: Bill:
3210 S: The next meeting of the board of directors will be
3211 S: on Tuesday.
3212 S: John.
3213 S: .
3214 R: 250 OK
3216 S: QUIT
3217 R: 221 USC-ISIE.ARPA Service closing transmission channel
3219 Scenario 3
3221 -------------------------------------------------------------
3237 [Page 54] Postel
3238 \f
3241 RFC 821 August 1982
3242 Simple Mail Transfer Protocol
3246 Verifying and Sending Scenario
3248 -------------------------------------------------------------
3250 R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
3251 S: HELO MIT-MC.ARPA
3252 R: 250 SU-SCORE.ARPA
3254 S: VRFY Crispin
3255 R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA>
3257 S: SEND FROM:<EAK@MIT-MC.ARPA>
3258 R: 250 OK
3260 S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
3261 R: 250 OK
3263 S: DATA
3264 R: 354 Start mail input; end with <CRLF>.<CRLF>
3265 S: Blah blah blah...
3266 S: ...etc. etc. etc.
3267 S: .
3268 R: 250 OK
3270 S: QUIT
3271 R: 221 SU-SCORE.ARPA Service closing transmission channel
3273 Scenario 4
3275 -------------------------------------------------------------
3295 Postel [Page 55]
3296 \f
3299 August 1982 RFC 821
3300 Simple Mail Transfer Protocol
3304 Sending and Mailing Scenarios
3306 First the user's name is verified, then an attempt is made to
3307 send to the user's terminal. When that fails, the messages is
3308 mailed to the user's mailbox.
3310 -------------------------------------------------------------
3312 R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
3313 S: HELO MIT-MC.ARPA
3314 R: 250 SU-SCORE.ARPA
3316 S: VRFY Crispin
3317 R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA>
3319 S: SEND FROM:<EAK@MIT-MC.ARPA>
3320 R: 250 OK
3322 S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
3323 R: 450 User not active now
3325 S: RSET
3326 R: 250 OK
3328 S: MAIL FROM:<EAK@MIT-MC.ARPA>
3329 R: 250 OK
3331 S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
3332 R: 250 OK
3334 S: DATA
3335 R: 354 Start mail input; end with <CRLF>.<CRLF>
3336 S: Blah blah blah...
3337 S: ...etc. etc. etc.
3338 S: .
3339 R: 250 OK
3341 S: QUIT
3342 R: 221 SU-SCORE.ARPA Service closing transmission channel
3344 Scenario 5
3346 -------------------------------------------------------------
3353 [Page 56] Postel
3354 \f
3357 RFC 821 August 1982
3358 Simple Mail Transfer Protocol
3362 Doing the preceding scenario more efficiently.
3364 -------------------------------------------------------------
3366 R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
3367 S: HELO MIT-MC.ARPA
3368 R: 250 SU-SCORE.ARPA
3370 S: VRFY Crispin
3371 R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA>
3373 S: SOML FROM:<EAK@MIT-MC.ARPA>
3374 R: 250 OK
3376 S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
3377 R: 250 User not active now, so will do mail.
3379 S: DATA
3380 R: 354 Start mail input; end with <CRLF>.<CRLF>
3381 S: Blah blah blah...
3382 S: ...etc. etc. etc.
3383 S: .
3384 R: 250 OK
3386 S: QUIT
3387 R: 221 SU-SCORE.ARPA Service closing transmission channel
3389 Scenario 6
3391 -------------------------------------------------------------
3411 Postel [Page 57]
3412 \f
3415 August 1982 RFC 821
3416 Simple Mail Transfer Protocol
3420 Mailing List Scenario
3422 First each of two mailing lists are expanded in separate sessions
3423 with different hosts. Then the message is sent to everyone that
3424 appeared on either list (but no duplicates) via a relay host.
3426 -------------------------------------------------------------
3428 Step 1 -- Expanding the First List
3430 R: 220 MIT-AI.ARPA Simple Mail Transfer Service Ready
3431 S: HELO SU-SCORE.ARPA
3432 R: 250 MIT-AI.ARPA
3434 S: EXPN Example-People
3435 R: 250-<ABC@MIT-MC.ARPA>
3436 R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA>
3437 R: 250-Xenon Y. Zither <XYZ@MIT-AI.ARPA>
3438 R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
3439 R: 250-<joe@foo-unix.ARPA>
3440 R: 250 <xyz@bar-unix.ARPA>
3442 S: QUIT
3443 R: 221 MIT-AI.ARPA Service closing transmission channel
3469 [Page 58] Postel
3470 \f
3473 RFC 821 August 1982
3474 Simple Mail Transfer Protocol
3478 Step 2 -- Expanding the Second List
3480 R: 220 MIT-MC.ARPA Simple Mail Transfer Service Ready
3481 S: HELO SU-SCORE.ARPA
3482 R: 250 MIT-MC.ARPA
3484 S: EXPN Interested-Parties
3485 R: 250-Al Calico <ABC@MIT-MC.ARPA>
3486 R: 250-<XYZ@MIT-AI.ARPA>
3487 R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
3488 R: 250-<fred@BBN-UNIX.ARPA>
3489 R: 250 <xyz@bar-unix.ARPA>
3491 S: QUIT
3492 R: 221 MIT-MC.ARPA Service closing transmission channel
3527 Postel [Page 59]
3528 \f
3531 August 1982 RFC 821
3532 Simple Mail Transfer Protocol
3536 Step 3 -- Mailing to All via a Relay Host
3538 R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
3539 S: HELO SU-SCORE.ARPA
3540 R: 250 USC-ISIE.ARPA
3542 S: MAIL FROM:<Account.Person@SU-SCORE.ARPA>
3543 R: 250 OK
3544 S: RCPT TO:<@USC-ISIE.ARPA:ABC@MIT-MC.ARPA>
3545 R: 250 OK
3546 S: RCPT TO:<@USC-ISIE.ARPA:Fonebone@USC-ISIQA.ARPA>
3547 R: 250 OK
3548 S: RCPT TO:<@USC-ISIE.ARPA:XYZ@MIT-AI.ARPA>
3549 R: 250 OK
3550 S: RCPT
3551 TO:<@USC-ISIE.ARPA,@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
3552 R: 250 OK
3553 S: RCPT TO:<@USC-ISIE.ARPA:joe@FOO-UNIX.ARPA>
3554 R: 250 OK
3555 S: RCPT TO:<@USC-ISIE.ARPA:xyz@BAR-UNIX.ARPA>
3556 R: 250 OK
3557 S: RCPT TO:<@USC-ISIE.ARPA:fred@BBN-UNIX.ARPA>
3558 R: 250 OK
3560 S: DATA
3561 R: 354 Start mail input; end with <CRLF>.<CRLF>
3562 S: Blah blah blah...
3563 S: ...etc. etc. etc.
3564 S: .
3565 R: 250 OK
3567 S: QUIT
3568 R: 221 USC-ISIE.ARPA Service closing transmission channel
3570 Scenario 7
3572 -------------------------------------------------------------
3585 [Page 60] Postel
3586 \f
3589 RFC 821 August 1982
3590 Simple Mail Transfer Protocol
3594 Forwarding Scenarios
3596 -------------------------------------------------------------
3598 R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready
3599 S: HELO LBL-UNIX.ARPA
3600 R: 250 USC-ISIF.ARPA
3602 S: MAIL FROM:<mo@LBL-UNIX.ARPA>
3603 R: 250 OK
3605 S: RCPT TO:<fred@USC-ISIF.ARPA>
3606 R: 251 User not local; will forward to <Jones@USC-ISI.ARPA>
3608 S: DATA
3609 R: 354 Start mail input; end with <CRLF>.<CRLF>
3610 S: Blah blah blah...
3611 S: ...etc. etc. etc.
3612 S: .
3613 R: 250 OK
3615 S: QUIT
3616 R: 221 USC-ISIF.ARPA Service closing transmission channel
3618 Scenario 8
3620 -------------------------------------------------------------
3643 Postel [Page 61]
3644 \f
3647 August 1982 RFC 821
3648 Simple Mail Transfer Protocol
3652 -------------------------------------------------------------
3654 Step 1 -- Trying the Mailbox at the First Host
3656 R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready
3657 S: HELO LBL-UNIX.ARPA
3658 R: 250 USC-ISIF.ARPA
3660 S: MAIL FROM:<mo@LBL-UNIX.ARPA>
3661 R: 250 OK
3663 S: RCPT TO:<fred@USC-ISIF.ARPA>
3664 R: 251 User not local; will forward to <Jones@USC-ISI.ARPA>
3666 S: RSET
3667 R: 250 OK
3669 S: QUIT
3670 R: 221 USC-ISIF.ARPA Service closing transmission channel
3672 Step 2 -- Delivering the Mail at the Second Host
3674 R: 220 USC-ISI.ARPA Simple Mail Transfer Service Ready
3675 S: HELO LBL-UNIX.ARPA
3676 R: 250 USC-ISI.ARPA
3678 S: MAIL FROM:<mo@LBL-UNIX.ARPA>
3679 R: 250 OK
3681 S: RCPT TO:<Jones@USC-ISI.ARPA>
3682 R: OK
3684 S: DATA
3685 R: 354 Start mail input; end with <CRLF>.<CRLF>
3686 S: Blah blah blah...
3687 S: ...etc. etc. etc.
3688 S: .
3689 R: 250 OK
3691 S: QUIT
3692 R: 221 USC-ISI.ARPA Service closing transmission channel
3694 Scenario 9
3696 -------------------------------------------------------------
3701 [Page 62] Postel
3702 \f
3705 RFC 821 August 1982
3706 Simple Mail Transfer Protocol
3710 Too Many Recipients Scenario
3712 -------------------------------------------------------------
3714 R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready
3715 S: HELO USC-ISIF.ARPA
3716 R: 250 BERKELEY.ARPA
3718 S: MAIL FROM:<Postel@USC-ISIF.ARPA>
3719 R: 250 OK
3721 S: RCPT TO:<fabry@BERKELEY.ARPA>
3722 R: 250 OK
3724 S: RCPT TO:<eric@BERKELEY.ARPA>
3725 R: 552 Recipient storage full, try again in another transaction
3727 S: DATA
3728 R: 354 Start mail input; end with <CRLF>.<CRLF>
3729 S: Blah blah blah...
3730 S: ...etc. etc. etc.
3731 S: .
3732 R: 250 OK
3734 S: MAIL FROM:<Postel@USC-ISIF.ARPA>
3735 R: 250 OK
3737 S: RCPT TO:<eric@BERKELEY.ARPA>
3738 R: 250 OK
3740 S: DATA
3741 R: 354 Start mail input; end with <CRLF>.<CRLF>
3742 S: Blah blah blah...
3743 S: ...etc. etc. etc.
3744 S: .
3745 R: 250 OK
3747 S: QUIT
3748 R: 221 BERKELEY.ARPA Service closing transmission channel
3750 Scenario 10
3752 -------------------------------------------------------------
3754 Note that a real implementation must handle many recipients as
3755 specified in Section 4.5.3.
3759 Postel [Page 63]
3760 \f
3763 August 1982 RFC 821
3764 Simple Mail Transfer Protocol
3768 GLOSSARY
3770 ASCII
3772 American Standard Code for Information Interchange [1].
3774 command
3776 A request for a mail service action sent by the sender-SMTP to the
3777 receiver-SMTP.
3779 domain
3781 The hierarchially structured global character string address of a
3782 host computer in the mail system.
3784 end of mail data indication
3786 A special sequence of characters that indicates the end of the
3787 mail data. In particular, the five characters carriage return,
3788 line feed, period, carriage return, line feed, in that order.
3790 host
3792 A computer in the internetwork environment on which mailboxes or
3793 SMTP processes reside.
3795 line
3797 A a sequence of ASCII characters ending with a <CRLF>.
3799 mail data
3801 A sequence of ASCII characters of arbitrary length, which conforms
3802 to the standard set in the Standard for the Format of ARPA
3803 Internet Text Messages (RFC 822 [2]).
3805 mailbox
3807 A character string (address) which identifies a user to whom mail
3808 is to be sent. Mailbox normally consists of the host and user
3809 specifications. The standard mailbox naming convention is defined
3810 to be "user@domain". Additionally, the "container" in which mail
3811 is stored.
3817 [Page 64] Postel
3818 \f
3821 RFC 821 August 1982
3822 Simple Mail Transfer Protocol
3826 receiver-SMTP process
3828 A process which transfers mail in cooperation with a sender-SMTP
3829 process. It waits for a connection to be established via the
3830 transport service. It receives SMTP commands from the
3831 sender-SMTP, sends replies, and performs the specified operations.
3833 reply
3835 A reply is an acknowledgment (positive or negative) sent from
3836 receiver to sender via the transmission channel in response to a
3837 command. The general form of a reply is a completion code
3838 (including error codes) followed by a text string. The codes are
3839 for use by programs and the text is usually intended for human
3840 users.
3842 sender-SMTP process
3844 A process which transfers mail in cooperation with a receiver-SMTP
3845 process. A local language may be used in the user interface
3846 command/reply dialogue. The sender-SMTP initiates the transport
3847 service connection. It initiates SMTP commands, receives replies,
3848 and governs the transfer of mail.
3850 session
3852 The set of exchanges that occur while the transmission channel is
3853 open.
3855 transaction
3857 The set of exchanges required for one message to be transmitted
3858 for one or more recipients.
3860 transmission channel
3862 A full-duplex communication path between a sender-SMTP and a
3863 receiver-SMTP for the exchange of commands, replies, and mail
3864 text.
3866 transport service
3868 Any reliable stream-oriented data communication services. For
3869 example, NCP, TCP, NITS.
3875 Postel [Page 65]
3876 \f
3879 August 1982 RFC 821
3880 Simple Mail Transfer Protocol
3884 user
3886 A human being (or a process on behalf of a human being) wishing to
3887 obtain mail transfer service. In addition, a recipient of
3888 computer mail.
3890 word
3892 A sequence of printing characters.
3894 <CRLF>
3896 The characters carriage return and line feed (in that order).
3898 <SP>
3900 The space character.
3933 [Page 66] Postel
3934 \f
3937 RFC 821 August 1982
3938 Simple Mail Transfer Protocol
3942 REFERENCES
3944 [1] ASCII
3946 ASCII, "USA Code for Information Interchange", United States of
3947 America Standards Institute, X3.4, 1968. Also in: Feinler, E.
3948 and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for
3949 the Defense Communications Agency by SRI International, Menlo
3950 Park, California, Revised January 1978.
3952 [2] RFC 822
3954 Crocker, D., "Standard for the Format of ARPA Internet Text
3955 Messages," RFC 822, Department of Electrical Engineering,
3956 University of Delaware, August 1982.
3958 [3] TCP
3960 Postel, J., ed., "Transmission Control Protocol - DARPA Internet
3961 Program Protocol Specification", RFC 793, USC/Information Sciences
3962 Institute, NTIS AD Number A111091, September 1981. Also in:
3963 Feinler, E. and J. Postel, eds., "Internet Protocol Transition
3964 Workbook", SRI International, Menlo Park, California, March 1982.
3966 [4] NCP
3968 McKenzie,A., "Host/Host Protocol for the ARPA Network", NIC 8246,
3969 January 1972. Also in: Feinler, E. and J. Postel, eds., "ARPANET
3970 Protocol Handbook", NIC 7104, for the Defense Communications
3971 Agency by SRI International, Menlo Park, California, Revised
3972 January 1978.
3974 [5] Initial Connection Protocol
3976 Postel, J., "Official Initial Connection Protocol", NIC 7101,
3977 11 June 1971. Also in: Feinler, E. and J. Postel, eds., "ARPANET
3978 Protocol Handbook", NIC 7104, for the Defense Communications
3979 Agency by SRI International, Menlo Park, California, Revised
3980 January 1978.
3982 [6] NITS
3984 PSS/SG3, "A Network Independent Transport Service", Study Group 3,
3985 The Post Office PSS Users Group, February 1980. Available from
3986 the DCPU, National Physical Laboratory, Teddington, UK.
3991 Postel [Page 67]
3992 \f
3995 August 1982 RFC 821
3996 Simple Mail Transfer Protocol
4000 [7] X.25
4002 CCITT, "Recommendation X.25 - Interface Between Data Terminal
4003 Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for
4004 Terminals Operating in the Packet Mode on Public Data Networks,"
4005 CCITT Orange Book, Vol. VIII.2, International Telephone and
4006 Telegraph Consultative Committee, Geneva, 1976.
4049 [Page 68] Postel
4050 \f