![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to rfc821.lpr CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 42BSD / usr.lib / sendmail / doc|
Return to rfc821.lpr CVS log | Up to [CSRG BSD Unix] / 42BSD / usr.lib / sendmail / doc |
1.1 root 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:
55:
56:
57:
58: RFC 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:
106:
107:
108:
109: Network Working Group J. Postel
110: Request for Comments: DRAFT ISI
111: Replaces: RFC 788, 780, 772 August 1982
112:
113: SIMPLE MAIL TRANSFER PROTOCOL
114:
115:
116: 1. 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:
163: Postel [Page 1]
164:
165:
166:
167: August 1982 RFC 821
168: Simple Mail Transfer Protocol
169:
170:
171:
172: 2. 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:
223:
224:
225: RFC 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: "<[email protected]>" is an instance of <reverse-path> (the
273: angle brackets are actually transmitted in the command or reply).
274:
275:
276:
277:
278:
279: Postel [Page 3]
280:
281:
282:
283: August 1982 RFC 821
284: Simple Mail Transfer Protocol
285:
286:
287:
288: 3. 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:
339:
340:
341: RFC 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:
395: Postel [Page 5]
396:
397:
398:
399: August 1982 RFC 821
400: Simple 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:<[email protected]>
413: R: 250 OK
414:
415: S: RCPT TO:<[email protected]>
416: R: 250 OK
417:
418: S: RCPT TO:<[email protected]>
419: R: 550 No such user here
420:
421: S: RCPT TO:<[email protected]>
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:
455:
456:
457: RFC 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:<[email protected]>
497: R: 251 User not local; will forward to <[email protected]>
498:
499: Or
500:
501: S: RCPT TO:<[email protected]>
502: R: 551 User not local; please try <[email protected]>
503:
504: Example 2
505:
506: -------------------------------------------------------------
507:
508:
509:
510:
511: Postel [Page 7]
512:
513:
514:
515: August 1982 RFC 821
516: Simple 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:
571:
572:
573: RFC 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 <[email protected]>
586:
587: Or
588:
589: S: VRFY Smith
590: R: 251 User not local; will forward to <[email protected]>
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 <[email protected]>
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:
627: Postel [Page 9]
628:
629:
630:
631: August 1982 RFC 821
632: Simple 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 <[email protected]>
647: R: 250-Fred Fonebone <[email protected]>
648: R: 250-Sam Q. Smith <[email protected]>
649: R: 250-Quincy Smith <@USC-ISIF.ARPA:[email protected]>
650: R: 250-<[email protected]>
651: R: 250 <[email protected]>
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:
687:
688:
689: RFC 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:
743: Postel [Page 11]
744:
745:
746:
747: August 1982 RFC 821
748: Simple 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:
803:
804:
805: RFC 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:
859: Postel [Page 13]
860:
861:
862:
863: August 1982 RFC 821
864: Simple 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:
919:
920:
921: RFC 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:
975: Postel [Page 15]
976:
977:
978:
979: August 1982 RFC 821
980: Simple 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:[email protected]>
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: [email protected]
996: S: To: [email protected]
997: S: Subject: Mail System Problem
998: S:
999: S: Sorry JOE, your message to [email protected] 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:
1035:
1036:
1037: RFC 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:
1091: Postel [Page 17]
1092:
1093:
1094:
1095: August 1982 RFC 821
1096: Simple 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:
1151:
1152:
1153: RFC 821 August 1982
1154: Simple Mail Transfer Protocol
1155:
1156:
1157:
1158: 4. 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:
1207: Postel [Page 19]
1208:
1209:
1210:
1211: August 1982 RFC 821
1212: Simple 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:
1267:
1268:
1269: RFC 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:<[email protected]>
1277: TO:<@HOSTA.ARPA,@HOSTB.ARPA:[email protected]>
1278:
1279: will be relayed on to host B with arguments
1280:
1281: FROM:<@HOSTA.ARPA:[email protected]>
1282: TO:<@HOSTB.ARPA:[email protected]>.
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:
1323: Postel [Page 21]
1324:
1325:
1326:
1327: August 1982 RFC 821
1328: Simple 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:
1383:
1384:
1385: RFC 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:[email protected]>
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: [email protected]
1400: Subject: Improved Mailing System Installed
1401: To: [email protected]
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:
1439: Postel [Page 23]
1440:
1441:
1442:
1443: August 1982 RFC 821
1444: Simple 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:
1499:
1500:
1501: RFC 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:
1555: Postel [Page 25]
1556:
1557:
1558:
1559: August 1982 RFC 821
1560: Simple 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:
1615:
1616:
1617: RFC 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:
1671: Postel [Page 27]
1672:
1673:
1674:
1675: August 1982 RFC 821
1676: Simple 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:
1731:
1732:
1733: RFC 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:
1787: Postel [Page 29]
1788:
1789:
1790:
1791: August 1982 RFC 821
1792: Simple 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:
1847:
1848:
1849: RFC 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:
1903: Postel [Page 31]
1904:
1905:
1906:
1907: August 1982 RFC 821
1908: Simple 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:
1963:
1964:
1965: RFC 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:[email protected]>
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 [email protected] ; 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:
2019: Postel [Page 33]
2020:
2021:
2022:
2023: August 1982 RFC 821
2024: Simple 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:
2079:
2080:
2081: RFC 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:
2135: Postel [Page 35]
2136:
2137:
2138:
2139: August 1982 RFC 821
2140: Simple 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:
2195:
2196:
2197: RFC 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:
2251: Postel [Page 37]
2252:
2253:
2254:
2255: August 1982 RFC 821
2256: Simple 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:
2311:
2312:
2313: RFC 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:
2367: Postel [Page 39]
2368:
2369:
2370:
2371: August 1982 RFC 821
2372: Simple 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:
2427:
2428:
2429: RFC 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:
2483: Postel [Page 41]
2484:
2485:
2486:
2487: August 1982 RFC 821
2488: Simple 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:
2543:
2544:
2545: RFC 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:
2599: Postel [Page 43]
2600:
2601:
2602:
2603: August 1982 RFC 821
2604: Simple Mail Transfer Protocol
2605:
2606:
2607:
2608: APPENDIX 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:
2659:
2660:
2661: RFC 821 August 1982
2662: Simple Mail Transfer Protocol
2663:
2664:
2665:
2666: APPENDIX 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:
2715: Postel [Page 45]
2716:
2717:
2718:
2719: August 1982 RFC 821
2720: Simple Mail Transfer Protocol
2721:
2722:
2723:
2724: APPENDIX 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:
2775:
2776:
2777: RFC 821 August 1982
2778: Simple Mail Transfer Protocol
2779:
2780:
2781:
2782: APPENDIX 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:
2831: Postel [Page 47]
2832:
2833:
2834:
2835: August 1982 RFC 821
2836: Simple Mail Transfer Protocol
2837:
2838:
2839:
2840: APPENDIX 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:
2891:
2892:
2893: RFC 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:
2947: Postel [Page 49]
2948:
2949:
2950:
2951: August 1982 RFC 821
2952: Simple 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:
3007:
3008:
3009: RFC 821 August 1982
3010: Simple Mail Transfer Protocol
3011:
3012:
3013:
3014: APPENDIX 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:<[email protected]>
3036: R: 250 OK
3037:
3038: S: RCPT TO:<[email protected]>
3039: R: 250 OK
3040:
3041: S: RCPT TO:<[email protected]>
3042: R: 550 No such user here
3043:
3044: S: RCPT TO:<[email protected]>
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:
3063: Postel [Page 51]
3064:
3065:
3066:
3067: August 1982 RFC 821
3068: Simple 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:<[email protected]>
3081: R: 250 OK
3082:
3083: S: RCPT TO:<[email protected]>
3084: R: 250 OK
3085:
3086: S: RCPT TO:<[email protected]>
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:
3123:
3124:
3125: RFC 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:<[email protected]>
3141: R: 250 OK
3142:
3143: S: RCPT TO:<@USC-ISIE.ARPA:[email protected]>
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 <[email protected]>
3150: S: Subject: The Next Meeting of the Board
3151: S: To: [email protected]
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:
3179: Postel [Page 53]
3180:
3181:
3182:
3183: August 1982 RFC 821
3184: Simple 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:[email protected]>
3195: R: 250 OK
3196:
3197: S: RCPT TO:<[email protected]>
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 <[email protected]>
3206: S: Subject: The Next Meeting of the Board
3207: S: To: [email protected]
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:
3239:
3240:
3241: RFC 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 <[email protected]>
3256:
3257: S: SEND FROM:<[email protected]>
3258: R: 250 OK
3259:
3260: S: RCPT TO:<[email protected]>
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:
3295: Postel [Page 55]
3296:
3297:
3298:
3299: August 1982 RFC 821
3300: Simple 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 <[email protected]>
3318:
3319: S: SEND FROM:<[email protected]>
3320: R: 250 OK
3321:
3322: S: RCPT TO:<[email protected]>
3323: R: 450 User not active now
3324:
3325: S: RSET
3326: R: 250 OK
3327:
3328: S: MAIL FROM:<[email protected]>
3329: R: 250 OK
3330:
3331: S: RCPT TO:<[email protected]>
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:
3355:
3356:
3357: RFC 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 <[email protected]>
3372:
3373: S: SOML FROM:<[email protected]>
3374: R: 250 OK
3375:
3376: S: RCPT TO:<[email protected]>
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:
3411: Postel [Page 57]
3412:
3413:
3414:
3415: August 1982 RFC 821
3416: Simple 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-<[email protected]>
3436: R: 250-Fred Fonebone <[email protected]>
3437: R: 250-Xenon Y. Zither <[email protected]>
3438: R: 250-Quincy Smith <@USC-ISIF.ARPA:[email protected]>
3439: R: 250-<[email protected]>
3440: R: 250 <[email protected]>
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:
3471:
3472:
3473: RFC 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 <[email protected]>
3486: R: 250-<[email protected]>
3487: R: 250-Quincy Smith <@USC-ISIF.ARPA:[email protected]>
3488: R: 250-<[email protected]>
3489: R: 250 <[email protected]>
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:
3527: Postel [Page 59]
3528:
3529:
3530:
3531: August 1982 RFC 821
3532: Simple 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:<[email protected]>
3543: R: 250 OK
3544: S: RCPT TO:<@USC-ISIE.ARPA:[email protected]>
3545: R: 250 OK
3546: S: RCPT TO:<@USC-ISIE.ARPA:[email protected]>
3547: R: 250 OK
3548: S: RCPT TO:<@USC-ISIE.ARPA:[email protected]>
3549: R: 250 OK
3550: S: RCPT
3551: TO:<@USC-ISIE.ARPA,@USC-ISIF.ARPA:[email protected]>
3552: R: 250 OK
3553: S: RCPT TO:<@USC-ISIE.ARPA:[email protected]>
3554: R: 250 OK
3555: S: RCPT TO:<@USC-ISIE.ARPA:[email protected]>
3556: R: 250 OK
3557: S: RCPT TO:<@USC-ISIE.ARPA:[email protected]>
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:
3587:
3588:
3589: RFC 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:<[email protected]>
3603: R: 250 OK
3604:
3605: S: RCPT TO:<[email protected]>
3606: R: 251 User not local; will forward to <[email protected]>
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:
3643: Postel [Page 61]
3644:
3645:
3646:
3647: August 1982 RFC 821
3648: Simple 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:<[email protected]>
3661: R: 250 OK
3662:
3663: S: RCPT TO:<[email protected]>
3664: R: 251 User not local; will forward to <[email protected]>
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:<[email protected]>
3679: R: 250 OK
3680:
3681: S: RCPT TO:<[email protected]>
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:
3703:
3704:
3705: RFC 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:<[email protected]>
3719: R: 250 OK
3720:
3721: S: RCPT TO:<[email protected]>
3722: R: 250 OK
3723:
3724: S: RCPT TO:<[email protected]>
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:<[email protected]>
3735: R: 250 OK
3736:
3737: S: RCPT TO:<[email protected]>
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:
3759: Postel [Page 63]
3760:
3761:
3762:
3763: August 1982 RFC 821
3764: Simple Mail Transfer Protocol
3765:
3766:
3767:
3768: GLOSSARY
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:
3819:
3820:
3821: RFC 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:
3875: Postel [Page 65]
3876:
3877:
3878:
3879: August 1982 RFC 821
3880: Simple 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:
3935:
3936:
3937: RFC 821 August 1982
3938: Simple Mail Transfer Protocol
3939:
3940:
3941:
3942: REFERENCES
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:
3991: Postel [Page 67]
3992:
3993:
3994:
3995: August 1982 RFC 821
3996: Simple 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:
4051:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.