projects / unix-history / blame
? search:
summary | tags | clone url | shortlog | log | commit | commitdiff | tree
blob | blame (incremental) | history | HEAD
This commit was generated by cvs2svn to track changes on a CVS vendor
[unix-history] / usr.sbin / sendmail / doc / rfc821.lpr
CommitLineData
15637ed4
RG		 1
2
3
4 RFC 821
5
6
7
8
9
10 SIMPLE MAIL TRANSFER PROTOCOL
11
12
13
14 Jonathan B. Postel
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44 August 1982
45
46
47
48 Information Sciences Institute
49 University of Southern California
50 4676 Admiralty Way
51 Marina del Rey, California 90291
52
53 (213) 822-1511
54\f
55\f
56
57
58RFC 821 August 1982
59 Simple Mail Transfer Protocol
60
61
62
63 TABLE OF CONTENTS
64
65 1. INTRODUCTION .................................................. 1
66
67 2. THE SMTP MODEL ................................................ 2
68
69 3. THE SMTP PROCEDURE ............................................ 4
70
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
79
80 4. THE SMTP SPECIFICATIONS ...................................... 19
81
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
94
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
101
102 GLOSSARY ......................................................... 64
103
104 REFERENCES ....................................................... 67
105\f
106\f
107
108
109Network Working Group J. Postel
110Request for Comments: DRAFT ISI
111Replaces: RFC 788, 780, 772 August 1982
112
113 SIMPLE MAIL TRANSFER PROTOCOL
114
115
1161. INTRODUCTION
117
118 The objective of Simple Mail Transfer Protocol (SMTP) is to transfer
119 mail reliably and efficiently.
120
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.
126
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.
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163Postel [Page 1]
164\f
165
166
167August 1982 RFC 821
168Simple Mail Transfer Protocol
169
170
171
1722. THE SMTP MODEL
173
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.
181
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.
194
195 -------------------------------------------------------------
196
197
198 +----------+ +----------+
199 +------+ | | | |
200 | User |<-->| | SMTP | |
201 +------+ | Sender- |Commands/Replies| Receiver-|
202 +------+ | SMTP |<-------------->| SMTP | +------+
203 | File |<-->| | and Mail | |<-->| File |
204 |System| | | | | |System|
205 +------+ +----------+ +----------+ +------+
206
207
208 Sender-SMTP Receiver-SMTP
209
210 Model for SMTP Use
211
212 Figure 1
213
214 -------------------------------------------------------------
215
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
218
219
220
221[Page 2] Postel
222\f
223
224
225RFC 821 August 1982
226 Simple Mail Transfer Protocol
227
228
229
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.
233
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.
237
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).
244
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.
248
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.
253
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.
260
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.
265
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).
274
275
276
277
278
279Postel [Page 3]
280\f
281
282
283August 1982 RFC 821
284Simple Mail Transfer Protocol
285
286
287
2883. THE SMTP PROCEDURES
289
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.
299
300 3.1. MAIL
301
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.
308
309 The first step in the procedure is the MAIL command. The
310 <reverse-path> contains the source mailbox.
311
312 MAIL <SP> FROM:<reverse-path> <CRLF>
313
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.
319
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.
324
325 The second step in the procedure is the RCPT command.
326
327 RCPT <SP> TO:<forward-path> <CRLF>
328
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.
334
335
336
337[Page 4] Postel
338\f
339
340
341RFC 821 August 1982
342 Simple Mail Transfer Protocol
343
344
345
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.
350
351 The third step in the procedure is the DATA command.
352
353 DATA <CRLF>
354
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.
359
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).
366
367 Please note that the mail data includes the memo header
368 items such as Date, Subject, To, Cc, From [2].
369
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.
376
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.
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395Postel [Page 5]
396\f
397
398
399August 1982 RFC 821
400Simple Mail Transfer Protocol
401
402
403
404 -------------------------------------------------------------
405
406 Example of the SMTP Procedure
407
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.
411
412 S: MAIL FROM:<Smith@Alpha.ARPA>
413 R: 250 OK
414
415 S: RCPT TO:<Jones@Beta.ARPA>
416 R: 250 OK
417
418 S: RCPT TO:<Green@Beta.ARPA>
419 R: 550 No such user here
420
421 S: RCPT TO:<Brown@Beta.ARPA>
422 R: 250 OK
423
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
430
431 The mail has now been accepted for Jones and Brown. Green did
432 not have a mailbox at host Beta.
433
434 Example 1
435
436 -------------------------------------------------------------
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453[Page 6] Postel
454\f
455
456
457RFC 821 August 1982
458 Simple Mail Transfer Protocol
459
460
461
462 3.2. FORWARDING
463
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.
469
470 251 User not local; will forward to <forward-path>
471
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.
477
478 551 User not local; please try <forward-path>
479
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.
487
488 Example 2 illustrates the use of these responses.
489
490 -------------------------------------------------------------
491
492 Example of Forwarding
493
494 Either
495
496 S: RCPT TO:<Postel@USC-ISI.ARPA>
497 R: 251 User not local; will forward to <Postel@USC-ISIF.ARPA>
498
499 Or
500
501 S: RCPT TO:<Paul@USC-ISIB.ARPA>
502 R: 551 User not local; please try <Mockapetris@USC-ISIF.ARPA>
503
504 Example 2
505
506 -------------------------------------------------------------
507
508
509
510
511Postel [Page 7]
512\f
513
514
515August 1982 RFC 821
516Simple Mail Transfer Protocol
517
518
519
520 3.3. VERIFYING AND EXPANDING
521
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.
530
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.
535
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").
547
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".
552
553 The case of verifying a user name is straightforward as shown in
554 example 3.
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569[Page 8] Postel
570\f
571
572
573RFC 821 August 1982
574 Simple Mail Transfer Protocol
575
576
577
578 -------------------------------------------------------------
579
580 Example of Verifying a User Name
581
582 Either
583
584 S: VRFY Smith
585 R: 250 Fred Smith <Smith@USC-ISIF.ARPA>
586
587 Or
588
589 S: VRFY Smith
590 R: 251 User not local; will forward to <Smith@USC-ISIQ.ARPA>
591
592 Or
593
594 S: VRFY Jones
595 R: 550 String does not match anything.
596
597 Or
598
599 S: VRFY Jones
600 R: 551 User not local; please try <Jones@USC-ISIQ.ARPA>
601
602 Or
603
604 S: VRFY Gourzenkyinplatz
605 R: 553 User ambiguous.
606
607 Example 3
608
609 -------------------------------------------------------------
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627Postel [Page 9]
628\f
629
630
631August 1982 RFC 821
632Simple Mail Transfer Protocol
633
634
635
636 The case of expanding a mailbox list requires a multiline reply as
637 shown in example 4.
638
639 -------------------------------------------------------------
640
641 Example of Expanding a Mailing List
642
643 Either
644
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>
652
653 Or
654
655 S: EXPN Executive-Washroom-List
656 R: 550 Access Denied to You.
657
658 Example 4
659
660 -------------------------------------------------------------
661
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.
668
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.
672
673
674
675
676
677
678
679
680
681
682
683
684
685[Page 10] Postel
686\f
687
688
689RFC 821 August 1982
690 Simple Mail Transfer Protocol
691
692
693
694 3.4. SENDING AND MAILING
695
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.
708
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:
713
714 SEND <SP> FROM:<reverse-path> <CRLF>
715
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.
721
722 SOML <SP> FROM:<reverse-path> <CRLF>
723
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.
731
732 SAML <SP> FROM:<reverse-path> <CRLF>
733
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.
740
741
742
743Postel [Page 11]
744\f
745
746
747August 1982 RFC 821
748Simple Mail Transfer Protocol
749
750
751
752 The same reply codes that are used for the MAIL commands are used
753 for these commands.
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801[Page 12] Postel
802\f
803
804
805RFC 821 August 1982
806 Simple Mail Transfer Protocol
807
808
809
810 3.5. OPENING AND CLOSING
811
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.
815
816 The following two commands are used in transmission channel
817 opening and closing:
818
819 HELO <SP> <domain> <CRLF>
820
821 QUIT <CRLF>
822
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>".
826
827 -------------------------------------------------------------
828
829 Example of Connection Opening
830
831 R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
832 S: HELO USC-ISIF.ARPA
833 R: 250 BBN-UNIX.ARPA
834
835 Example 5
836
837 -------------------------------------------------------------
838
839 -------------------------------------------------------------
840
841 Example of Connection Closing
842
843 S: QUIT
844 R: 221 BBN-UNIX.ARPA Service closing transmission channel
845
846 Example 6
847
848 -------------------------------------------------------------
849
850
851
852
853
854
855
856
857
858
859Postel [Page 13]
860\f
861
862
863August 1982 RFC 821
864Simple Mail Transfer Protocol
865
866
867
868 3.6. RELAYING
869
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.
876
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.
887
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.
893
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.
902
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.
906
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.
912
913 If a server-SMTP has accepted the task of relaying the mail and
914
915
916
917[Page 14] Postel
918\f
919
920
921RFC 821 August 1982
922 Simple Mail Transfer Protocol
923
924
925
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).
931
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:
939
940 MAIL FROM:<>
941
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.
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975Postel [Page 15]
976\f
977
978
979August 1982 RFC 821
980Simple Mail Transfer Protocol
981
982
983
984 -------------------------------------------------------------
985
986 Example Undeliverable Mail Notification Message
987
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
1004
1005 Example 7
1006
1007 -------------------------------------------------------------
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033[Page 16] Postel
1034\f
1035
1036
1037RFC 821 August 1982
1038 Simple Mail Transfer Protocol
1039
1040
1041
1042 3.7. DOMAINS
1043
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.
1052
1053 For example, "USC-ISIF.ARPA", "Fred.Cambridge.UK", and
1054 "PC7.LCS.MIT.ARPA" might be host-and-domain identifiers.
1055
1056 Whenever domain names are used in SMTP only the official names are
1057 used, the use of nicknames or aliases is not allowed.
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091Postel [Page 17]
1092\f
1093
1094
1095August 1982 RFC 821
1096Simple Mail Transfer Protocol
1097
1098
1099
1100 3.8. CHANGING ROLES
1101
1102 The TURN command may be used to reverse the roles of the two
1103 programs communicating over the transmission channel.
1104
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.
1108
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.
1112
1113 To refuse to change roles the receiver sends the 502 reply.
1114
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.
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149[Page 18] Postel
1150\f
1151
1152
1153RFC 821 August 1982
1154 Simple Mail Transfer Protocol
1155
1156
1157
11584. THE SMTP SPECIFICATIONS
1159
1160 4.1. SMTP COMMANDS
1161
1162 4.1.1. COMMAND SEMANTICS
1163
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.
1171
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.
1185
1186 HELLO (HELO)
1187
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.
1191
1192 The receiver-SMTP identifies itself to the sender-SMTP in
1193 the connection greeting reply, and in the response to this
1194 command.
1195
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.
1200
1201
1202
1203
1204
1205
1206
1207Postel [Page 19]
1208\f
1209
1210
1211August 1982 RFC 821
1212Simple Mail Transfer Protocol
1213
1214
1215
1216 MAIL (MAIL)
1217
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.
1221
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).
1234
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.
1239
1240 RECIPIENT (RCPT)
1241
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.
1245
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).
1253
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.
1260
1261
1262
1263
1264
1265[Page 20] Postel
1266\f
1267
1268
1269RFC 821 August 1982
1270 Simple Mail Transfer Protocol
1271
1272
1273
1274 For example, mail received at relay host A with arguments
1275
1276 FROM:<USERX@HOSTY.ARPA>
1277 TO:<@HOSTA.ARPA,@HOSTB.ARPA:USERC@HOSTD.ARPA>
1278
1279 will be relayed on to host B with arguments
1280
1281 FROM:<@HOSTA.ARPA:USERX@HOSTY.ARPA>
1282 TO:<@HOSTB.ARPA:USERC@HOSTD.ARPA>.
1283
1284 This command causes its forward-path argument to be appended
1285 to the forward-path buffer.
1286
1287 DATA (DATA)
1288
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.
1294
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.
1299
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.
1308
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.
1317
1318 When the receiver-SMTP makes the "final delivery" of a
1319 message it inserts at the beginning of the mail data a
1320
1321
1322
1323Postel [Page 21]
1324\f
1325
1326
1327August 1982 RFC 821
1328Simple Mail Transfer Protocol
1329
1330
1331
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.
1338
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.
1343
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.
1348
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).
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381[Page 22] Postel
1382\f
1383
1384
1385RFC 821 August 1982
1386 Simple Mail Transfer Protocol
1387
1388
1389
1390 -------------------------------------------------------------
1391
1392 Example of Return Path and Received Time Stamps
1393
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
1402
1403 This is to inform you that ...
1404
1405 Example 8
1406
1407 -------------------------------------------------------------
1408
1409 SEND (SEND)
1410
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.
1415
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).
1426
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.
1431
1432 SEND OR MAIL (SOML)
1433
1434 This command is used to initiate a mail transaction in which
1435 the mail data is delivered to one or more terminals or
1436
1437
1438
1439Postel [Page 23]
1440\f
1441
1442
1443August 1982 RFC 821
1444Simple Mail Transfer Protocol
1445
1446
1447
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.
1454
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).
1465
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.
1470
1471 SEND AND MAIL (SAML)
1472
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.
1481
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).
1492
1493 This command clears the reverse-path buffer, the
1494
1495
1496
1497[Page 24] Postel
1498\f
1499
1500
1501RFC 821 August 1982
1502 Simple Mail Transfer Protocol
1503
1504
1505
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.
1509
1510 RESET (RSET)
1511
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.
1516
1517 VERIFY (VRFY)
1518
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.
1523
1524 This command has no effect on any of the reverse-path
1525 buffer, the forward-path buffer, or the mail data buffer.
1526
1527 EXPAND (EXPN)
1528
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.
1534
1535 This command has no effect on any of the reverse-path
1536 buffer, the forward-path buffer, or the mail data buffer.
1537
1538 HELP (HELP)
1539
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.
1544
1545 This command has no effect on any of the reverse-path
1546 buffer, the forward-path buffer, or the mail data buffer.
1547
1548
1549
1550
1551
1552
1553
1554
1555Postel [Page 25]
1556\f
1557
1558
1559August 1982 RFC 821
1560Simple Mail Transfer Protocol
1561
1562
1563
1564 NOOP (NOOP)
1565
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.
1569
1570 This command has no effect on any of the reverse-path
1571 buffer, the forward-path buffer, or the mail data buffer.
1572
1573 QUIT (QUIT)
1574
1575 This command specifies that the receiver must send an OK
1576 reply, and then close the transmission channel.
1577
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).
1589
1590 TURN (TURN)
1591
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.
1596
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.
1602
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.
1608
1609 To refuse to change roles the receiver sends the 502 reply.
1610
1611
1612
1613[Page 26] Postel
1614\f
1615
1616
1617RFC 821 August 1982
1618 Simple Mail Transfer Protocol
1619
1620
1621
1622 There are restrictions on the order in which these command may
1623 be used.
1624
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.
1630
1631 The NOOP, HELP, EXPN, and VRFY commands can be used at any
1632 time during a session.
1633
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.
1640
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.
1647
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.
1650
1651 4.1.2. COMMAND SYNTAX
1652
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:
1658
1659 MAIL Mail mail MaIl mAIl
1660
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".
1667
1668
1669
1670
1671Postel [Page 27]
1672\f
1673
1674
1675August 1982 RFC 821
1676Simple Mail Transfer Protocol
1677
1678
1679
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.
1683
1684 Square brackets denote an optional argument field. If the
1685 option is not taken, the appropriate default is implied.
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729[Page 28] Postel
1730\f
1731
1732
1733RFC 821 August 1982
1734 Simple Mail Transfer Protocol
1735
1736
1737
1738 The following are the SMTP commands:
1739
1740 HELO <SP> <domain> <CRLF>
1741
1742 MAIL <SP> FROM:<reverse-path> <CRLF>
1743
1744 RCPT <SP> TO:<forward-path> <CRLF>
1745
1746 DATA <CRLF>
1747
1748 RSET <CRLF>
1749
1750 SEND <SP> FROM:<reverse-path> <CRLF>
1751
1752 SOML <SP> FROM:<reverse-path> <CRLF>
1753
1754 SAML <SP> FROM:<reverse-path> <CRLF>
1755
1756 VRFY <SP> <string> <CRLF>
1757
1758 EXPN <SP> <string> <CRLF>
1759
1760 HELP [<SP> <string>] <CRLF>
1761
1762 NOOP <CRLF>
1763
1764 QUIT <CRLF>
1765
1766 TURN <CRLF>
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787Postel [Page 29]
1788\f
1789
1790
1791August 1982 RFC 821
1792Simple Mail Transfer Protocol
1793
1794
1795
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.
1799
1800 <reverse-path> ::= <path>
1801
1802 <forward-path> ::= <path>
1803
1804 <path> ::= "<" [ <a-d-l> ":" ] <mailbox> ">"
1805
1806 <a-d-l> ::= <at-domain> | <at-domain> "," <a-d-l>
1807
1808 <at-domain> ::= "@" <domain>
1809
1810 <domain> ::= <element> | <element> "." <domain>
1811
1812 <element> ::= <name> | "#" <number> | "[" <dotnum> "]"
1813
1814 <mailbox> ::= <local-part> "@" <domain>
1815
1816 <local-part> ::= <dot-string> | <quoted-string>
1817
1818 <name> ::= <a> <ldh-str> <let-dig>
1819
1820 <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
1821
1822 <let-dig> ::= <a> | <d>
1823
1824 <let-dig-hyp> ::= <a> | <d> | "-"
1825
1826 <dot-string> ::= <string> | <string> "." <dot-string>
1827
1828 <string> ::= <char> | <char> <string>
1829
1830 <quoted-string> ::= """ <qtext> """
1831
1832 <qtext> ::= "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>
1833
1834 <char> ::= <c> | "\" <x>
1835
1836 <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>
1837
1838 <number> ::= <d> | <d> <number>
1839
1840 <CRLF> ::= <CR> <LF>
1841
1842
1843
1844
1845[Page 30] Postel
1846\f
1847
1848
1849RFC 821 August 1982
1850 Simple Mail Transfer Protocol
1851
1852
1853
1854 <CR> ::= the carriage return character (ASCII code 13)
1855
1856 <LF> ::= the line feed character (ASCII code 10)
1857
1858 <SP> ::= the space character (ASCII code 32)
1859
1860 <snum> ::= one, two, or three digits representing a decimal
1861 integer value in the range 0 through 255
1862
1863 <a> ::= any one of the 52 alphabetic characters A through Z
1864 in upper case and a through z in lower case
1865
1866 <c> ::= any one of the 128 ASCII characters, but not any
1867 <special> or <SP>
1868
1869 <d> ::= any one of the ten digits 0 through 9
1870
1871 <q> ::= any one of the 128 ASCII characters except <CR>,
1872 <LF>, quote ("), or backslash (\)
1873
1874 <x> ::= any one of the 128 ASCII characters (no exceptions)
1875
1876 <special> ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "."
1877 | "," | ";" | ":" | "@" """ | the control
1878 characters (ASCII codes 0 through 31 inclusive and
1879 127)
1880
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.
1886
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.
1891
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.
1900
1901
1902
1903Postel [Page 31]
1904\f
1905
1906
1907August 1982 RFC 821
1908Simple Mail Transfer Protocol
1909
1910
1911
1912 The time stamp line and the return path line are formally
1913 defined as follows:
1914
1915 <return-path-line> ::= "Return-Path:" <SP><reverse-path><CRLF>
1916
1917 <time-stamp-line> ::= "Received:" <SP> <stamp> <CRLF>
1918
1919 <stamp> ::= <from-domain> <by-domain> <opt-info> ";"
1920 <daytime>
1921
1922 <from-domain> ::= "FROM" <SP> <domain> <SP>
1923
1924 <by-domain> ::= "BY" <SP> <domain> <SP>
1925
1926 <opt-info> ::= [<via>] [<with>] [<id>] [<for>]
1927
1928 <via> ::= "VIA" <SP> <link> <SP>
1929
1930 <with> ::= "WITH" <SP> <protocol> <SP>
1931
1932 <id> ::= "ID" <SP> <string> <SP>
1933
1934 <for> ::= "FOR" <SP> <path> <SP>
1935
1936 <link> ::= The standard names for links are registered with
1937 the Network Information Center.
1938
1939 <protocol> ::= The standard names for protocols are
1940 registered with the Network Information Center.
1941
1942 <daytime> ::= <SP> <date> <SP> <time>
1943
1944 <date> ::= <dd> <SP> <mon> <SP> <yy>
1945
1946 <time> ::= <hh> ":" <mm> ":" <ss> <SP> <zone>
1947
1948 <dd> ::= the one or two decimal integer day of the month in
1949 the range 1 to 31.
1950
1951 <mon> ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" |
1952 "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"
1953
1954 <yy> ::= the two decimal integer year of the century in the
1955 range 00 to 99.
1956
1957
1958
1959
1960
1961[Page 32] Postel
1962\f
1963
1964
1965RFC 821 August 1982
1966 Simple Mail Transfer Protocol
1967
1968
1969
1970 <hh> ::= the two decimal integer hour of the day in the
1971 range 00 to 24.
1972
1973 <mm> ::= the two decimal integer minute of the hour in the
1974 range 00 to 59.
1975
1976 <ss> ::= the two decimal integer second of the minute in the
1977 range 00 to 59.
1978
1979 <zone> ::= "UT" for Universal Time (the default) or other
1980 time zone designator (as in [2]).
1981
1982
1983
1984 -------------------------------------------------------------
1985
1986 Return Path Example
1987
1988 Return-Path: <@CHARLIE.ARPA,@BAKER.ARPA:JOE@ABLE.ARPA>
1989
1990 Example 9
1991
1992 -------------------------------------------------------------
1993
1994 -------------------------------------------------------------
1995
1996 Time Stamp Line Example
1997
1998 Received: FROM ABC.ARPA BY XYZ.ARPA ; 22 OCT 81 09:23:59 PDT
1999
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
2002
2003 Example 10
2004
2005 -------------------------------------------------------------
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019Postel [Page 33]
2020\f
2021
2022
2023August 1982 RFC 821
2024Simple Mail Transfer Protocol
2025
2026
2027
2028 4.2. SMTP REPLIES
2029
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.
2034
2035 The details of the command-reply sequence are made explicit in
2036 Section 5.3 on Sequencing and Section 5.4 State Diagrams.
2037
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.
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077[Page 34] Postel
2078\f
2079
2080
2081RFC 821 August 1982
2082 Simple Mail Transfer Protocol
2083
2084
2085
2086 4.2.1. REPLY CODES BY FUNCTION GROUPS
2087
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
2094
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]
2100
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]
2107
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
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135Postel [Page 35]
2136\f
2137
2138
2139August 1982 RFC 821
2140Simple Mail Transfer Protocol
2141
2142
2143
2144 4.2.2. NUMERIC ORDER LIST OF REPLY CODES
2145
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>
2155
2156 354 Start mail input; end with <CRLF>.<CRLF>
2157
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
2166
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
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193[Page 36] Postel
2194\f
2195
2196
2197RFC 821 August 1982
2198 Simple Mail Transfer Protocol
2199
2200
2201
2202 4.3. SEQUENCING OF COMMANDS AND REPLIES
2203
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.
2209
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.
2214
2215 Note: all the greeting type replies have the official name of
2216 the server host as the first word following the reply code.
2217
2218 For example,
2219
2220 220 <SP> USC-ISIF.ARPA <SP> Service ready <CRLF>
2221
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.
2227
2228 COMMAND-REPLY SEQUENCES
2229
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.
2237
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
2248
2249
2250
2251Postel [Page 37]
2252\f
2253
2254
2255August 1982 RFC 821
2256Simple Mail Transfer Protocol
2257
2258
2259
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
2305
2306
2307
2308
2309[Page 38] Postel
2310\f
2311
2312
2313RFC 821 August 1982
2314 Simple Mail Transfer Protocol
2315
2316
2317
2318 4.4. STATE DIAGRAMS
2319
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.
2326
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".
2331
2332 First, the diagram that represents most of the SMTP commands:
2333
2334
2335 1,3 +---+
2336 ----------->| E |
2337 | +---+
2338 |
2339 +---+ cmd +---+ 2 +---+
2340 | B |---------->| W |---------->| S |
2341 +---+ +---+ +---+
2342 |
2343 | 4,5 +---+
2344 ----------->| F |
2345 +---+
2346
2347
2348 This diagram models the commands:
2349
2350 HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP,
2351 NOOP, QUIT, TURN.
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367Postel [Page 39]
2368\f
2369
2370
2371August 1982 RFC 821
2372Simple Mail Transfer Protocol
2373
2374
2375
2376 A more complex diagram models the DATA command:
2377
2378
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
2395
2396
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.
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425[Page 40] Postel
2426\f
2427
2428
2429RFC 821 August 1982
2430 Simple Mail Transfer Protocol
2431
2432
2433
2434 4.5. DETAILS
2435
2436 4.5.1. MINIMUM IMPLEMENTATION
2437
2438 In order to make SMTP workable, the following minimum
2439 implementation is required for all receivers:
2440
2441 COMMANDS -- HELO
2442 MAIL
2443 RCPT
2444 DATA
2445 RSET
2446 NOOP
2447 QUIT
2448
2449 4.5.2. TRANSPARENCY
2450
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.
2456
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.
2460
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.
2466
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.
2473
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
2478
2479
2480
2481
2482
2483Postel [Page 41]
2484\f
2485
2486
2487August 1982 RFC 821
2488Simple Mail Transfer Protocol
2489
2490
2491
2492 strings. If such transforms are necessary, they must be
2493 reversible -- especially if such transforms are applied to
2494 mail being relayed.
2495
2496 4.5.3. SIZES
2497
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.
2502
2503
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 ****************************************************
2511
2512 user
2513
2514 The maximum total length of a user name is 64 characters.
2515
2516 domain
2517
2518 The maximum total length of a domain name or number is 64
2519 characters.
2520
2521 path
2522
2523 The maximum total length of a reverse-path or
2524 forward-path is 256 characters (including the punctuation
2525 and element separators).
2526
2527 command line
2528
2529 The maximum total length of a command line including the
2530 command word and the <CRLF> is 512 characters.
2531
2532 reply line
2533
2534 The maximum total length of a reply line including the
2535 reply code and the <CRLF> is 512 characters.
2536
2537
2538
2539
2540
2541[Page 42] Postel
2542\f
2543
2544
2545RFC 821 August 1982
2546 Simple Mail Transfer Protocol
2547
2548
2549
2550 text line
2551
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).
2555
2556 recipients buffer
2557
2558 The maximum total number of recipients that must be
2559 buffered is 100 recipients.
2560
2561
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 ****************************************************
2569
2570 Errors due to exceeding these limits may be reported by using
2571 the reply codes, for example:
2572
2573 500 Line too long.
2574
2575 501 Path too long
2576
2577 552 Too many recipients.
2578
2579 552 Too much mail data.
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599Postel [Page 43]
2600\f
2601
2602
2603August 1982 RFC 821
2604Simple Mail Transfer Protocol
2605
2606
2607
2608APPENDIX A
2609
2610 TCP Transport service
2611
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.
2615
2616 Connection Establishment
2617
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.
2623
2624 Data Transfer
2625
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.
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657[Page 44] Postel
2658\f
2659
2660
2661RFC 821 August 1982
2662 Simple Mail Transfer Protocol
2663
2664
2665
2666APPENDIX B
2667
2668 NCP Transport service
2669
2670 The ARPANET Host-to-Host Protocol [4] (implemented by the Network
2671 Control Program) may be used in the ARPANET.
2672
2673 Connection Establishment
2674
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.
2681
2682 Data Transfer
2683
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.
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715Postel [Page 45]
2716\f
2717
2718
2719August 1982 RFC 821
2720Simple Mail Transfer Protocol
2721
2722
2723
2724APPENDIX C
2725
2726 NITS
2727
2728 The Network Independent Transport Service [6] may be used.
2729
2730 Connection Establishment
2731
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.
2736
2737 Data Transfer
2738
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.
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773[Page 46] Postel
2774\f
2775
2776
2777RFC 821 August 1982
2778 Simple Mail Transfer Protocol
2779
2780
2781
2782APPENDIX D
2783
2784 X.25 Transport service
2785
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.
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831Postel [Page 47]
2832\f
2833
2834
2835August 1982 RFC 821
2836Simple Mail Transfer Protocol
2837
2838
2839
2840APPENDIX E
2841
2842 Theory of Reply Codes
2843
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.
2853
2854 There are five values for the first digit of the reply code:
2855
2856 1yz Positive Preliminary reply
2857
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.
2863
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.]
2867
2868 2yz Positive Completion reply
2869
2870 The requested action has been successfully completed. A
2871 new request may be initiated.
2872
2873 3yz Positive Intermediate reply
2874
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.
2880
2881 4yz Transient Negative Completion reply
2882
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
2886
2887
2888
2889[Page 48] Postel
2890\f
2891
2892
2893RFC 821 August 1982
2894 Simple Mail Transfer Protocol
2895
2896
2897
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.)
2909
2910 5yz Permanent Negative Completion reply
2911
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).
2920
2921 The second digit encodes responses in specific categories:
2922
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.
2927
2928 x1z Information -- These are replies to requests for
2929 information, such as status or help.
2930
2931 x2z Connections -- These are replies referring to the
2932 transmission channel.
2933
2934 x3z Unspecified as yet.
2935
2936 x4z Unspecified as yet.
2937
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.
2941
2942 The third digit gives a finer gradation of meaning in each
2943 category specified by the second digit. The list of replies
2944
2945
2946
2947Postel [Page 49]
2948\f
2949
2950
2951August 1982 RFC 821
2952Simple Mail Transfer Protocol
2953
2954
2955
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.
2963
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.
2970
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.
2975
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>.
2981
2982 For example:
2983 123-First line
2984 123-Second line
2985 123-234 text beginning with numbers
2986 123 The last line
2987
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.
2993
2994
2995
2996
2997
2998
2999
3000
3001
3002
3003
3004
3005[Page 50] Postel
3006\f
3007
3008
3009RFC 821 August 1982
3010 Simple Mail Transfer Protocol
3011
3012
3013
3014APPENDIX F
3015
3016 Scenarios
3017
3018 This section presents complete scenarios of several types of SMTP
3019 sessions.
3020
3021 A Typical SMTP Transaction Scenario
3022
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.
3028
3029 -------------------------------------------------------------
3030
3031 R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
3032 S: HELO USC-ISIF.ARPA
3033 R: 250 BBN-UNIX.ARPA
3034
3035 S: MAIL FROM:<Smith@USC-ISIF.ARPA>
3036 R: 250 OK
3037
3038 S: RCPT TO:<Jones@BBN-UNIX.ARPA>
3039 R: 250 OK
3040
3041 S: RCPT TO:<Green@BBN-UNIX.ARPA>
3042 R: 550 No such user here
3043
3044 S: RCPT TO:<Brown@BBN-UNIX.ARPA>
3045 R: 250 OK
3046
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
3053
3054 S: QUIT
3055 R: 221 BBN-UNIX.ARPA Service closing transmission channel
3056
3057 Scenario 1
3058
3059 -------------------------------------------------------------
3060
3061
3062
3063Postel [Page 51]
3064\f
3065
3066
3067August 1982 RFC 821
3068Simple Mail Transfer Protocol
3069
3070
3071
3072 Aborted SMTP Transaction Scenario
3073
3074 -------------------------------------------------------------
3075
3076 R: 220 MIT-Multics.ARPA Simple Mail Transfer Service Ready
3077 S: HELO ISI-VAXA.ARPA
3078 R: 250 MIT-Multics.ARPA
3079
3080 S: MAIL FROM:<Smith@ISI-VAXA.ARPA>
3081 R: 250 OK
3082
3083 S: RCPT TO:<Jones@MIT-Multics.ARPA>
3084 R: 250 OK
3085
3086 S: RCPT TO:<Green@MIT-Multics.ARPA>
3087 R: 550 No such user here
3088
3089 S: RSET
3090 R: 250 OK
3091
3092 S: QUIT
3093 R: 221 MIT-Multics.ARPA Service closing transmission channel
3094
3095 Scenario 2
3096
3097 -------------------------------------------------------------
3098
3099
3100
3101
3102
3103
3104
3105
3106
3107
3108
3109
3110
3111
3112
3113
3114
3115
3116
3117
3118
3119
3120
3121[Page 52] Postel
3122\f
3123
3124
3125RFC 821 August 1982
3126 Simple Mail Transfer Protocol
3127
3128
3129
3130 Relayed Mail Scenario
3131
3132 -------------------------------------------------------------
3133
3134 Step 1 -- Source Host to Relay Host
3135
3136 R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
3137 S: HELO MIT-AI.ARPA
3138 R: 250 USC-ISIE.ARPA
3139
3140 S: MAIL FROM:<JQP@MIT-AI.ARPA>
3141 R: 250 OK
3142
3143 S: RCPT TO:<@USC-ISIE.ARPA:Jones@BBN-VAX.ARPA>
3144 R: 250 OK
3145
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
3159
3160 S: QUIT
3161 R: 221 USC-ISIE.ARPA Service closing transmission channel
3162
3163
3164
3165
3166
3167
3168
3169
3170
3171
3172
3173
3174
3175
3176
3177
3178
3179Postel [Page 53]
3180\f
3181
3182
3183August 1982 RFC 821
3184Simple Mail Transfer Protocol
3185
3186
3187
3188 Step 2 -- Relay Host to Destination Host
3189
3190 R: 220 BBN-VAX.ARPA Simple Mail Transfer Service Ready
3191 S: HELO USC-ISIE.ARPA
3192 R: 250 BBN-VAX.ARPA
3193
3194 S: MAIL FROM:<@USC-ISIE.ARPA:JQP@MIT-AI.ARPA>
3195 R: 250 OK
3196
3197 S: RCPT TO:<Jones@BBN-VAX.ARPA>
3198 R: 250 OK
3199
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
3215
3216 S: QUIT
3217 R: 221 USC-ISIE.ARPA Service closing transmission channel
3218
3219 Scenario 3
3220
3221 -------------------------------------------------------------
3222
3223
3224
3225
3226
3227
3228
3229
3230
3231
3232
3233
3234
3235
3236
3237[Page 54] Postel
3238\f
3239
3240
3241RFC 821 August 1982
3242 Simple Mail Transfer Protocol
3243
3244
3245
3246 Verifying and Sending Scenario
3247
3248 -------------------------------------------------------------
3249
3250 R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
3251 S: HELO MIT-MC.ARPA
3252 R: 250 SU-SCORE.ARPA
3253
3254 S: VRFY Crispin
3255 R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA>
3256
3257 S: SEND FROM:<EAK@MIT-MC.ARPA>
3258 R: 250 OK
3259
3260 S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
3261 R: 250 OK
3262
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
3269
3270 S: QUIT
3271 R: 221 SU-SCORE.ARPA Service closing transmission channel
3272
3273 Scenario 4
3274
3275 -------------------------------------------------------------
3276
3277
3278
3279
3280
3281
3282
3283
3284
3285
3286
3287
3288
3289
3290
3291
3292
3293
3294
3295Postel [Page 55]
3296\f
3297
3298
3299August 1982 RFC 821
3300Simple Mail Transfer Protocol
3301
3302
3303
3304 Sending and Mailing Scenarios
3305
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.
3309
3310 -------------------------------------------------------------
3311
3312 R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
3313 S: HELO MIT-MC.ARPA
3314 R: 250 SU-SCORE.ARPA
3315
3316 S: VRFY Crispin
3317 R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA>
3318
3319 S: SEND FROM:<EAK@MIT-MC.ARPA>
3320 R: 250 OK
3321
3322 S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
3323 R: 450 User not active now
3324
3325 S: RSET
3326 R: 250 OK
3327
3328 S: MAIL FROM:<EAK@MIT-MC.ARPA>
3329 R: 250 OK
3330
3331 S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
3332 R: 250 OK
3333
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
3340
3341 S: QUIT
3342 R: 221 SU-SCORE.ARPA Service closing transmission channel
3343
3344 Scenario 5
3345
3346 -------------------------------------------------------------
3347
3348
3349
3350
3351
3352
3353[Page 56] Postel
3354\f
3355
3356
3357RFC 821 August 1982
3358 Simple Mail Transfer Protocol
3359
3360
3361
3362 Doing the preceding scenario more efficiently.
3363
3364 -------------------------------------------------------------
3365
3366 R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
3367 S: HELO MIT-MC.ARPA
3368 R: 250 SU-SCORE.ARPA
3369
3370 S: VRFY Crispin
3371 R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA>
3372
3373 S: SOML FROM:<EAK@MIT-MC.ARPA>
3374 R: 250 OK
3375
3376 S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
3377 R: 250 User not active now, so will do mail.
3378
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
3385
3386 S: QUIT
3387 R: 221 SU-SCORE.ARPA Service closing transmission channel
3388
3389 Scenario 6
3390
3391 -------------------------------------------------------------
3392
3393
3394
3395
3396
3397
3398
3399
3400
3401
3402
3403
3404
3405
3406
3407
3408
3409
3410
3411Postel [Page 57]
3412\f
3413
3414
3415August 1982 RFC 821
3416Simple Mail Transfer Protocol
3417
3418
3419
3420 Mailing List Scenario
3421
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.
3425
3426 -------------------------------------------------------------
3427
3428 Step 1 -- Expanding the First List
3429
3430 R: 220 MIT-AI.ARPA Simple Mail Transfer Service Ready
3431 S: HELO SU-SCORE.ARPA
3432 R: 250 MIT-AI.ARPA
3433
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>
3441
3442 S: QUIT
3443 R: 221 MIT-AI.ARPA Service closing transmission channel
3444
3445
3446
3447
3448
3449
3450
3451
3452
3453
3454
3455
3456
3457
3458
3459
3460
3461
3462
3463
3464
3465
3466
3467
3468
3469[Page 58] Postel
3470\f
3471
3472
3473RFC 821 August 1982
3474 Simple Mail Transfer Protocol
3475
3476
3477
3478 Step 2 -- Expanding the Second List
3479
3480 R: 220 MIT-MC.ARPA Simple Mail Transfer Service Ready
3481 S: HELO SU-SCORE.ARPA
3482 R: 250 MIT-MC.ARPA
3483
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>
3490
3491 S: QUIT
3492 R: 221 MIT-MC.ARPA Service closing transmission channel
3493
3494
3495
3496
3497
3498
3499
3500
3501
3502
3503
3504
3505
3506
3507
3508
3509
3510
3511
3512
3513
3514
3515
3516
3517
3518
3519
3520
3521
3522
3523
3524
3525
3526
3527Postel [Page 59]
3528\f
3529
3530
3531August 1982 RFC 821
3532Simple Mail Transfer Protocol
3533
3534
3535
3536 Step 3 -- Mailing to All via a Relay Host
3537
3538 R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
3539 S: HELO SU-SCORE.ARPA
3540 R: 250 USC-ISIE.ARPA
3541
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
3559
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
3566
3567 S: QUIT
3568 R: 221 USC-ISIE.ARPA Service closing transmission channel
3569
3570 Scenario 7
3571
3572 -------------------------------------------------------------
3573
3574
3575
3576
3577
3578
3579
3580
3581
3582
3583
3584
3585[Page 60] Postel
3586\f
3587
3588
3589RFC 821 August 1982
3590 Simple Mail Transfer Protocol
3591
3592
3593
3594 Forwarding Scenarios
3595
3596 -------------------------------------------------------------
3597
3598 R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready
3599 S: HELO LBL-UNIX.ARPA
3600 R: 250 USC-ISIF.ARPA
3601
3602 S: MAIL FROM:<mo@LBL-UNIX.ARPA>
3603 R: 250 OK
3604
3605 S: RCPT TO:<fred@USC-ISIF.ARPA>
3606 R: 251 User not local; will forward to <Jones@USC-ISI.ARPA>
3607
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
3614
3615 S: QUIT
3616 R: 221 USC-ISIF.ARPA Service closing transmission channel
3617
3618 Scenario 8
3619
3620 -------------------------------------------------------------
3621
3622
3623
3624
3625
3626
3627
3628
3629
3630
3631
3632
3633
3634
3635
3636
3637
3638
3639
3640
3641
3642
3643Postel [Page 61]
3644\f
3645
3646
3647August 1982 RFC 821
3648Simple Mail Transfer Protocol
3649
3650
3651
3652 -------------------------------------------------------------
3653
3654 Step 1 -- Trying the Mailbox at the First Host
3655
3656 R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready
3657 S: HELO LBL-UNIX.ARPA
3658 R: 250 USC-ISIF.ARPA
3659
3660 S: MAIL FROM:<mo@LBL-UNIX.ARPA>
3661 R: 250 OK
3662
3663 S: RCPT TO:<fred@USC-ISIF.ARPA>
3664 R: 251 User not local; will forward to <Jones@USC-ISI.ARPA>
3665
3666 S: RSET
3667 R: 250 OK
3668
3669 S: QUIT
3670 R: 221 USC-ISIF.ARPA Service closing transmission channel
3671
3672 Step 2 -- Delivering the Mail at the Second Host
3673
3674 R: 220 USC-ISI.ARPA Simple Mail Transfer Service Ready
3675 S: HELO LBL-UNIX.ARPA
3676 R: 250 USC-ISI.ARPA
3677
3678 S: MAIL FROM:<mo@LBL-UNIX.ARPA>
3679 R: 250 OK
3680
3681 S: RCPT TO:<Jones@USC-ISI.ARPA>
3682 R: OK
3683
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
3690
3691 S: QUIT
3692 R: 221 USC-ISI.ARPA Service closing transmission channel
3693
3694 Scenario 9
3695
3696 -------------------------------------------------------------
3697
3698
3699
3700
3701[Page 62] Postel
3702\f
3703
3704
3705RFC 821 August 1982
3706 Simple Mail Transfer Protocol
3707
3708
3709
3710 Too Many Recipients Scenario
3711
3712 -------------------------------------------------------------
3713
3714 R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready
3715 S: HELO USC-ISIF.ARPA
3716 R: 250 BERKELEY.ARPA
3717
3718 S: MAIL FROM:<Postel@USC-ISIF.ARPA>
3719 R: 250 OK
3720
3721 S: RCPT TO:<fabry@BERKELEY.ARPA>
3722 R: 250 OK
3723
3724 S: RCPT TO:<eric@BERKELEY.ARPA>
3725 R: 552 Recipient storage full, try again in another transaction
3726
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
3733
3734 S: MAIL FROM:<Postel@USC-ISIF.ARPA>
3735 R: 250 OK
3736
3737 S: RCPT TO:<eric@BERKELEY.ARPA>
3738 R: 250 OK
3739
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
3746
3747 S: QUIT
3748 R: 221 BERKELEY.ARPA Service closing transmission channel
3749
3750 Scenario 10
3751
3752 -------------------------------------------------------------
3753
3754 Note that a real implementation must handle many recipients as
3755 specified in Section 4.5.3.
3756
3757
3758
3759Postel [Page 63]
3760\f
3761
3762
3763August 1982 RFC 821
3764Simple Mail Transfer Protocol
3765
3766
3767
3768GLOSSARY
3769
3770 ASCII
3771
3772 American Standard Code for Information Interchange [1].
3773
3774 command
3775
3776 A request for a mail service action sent by the sender-SMTP to the
3777 receiver-SMTP.
3778
3779 domain
3780
3781 The hierarchially structured global character string address of a
3782 host computer in the mail system.
3783
3784 end of mail data indication
3785
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.
3789
3790 host
3791
3792 A computer in the internetwork environment on which mailboxes or
3793 SMTP processes reside.
3794
3795 line
3796
3797 A a sequence of ASCII characters ending with a <CRLF>.
3798
3799 mail data
3800
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]).
3804
3805 mailbox
3806
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.
3812
3813
3814
3815
3816
3817[Page 64] Postel
3818\f
3819
3820
3821RFC 821 August 1982
3822 Simple Mail Transfer Protocol
3823
3824
3825
3826 receiver-SMTP process
3827
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.
3832
3833 reply
3834
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.
3841
3842 sender-SMTP process
3843
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.
3849
3850 session
3851
3852 The set of exchanges that occur while the transmission channel is
3853 open.
3854
3855 transaction
3856
3857 The set of exchanges required for one message to be transmitted
3858 for one or more recipients.
3859
3860 transmission channel
3861
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.
3865
3866 transport service
3867
3868 Any reliable stream-oriented data communication services. For
3869 example, NCP, TCP, NITS.
3870
3871
3872
3873
3874
3875Postel [Page 65]
3876\f
3877
3878
3879August 1982 RFC 821
3880Simple Mail Transfer Protocol
3881
3882
3883
3884 user
3885
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.
3889
3890 word
3891
3892 A sequence of printing characters.
3893
3894 <CRLF>
3895
3896 The characters carriage return and line feed (in that order).
3897
3898 <SP>
3899
3900 The space character.
3901
3902
3903
3904
3905
3906
3907
3908
3909
3910
3911
3912
3913
3914
3915
3916
3917
3918
3919
3920
3921
3922
3923
3924
3925
3926
3927
3928
3929
3930
3931
3932
3933[Page 66] Postel
3934\f
3935
3936
3937RFC 821 August 1982
3938 Simple Mail Transfer Protocol
3939
3940
3941
3942REFERENCES
3943
3944 [1] ASCII
3945
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.
3951
3952 [2] RFC 822
3953
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.
3957
3958 [3] TCP
3959
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.
3965
3966 [4] NCP
3967
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.
3973
3974 [5] Initial Connection Protocol
3975
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.
3981
3982 [6] NITS
3983
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.
3987
3988
3989
3990
3991Postel [Page 67]
3992\f
3993
3994
3995August 1982 RFC 821
3996Simple Mail Transfer Protocol
3997
3998
3999
4000 [7] X.25
4001
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.
4007
4008
4009
4010
4011
4012
4013
4014
4015
4016
4017
4018
4019
4020
4021
4022
4023
4024
4025
4026
4027
4028
4029
4030
4031
4032
4033
4034
4035
4036
4037
4038
4039
4040
4041
4042
4043
4044
4045
4046
4047
4048
4049[Page 68] Postel
4050\f
Continuous source code history from original PDP-7 UNIX to FreeBSD 2, the first fully unencumbered FreeBSD release.