10 SIMPLE MAIL TRANSFER PROTOCOL
48 Information Sciences Institute
49 University of Southern California
51 Marina del Rey, California 90291
59 Simple Mail Transfer Protocol
65 1. INTRODUCTION .................................................. 1
67 2. THE SMTP MODEL ................................................ 2
69 3. THE SMTP PROCEDURE ............................................ 4
71 3.1. Mail ..................................................... 4
72 3.2. Forwarding ............................................... 7
73 3.3. Verifying and Expanding .................................. 8
74 3.4. Sending and Mailing ..................................... 11
75 3.5. Opening and Closing ..................................... 13
76 3.6. Relaying ................................................ 14
77 3.7. Domains ................................................. 17
78 3.8. Changing Roles .......................................... 18
80 4. THE SMTP SPECIFICATIONS ...................................... 19
82 4.1. SMTP Commands ........................................... 19
83 4.1.1. Command Semantics ..................................... 19
84 4.1.2. Command Syntax ........................................ 27
85 4.2. SMTP Replies ............................................ 34
86 4.2.1. Reply Codes by Function Group ......................... 35
87 4.2.2. Reply Codes in Numeric Order .......................... 36
88 4.3. Sequencing of Commands and Replies ...................... 37
89 4.4. State Diagrams .......................................... 39
90 4.5. Details ................................................. 41
91 4.5.1. Minimum Implementation ................................ 41
92 4.5.2. Transparency .......................................... 41
93 4.5.3. Sizes ................................................. 42
95 APPENDIX A: TCP ................................................. 44
96 APPENDIX B: NCP ................................................. 45
97 APPENDIX C: NITS ................................................ 46
98 APPENDIX D: X.25 ................................................ 47
99 APPENDIX E: Theory of Reply Codes ............................... 48
100 APPENDIX F: Scenarios ........................................... 51
102 GLOSSARY ......................................................... 64
104 REFERENCES ....................................................... 67
109Network Working Group J. Postel
110Request for Comments: DRAFT ISI
111Replaces: RFC 788, 780, 772 August 1982
113 SIMPLE MAIL TRANSFER PROTOCOL
118 The objective of Simple Mail Transfer Protocol (SMTP) is to transfer
119 mail reliably and efficiently.
121 SMTP is independent of the particular transmission subsystem and
122 requires only a reliable ordered data stream channel. Appendices A,
123 B, C, and D describe the use of SMTP with various transport services.
124 A Glossary provides the definitions of terms as used in this
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
168Simple Mail Transfer Protocol
174 The SMTP design is based on the following model of communication: as
175 the result of a user mail request, the sender-SMTP establishes a
176 two-way transmission channel to a receiver-SMTP. The receiver-SMTP
177 may be either the ultimate destination or an intermediate. SMTP
178 commands are generated by the sender-SMTP and sent to the
179 receiver-SMTP. SMTP replies are sent from the receiver-SMTP to the
180 sender-SMTP in response to the commands.
182 Once the transmission channel is established, the SMTP-sender sends a
183 MAIL command indicating the sender of the mail. If the SMTP-receiver
184 can accept mail it responds with an OK reply. The SMTP-sender then
185 sends a RCPT command identifying a recipient of the mail. If the
186 SMTP-receiver can accept mail for that recipient it responds with an
187 OK reply; if not, it responds with a reply rejecting that recipient
188 (but not the whole mail transaction). The SMTP-sender and
189 SMTP-receiver may negotiate several recipients. When the recipients
190 have been negotiated the SMTP-sender sends the mail data, terminating
191 with a special sequence. If the SMTP-receiver successfully processes
192 the mail data it responds with an OK reply. The dialog is purposely
193 lock-step, one-at-a-time.
195 -------------------------------------------------------------
198 +----------+ +----------+
200 | User |<-->| | SMTP | |
201 +------+ | Sender- |Commands/Replies| Receiver-|
202 +------+ | SMTP |<-------------->| SMTP | +------+
203 | File |<-->| | and Mail | |<-->| File |
204 |System| | | | | |System|
205 +------+ +----------+ +----------+ +------+
208 Sender-SMTP Receiver-SMTP
214 -------------------------------------------------------------
216 The SMTP provides mechanisms for the transmission of mail; directly
217 from the sending user's host to the receiving user's host when the
226 Simple Mail Transfer Protocol
230 two host are connected to the same transport service, or via one or
231 more relay SMTP-servers when the source and destination hosts are not
232 connected to the same transport service.
234 To be able to provide the relay capability the SMTP-server must be
235 supplied with the name of the ultimate destination host as well as
236 the destination mailbox name.
238 The argument to the MAIL command is a reverse-path, which specifies
239 who the mail is from. The argument to the RCPT command is a
240 forward-path, which specifies who the mail is to. The forward-path
241 is a source route, while the reverse-path is a return route (which
242 may be used to return a message to the sender when an error occurs
243 with a relayed message).
245 When the same message is sent to multiple recipients the SMTP
246 encourages the transmission of only one copy of the data for all the
247 recipients at the same destination host.
249 The mail commands and replies have a rigid syntax. Replies also have
250 a numeric code. In the following, examples appear which use actual
251 commands and replies. The complete lists of commands and replies
252 appears in Section 4 on specifications.
254 Commands and replies are not case sensitive. That is, a command or
255 reply word may be upper case, lower case, or any mixture of upper and
256 lower case. Note that this is not true of mailbox user names. For
257 some hosts the user name is case sensitive, and SMTP implementations
258 must take case to preserve the case of user names as they appear in
259 mailbox arguments. Host names are not case sensitive.
261 Commands and replies are composed of characters from the ASCII
262 character set [1]. When the transport service provides an 8-bit byte
263 (octet) transmission channel, each 7-bit character is transmitted
264 right justified in an octet with the high order bit cleared to zero.
266 When specifying the general form of a command or reply, an argument
267 (or special symbol) will be denoted by a meta-linguistic variable (or
268 constant), for example, "<string>" or "<reverse-path>". Here the
269 angle brackets indicate these are meta-linguistic variables.
270 However, some arguments use the angle brackets literally. For
271 example, an actual reverse-path is enclosed in angle brackets, i.e.,
272 "<John.Smith@USC-ISI.ARPA>" is an instance of <reverse-path> (the
273 angle brackets are actually transmitted in the command or reply).
284Simple Mail Transfer Protocol
2883. THE SMTP PROCEDURES
290 This section presents the procedures used in SMTP in several parts.
291 First comes the basic mail procedure defined as a mail transaction.
292 Following this are descriptions of forwarding mail, verifying mailbox
293 names and expanding mailing lists, sending to terminals instead of or
294 in combination with mailboxes, and the opening and closing exchanges.
295 At the end of this section are comments on relaying, a note on mail
296 domains, and a discussion of changing roles. Throughout this section
297 are examples of partial command and reply sequences, several complete
298 scenarios are presented in Appendix F.
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
309 The first step in the procedure is the MAIL command. The
310 <reverse-path> contains the source mailbox.
312 MAIL <SP> FROM:<reverse-path> <CRLF>
314 This command tells the SMTP-receiver that a new mail
315 transaction is starting and to reset all its state tables and
316 buffers, including any recipients or mail data. It gives the
317 reverse-path which can be used to report errors. If accepted,
318 the receiver-SMTP returns a 250 OK reply.
320 The <reverse-path> can contain more than just a mailbox. The
321 <reverse-path> is a reverse source routing list of hosts and
322 source mailbox. The first host in the <reverse-path> should be
323 the host sending this command.
325 The second step in the procedure is the RCPT command.
327 RCPT <SP> TO:<forward-path> <CRLF>
329 This command gives a forward-path identifying one recipient.
330 If accepted, the receiver-SMTP returns a 250 OK reply, and
331 stores the forward-path. If the recipient is unknown the
332 receiver-SMTP returns a 550 Failure reply. This second step of
333 the procedure can be repeated any number of times.
342 Simple Mail Transfer Protocol
346 The <forward-path> can contain more than just a mailbox. The
347 <forward-path> is a source routing list of hosts and the
348 destination mailbox. The first host in the <forward-path>
349 should be the host receiving this command.
351 The third step in the procedure is the DATA command.
355 If accepted, the receiver-SMTP returns a 354 Intermediate reply
356 and considers all succeeding lines to be the message text.
357 When the end of text is received and stored the SMTP-receiver
358 sends a 250 OK reply.
360 Since the mail data is sent on the transmission channel the end
361 of the mail data must be indicated so that the command and
362 reply dialog can be resumed. SMTP indicates the end of the
363 mail data by sending a line containing only a period. A
364 transparency procedure is used to prevent this from interfering
365 with the user's text (see Section 4.5.2).
367 Please note that the mail data includes the memo header
368 items such as Date, Subject, To, Cc, From [2].
370 The end of mail data indicator also confirms the mail
371 transaction and tells the receiver-SMTP to now process the
372 stored recipients and mail data. If accepted, the
373 receiver-SMTP returns a 250 OK reply. The DATA command should
374 fail only if the mail transaction was incomplete (for example,
375 no recipients), or if resources are not available.
377 The above procedure is an example of a mail transaction. These
378 commands must be used only in the order discussed above.
379 Example 1 (below) illustrates the use of these commands in a mail
400Simple Mail Transfer Protocol
404 -------------------------------------------------------------
406 Example of the SMTP Procedure
408 This SMTP example shows mail sent by Smith at host Alpha.ARPA,
409 to Jones, Green, and Brown at host Beta.ARPA. Here we assume
410 that host Alpha contacts host Beta directly.
412 S: MAIL FROM:<Smith@Alpha.ARPA>
415 S: RCPT TO:<Jones@Beta.ARPA>
418 S: RCPT TO:<Green@Beta.ARPA>
419 R: 550 No such user here
421 S: RCPT TO:<Brown@Beta.ARPA>
425 R: 354 Start mail input; end with <CRLF>.<CRLF>
431 The mail has now been accepted for Jones and Brown. Green did
432 not have a mailbox at host Beta.
436 -------------------------------------------------------------
458 Simple Mail Transfer Protocol
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
470 251 User not local; will forward to <forward-path>
472 This reply indicates that the receiver-SMTP knows the user's
473 mailbox is on another host and indicates the correct
474 forward-path to use in the future. Note that either the
475 host or user or both may be different. The receiver takes
476 responsibility for delivering the message.
478 551 User not local; please try <forward-path>
480 This reply indicates that the receiver-SMTP knows the user's
481 mailbox is on another host and indicates the correct
482 forward-path to use. Note that either the host or user or
483 both may be different. The receiver refuses to accept mail
484 for this user, and the sender must either redirect the mail
485 according to the information provided or return an error
486 response to the originating user.
488 Example 2 illustrates the use of these responses.
490 -------------------------------------------------------------
492 Example of Forwarding
496 S: RCPT TO:<Postel@USC-ISI.ARPA>
497 R: 251 User not local; will forward to <Postel@USC-ISIF.ARPA>
501 S: RCPT TO:<Paul@USC-ISIB.ARPA>
502 R: 551 User not local; please try <Mockapetris@USC-ISIF.ARPA>
506 -------------------------------------------------------------
516Simple Mail Transfer Protocol
520 3.3. VERIFYING AND EXPANDING
522 SMTP provides as additional features, commands to verify a user
523 name or expand a mailing list. This is done with the VRFY and
524 EXPN commands, which have character string arguments. For the
525 VRFY command, the string is a user name, and the response may
526 include the full name of the user and must include the mailbox of
527 the user. For the EXPN command, the string identifies a mailing
528 list, and the multiline response may include the full name of the
529 users and must give the mailboxes on the mailing list.
531 "User name" is a fuzzy term and used purposely. If a host
532 implements the VRFY or EXPN commands then at least local mailboxes
533 must be recognized as "user names". If a host chooses to
534 recognize other strings as "user names" that is allowed.
536 In some hosts the distinction between a mailing list and an alias
537 for a single mailbox is a bit fuzzy, since a common data structure
538 may hold both types of entries, and it is possible to have mailing
539 lists of one mailbox. If a request is made to verify a mailing
540 list a positive response can be given if on receipt of a message
541 so addressed it will be delivered to everyone on the list,
542 otherwise an error should be reported (e.g., "550 That is a
543 mailing list, not a user"). If a request is made to expand a user
544 name a positive response can be formed by returning a list
545 containing one name, or an error can be reported (e.g., "550 That
546 is a user name, not a mailing list").
548 In the case of a multiline reply (normal for EXPN) exactly one
549 mailbox is to be specified on each line of the reply. In the case
550 of an ambiguous request, for example, "VRFY Smith", where there
551 are two Smith's the response must be "553 User ambiguous".
553 The case of verifying a user name is straightforward as shown in
574 Simple Mail Transfer Protocol
578 -------------------------------------------------------------
580 Example of Verifying a User Name
585 R: 250 Fred Smith <Smith@USC-ISIF.ARPA>
590 R: 251 User not local; will forward to <Smith@USC-ISIQ.ARPA>
595 R: 550 String does not match anything.
600 R: 551 User not local; please try <Jones@USC-ISIQ.ARPA>
604 S: VRFY Gourzenkyinplatz
605 R: 553 User ambiguous.
609 -------------------------------------------------------------
632Simple Mail Transfer Protocol
636 The case of expanding a mailbox list requires a multiline reply as
639 -------------------------------------------------------------
641 Example of Expanding a Mailing List
645 S: EXPN Example-People
646 R: 250-Jon Postel <Postel@USC-ISIF.ARPA>
647 R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA>
648 R: 250-Sam Q. Smith <SQSmith@USC-ISIQ.ARPA>
649 R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
650 R: 250-<joe@foo-unix.ARPA>
651 R: 250 <xyz@bar-unix.ARPA>
655 S: EXPN Executive-Washroom-List
656 R: 550 Access Denied to You.
660 -------------------------------------------------------------
662 The character string arguments of the VRFY and EXPN commands
663 cannot be further restricted due to the variety of implementations
664 of the user name and mailbox list concepts. On some systems it
665 may be appropriate for the argument of the EXPN command to be a
666 file name for a file containing a mailing list, but again there is
667 a variety of file naming conventions in the Internet.
669 The VRFY and EXPN commands are not included in the minimum
670 implementation (Section 4.5.1), and are not required to work
671 across relays when they are implemented.
690 Simple Mail Transfer Protocol
694 3.4. SENDING AND MAILING
696 The main purpose of SMTP is to deliver messages to user's
697 mailboxes. A very similar service provided by some hosts is to
698 deliver messages to user's terminals (provided the user is active
699 on the host). The delivery to the user's mailbox is called
700 "mailing", the delivery to the user's terminal is called
701 "sending". Because in many hosts the implementation of sending is
702 nearly identical to the implementation of mailing these two
703 functions are combined in SMTP. However the sending commands are
704 not included in the required minimum implementation
705 (Section 4.5.1). Users should have the ability to control the
706 writing of messages on their terminals. Most hosts permit the
707 users to accept or refuse such messages.
709 The following three command are defined to support the sending
710 options. These are used in the mail transaction instead of the
711 MAIL command and inform the receiver-SMTP of the special semantics
714 SEND <SP> FROM:<reverse-path> <CRLF>
716 The SEND command requires that the mail data be delivered to
717 the user's terminal. If the user is not active (or not
718 accepting terminal messages) on the host a 450 reply may
719 returned to a RCPT command. The mail transaction is
720 successful if the message is delivered the terminal.
722 SOML <SP> FROM:<reverse-path> <CRLF>
724 The Send Or MaiL command requires that the mail data be
725 delivered to the user's terminal if the user is active (and
726 accepting terminal messages) on the host. If the user is
727 not active (or not accepting terminal messages) then the
728 mail data is entered into the user's mailbox. The mail
729 transaction is successful if the message is delivered either
730 to the terminal or the mailbox.
732 SAML <SP> FROM:<reverse-path> <CRLF>
734 The Send And MaiL command requires that the mail data be
735 delivered to the user's terminal if the user is active (and
736 accepting terminal messages) on the host. In any case the
737 mail data is entered into the user's mailbox. The mail
738 transaction is successful if the message is delivered the
748Simple Mail Transfer Protocol
752 The same reply codes that are used for the MAIL commands are used
806 Simple Mail Transfer Protocol
810 3.5. OPENING AND CLOSING
812 At the time the transmission channel is opened there is an
813 exchange to ensure that the hosts are communicating with the hosts
816 The following two commands are used in transmission channel
819 HELO <SP> <domain> <CRLF>
823 In the HELO command the host sending the command identifies
824 itself; the command may be interpreted as saying "Hello, I am
827 -------------------------------------------------------------
829 Example of Connection Opening
831 R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
832 S: HELO USC-ISIF.ARPA
837 -------------------------------------------------------------
839 -------------------------------------------------------------
841 Example of Connection Closing
844 R: 221 BBN-UNIX.ARPA Service closing transmission channel
848 -------------------------------------------------------------
864Simple Mail Transfer Protocol
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
877 Conceptually the elements of the forward-path are moved to the
878 reverse-path as the message is relayed from one server-SMTP to
879 another. The reverse-path is a reverse source route, (i.e., a
880 source route from the current location of the message to the
881 originator of the message). When a server-SMTP deletes its
882 identifier from the forward-path and inserts it into the
883 reverse-path, it must use the name it is known by in the
884 environment it is sending into, not the environment the mail came
885 from, in case the server-SMTP is known by different names in
886 different environments.
888 If when the message arrives at an SMTP the first element of the
889 forward-path is not the identifier of that SMTP the element is not
890 deleted from the forward-path and is used to determine the next
891 SMTP to send the message to. In any case, the SMTP adds its own
892 identifier to the reverse-path.
894 Using source routing the receiver-SMTP receives mail to be relayed
895 to another server-SMTP The receiver-SMTP may accept or reject the
896 task of relaying the mail in the same way it accepts or rejects
897 mail for a local user. The receiver-SMTP transforms the command
898 arguments by moving its own identifier from the forward-path to
899 the beginning of the reverse-path. The receiver-SMTP then becomes
900 a sender-SMTP, establishes a transmission channel to the next SMTP
901 in the forward-path, and sends it the mail.
903 The first host in the reverse-path should be the host sending the
904 SMTP commands, and the first host in the forward-path should be
905 the host receiving the SMTP commands.
907 Notice that the forward-path and reverse-path appear in the SMTP
908 commands and replies, but not necessarily in the message. That
909 is, there is no need for these paths and especially this syntax to
910 appear in the "To:" , "From:", "CC:", etc. fields of the message
913 If a server-SMTP has accepted the task of relaying the mail and
922 Simple Mail Transfer Protocol
926 later finds that the forward-path is incorrect or that the mail
927 cannot be delivered for whatever reason, then it must construct an
928 "undeliverable mail" notification message and send it to the
929 originator of the undeliverable mail (as indicated by the
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:
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.
980Simple Mail Transfer Protocol
984 -------------------------------------------------------------
986 Example Undeliverable Mail Notification Message
990 S: RCPT TO:<@HOSTX.ARPA:JOE@HOSTW.ARPA>
993 R: 354 send the mail data, end with .
994 S: Date: 23 Oct 81 11:22:33
995 S: From: SMTP@HOSTY.ARPA
996 S: To: JOE@HOSTW.ARPA
997 S: Subject: Mail System Problem
999 S: Sorry JOE, your message to SAM@HOSTZ.ARPA lost.
1000 S: HOSTZ.ARPA said this:
1001 S: "550 No Such User"
1007 -------------------------------------------------------------
1038 Simple Mail Transfer Protocol
1044 Domains are a recently introduced concept in the ARPA Internet
1045 mail system. The use of domains changes the address space from a
1046 flat global space of simple character string host names to a
1047 hierarchically structured rooted tree of global addresses. The
1048 host name is replaced by a domain and host designator which is a
1049 sequence of domain element strings separated by periods with the
1050 understanding that the domain elements are ordered from the most
1051 specific to the most general.
1053 For example, "USC-ISIF.ARPA", "Fred.Cambridge.UK", and
1054 "PC7.LCS.MIT.ARPA" might be host-and-domain identifiers.
1056 Whenever domain names are used in SMTP only the official names are
1057 used, the use of nicknames or aliases is not allowed.
1096Simple Mail Transfer Protocol
1102 The TURN command may be used to reverse the roles of the two
1103 programs communicating over the transmission channel.
1105 If program-A is currently the sender-SMTP and it sends the TURN
1106 command and receives an ok reply (250) then program-A becomes the
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
1113 To refuse to change roles the receiver sends the 502 reply.
1115 Please note that this command is optional. It would not normally
1116 be used in situations where the transmission channel is TCP.
1117 However, when the cost of establishing the transmission channel is
1118 high, this command may be quite useful. For example, this command
1119 may be useful in supporting be mail exchange using the public
1120 switched telephone system as a transmission channel, especially if
1121 some hosts poll other hosts for mail exchanges.
1154 Simple Mail Transfer Protocol
11584. THE SMTP SPECIFICATIONS
1162 4.1.1. COMMAND SEMANTICS
1164 The SMTP commands define the mail transfer or the mail system
1165 function requested by the user. SMTP commands are character
1166 strings terminated by <CRLF>. The command codes themselves are
1167 alphabetic characters terminated by <SP> if parameters follow
1168 and <CRLF> otherwise. The syntax of mailboxes must conform to
1169 receiver site conventions. The SMTP commands are discussed
1170 below. The SMTP replies are discussed in the Section 4.2.
1172 A mail transaction involves several data objects which are
1173 communicated as arguments to different commands. The
1174 reverse-path is the argument of the MAIL command, the
1175 forward-path is the argument of the RCPT command, and the mail
1176 data is the argument of the DATA command. These arguments or
1177 data objects must be transmitted and held pending the
1178 confirmation communicated by the end of mail data indication
1179 which finalizes the transaction. The model for this is that
1180 distinct buffers are provided to hold the types of data
1181 objects, that is, there is a reverse-path buffer, a
1182 forward-path buffer, and a mail data buffer. Specific commands
1183 cause information to be appended to a specific buffer, or cause
1184 one or more buffers to be cleared.
1188 This command is used to identify the sender-SMTP to the
1189 receiver-SMTP. The argument field contains the host name of
1192 The receiver-SMTP identifies itself to the sender-SMTP in
1193 the connection greeting reply, and in the response to this
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.
1212Simple Mail Transfer Protocol
1218 This command is used to initiate a mail transaction in which
1219 the mail data is delivered to one or more mailboxes. The
1220 argument field contains a reverse-path.
1222 The reverse-path consists of an optional list of hosts and
1223 the sender mailbox. When the list of hosts is present, it
1224 is a "reverse" source route and indicates that the mail was
1225 relayed through each host on the list (the first host in the
1226 list was the most recent relay). This list is used as a
1227 source route to return non-delivery notices to the sender.
1228 As each relay host adds itself to the beginning of the list,
1229 it must use its name as known in the IPCE to which it is
1230 relaying the mail rather than the IPCE from which the mail
1231 came (if they are different). In some types of error
1232 reporting messages (for example, undeliverable mail
1233 notifications) the reverse-path may be null (see Example 7).
1235 This command clears the reverse-path buffer, the
1236 forward-path buffer, and the mail data buffer; and inserts
1237 the reverse-path information from this command into the
1238 reverse-path buffer.
1242 This command is used to identify an individual recipient of
1243 the mail data; multiple recipients are specified by multiple
1244 use of this command.
1246 The forward-path consists of an optional list of hosts and a
1247 required destination mailbox. When the list of hosts is
1248 present, it is a source route and indicates that the mail
1249 must be relayed to the next host on the list. If the
1250 receiver-SMTP does not implement the relay function it may
1251 user the same reply it would for an unknown local user
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.
1270 Simple Mail Transfer Protocol
1274 For example, mail received at relay host A with arguments
1276 FROM:<USERX@HOSTY.ARPA>
1277 TO:<@HOSTA.ARPA,@HOSTB.ARPA:USERC@HOSTD.ARPA>
1279 will be relayed on to host B with arguments
1281 FROM:<@HOSTA.ARPA:USERX@HOSTY.ARPA>
1282 TO:<@HOSTB.ARPA:USERC@HOSTD.ARPA>.
1284 This command causes its forward-path argument to be appended
1285 to the forward-path buffer.
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
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
1300 The end of mail data indication requires that the receiver
1301 must now process the stored mail transaction information.
1302 This processing consumes the information in the reverse-path
1303 buffer, the forward-path buffer, and the mail data buffer,
1304 and on the completion of this command these buffers are
1305 cleared. If the processing is successful the receiver must
1306 send an OK reply. If the processing fails completely the
1307 receiver must send a failure reply.
1309 When the receiver-SMTP accepts a message either for relaying
1310 or for final delivery it inserts at the beginning of the
1311 mail data a time stamp line. The time stamp line indicates
1312 the identity of the host that sent the message, and the
1313 identity of the host that received the message (and is
1314 inserting this time stamp), and the date and time the
1315 message was received. Relayed messages will have multiple
1318 When the receiver-SMTP makes the "final delivery" of a
1319 message it inserts at the beginning of the mail data a
1328Simple Mail Transfer Protocol
1332 return path line. The return path line preserves the
1333 information in the <reverse-path> from the MAIL command.
1334 Here, final delivery means the message leaves the SMTP
1335 world. Normally, this would mean it has been delivered to
1336 the destination user, but in some cases it may be further
1337 processed and transmitted by another mail system.
1339 It is possible for the mailbox in the return path be
1340 different from the actual sender's mailbox, for example,
1341 if error responses are to be delivered a special error
1342 handling mailbox rather than the message senders.
1344 The preceding two paragraphs imply that the final mail data
1345 will begin with a return path line, followed by one or more
1346 time stamp lines. These lines will be followed by the mail
1347 data header and body [2]. See Example 8.
1349 Special mention is needed of the response and further action
1350 required when the processing following the end of mail data
1351 indication is partially successful. This could arise if
1352 after accepting several recipients and the mail data, the
1353 receiver-SMTP finds that the mail data can be successfully
1354 delivered to some of the recipients, but it cannot be to
1355 others (for example, due to mailbox space allocation
1356 problems). In such a situation, the response to the DATA
1357 command must be an OK reply. But, the receiver-SMTP must
1358 compose and send an "undeliverable mail" notification
1359 message to the originator of the message. Either a single
1360 notification which lists all of the recipients that failed
1361 to get the message, or separate notification messages must
1362 be sent for each failed recipient (see Example 7). All
1363 undeliverable mail notification messages are sent using the
1364 MAIL command (even if they result from processing a SEND,
1365 SOML, or SAML command).
1386 Simple Mail Transfer Protocol
1390 -------------------------------------------------------------
1392 Example of Return Path and Received Time Stamps
1394 Return-Path: <@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:JOE@ABC.ARPA>
1395 Received: from GHI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 PST
1396 Received: from DEF.ARPA by GHI.ARPA ; 27 Oct 81 15:15:13 PST
1397 Received: from ABC.ARPA by DEF.ARPA ; 27 Oct 81 15:01:59 PST
1398 Date: 27 Oct 81 15:01:01 PST
1400 Subject: Improved Mailing System Installed
1403 This is to inform you that ...
1407 -------------------------------------------------------------
1411 This command is used to initiate a mail transaction in which
1412 the mail data is delivered to one or more terminals. The
1413 argument field contains a reverse-path. This command is
1414 successful if the message is delivered to a terminal.
1416 The reverse-path consists of an optional list of hosts and
1417 the sender mailbox. When the list of hosts is present, it
1418 is a "reverse" source route and indicates that the mail was
1419 relayed through each host on the list (the first host in the
1420 list was the most recent relay). This list is used as a
1421 source route to return non-delivery notices to the sender.
1422 As each relay host adds itself to the beginning of the list,
1423 it must use its name as known in the IPCE to which it is
1424 relaying the mail rather than the IPCE from which the mail
1425 came (if they are different).
1427 This command clears the reverse-path buffer, the
1428 forward-path buffer, and the mail data buffer; and inserts
1429 the reverse-path information from this command into the
1430 reverse-path buffer.
1434 This command is used to initiate a mail transaction in which
1435 the mail data is delivered to one or more terminals or
1444Simple Mail Transfer Protocol
1448 mailboxes. For each recipient the mail data is delivered to
1449 the recipient's terminal if the recipient is active on the
1450 host (and accepting terminal messages), otherwise to the
1451 recipient's mailbox. The argument field contains a
1452 reverse-path. This command is successful if the message is
1453 delivered to a terminal or the mailbox.
1455 The reverse-path consists of an optional list of hosts and
1456 the sender mailbox. When the list of hosts is present, it
1457 is a "reverse" source route and indicates that the mail was
1458 relayed through each host on the list (the first host in the
1459 list was the most recent relay). This list is used as a
1460 source route to return non-delivery notices to the sender.
1461 As each relay host adds itself to the beginning of the list,
1462 it must use its name as known in the IPCE to which it is
1463 relaying the mail rather than the IPCE from which the mail
1464 came (if they are different).
1466 This command clears the reverse-path buffer, the
1467 forward-path buffer, and the mail data buffer; and inserts
1468 the reverse-path information from this command into the
1469 reverse-path buffer.
1471 SEND AND MAIL (SAML)
1473 This command is used to initiate a mail transaction in which
1474 the mail data is delivered to one or more terminals and
1475 mailboxes. For each recipient the mail data is delivered to
1476 the recipient's terminal if the recipient is active on the
1477 host (and accepting terminal messages), and for all
1478 recipients to the recipient's mailbox. The argument field
1479 contains a reverse-path. This command is successful if the
1480 message is delivered to the mailbox.
1482 The reverse-path consists of an optional list of hosts and
1483 the sender mailbox. When the list of hosts is present, it
1484 is a "reverse" source route and indicates that the mail was
1485 relayed through each host on the list (the first host in the
1486 list was the most recent relay). This list is used as a
1487 source route to return non-delivery notices to the sender.
1488 As each relay host adds itself to the beginning of the list,
1489 it must use its name as known in the IPCE to which it is
1490 relaying the mail rather than the IPCE from which the mail
1491 came (if they are different).
1493 This command clears the reverse-path buffer, the
1502 Simple Mail Transfer Protocol
1506 forward-path buffer, and the mail data buffer; and inserts
1507 the reverse-path information from this command into the
1508 reverse-path buffer.
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.
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
1524 This command has no effect on any of the reverse-path
1525 buffer, the forward-path buffer, or the mail data buffer.
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
1535 This command has no effect on any of the reverse-path
1536 buffer, the forward-path buffer, or the mail data buffer.
1540 This command causes the receiver to send helpful information
1541 to the sender of the HELP command. The command may take an
1542 argument (e.g., any command name) and return more specific
1543 information as a response.
1545 This command has no effect on any of the reverse-path
1546 buffer, the forward-path buffer, or the mail data buffer.
1560Simple Mail Transfer Protocol
1566 This command does not affect any parameters or previously
1567 entered commands. It specifies no action other than that
1568 the receiver send an OK reply.
1570 This command has no effect on any of the reverse-path
1571 buffer, the forward-path buffer, or the mail data buffer.
1575 This command specifies that the receiver must send an OK
1576 reply, and then close the transmission channel.
1578 The receiver should not close the transmission channel until
1579 it receives and replies to a QUIT command (even if there was
1580 an error). The sender should not close the transmission
1581 channel until it send a QUIT command and receives the reply
1582 (even if there was an error response to a previous command).
1583 If the connection is closed prematurely the receiver should
1584 act as if a RSET command had been received (canceling any
1585 pending transaction, but not undoing any previously
1586 completed transaction), the sender should act as if the
1587 command or transaction in progress had received a temporary
1592 This command specifies that the receiver must either (1)
1593 send an OK reply and then take on the role of the
1594 sender-SMTP, or (2) send a refusal reply and retain the role
1595 of the receiver-SMTP.
1597 If program-A is currently the sender-SMTP and it sends the
1598 TURN command and receives an OK reply (250) then program-A
1599 becomes the receiver-SMTP. Program-A is then in the initial
1600 state as if the transmission channel just opened, and it
1601 then sends the 220 service ready greeting.
1603 If program-B is currently the receiver-SMTP and it receives
1604 the TURN command and sends an OK reply (250) then program-B
1605 becomes the sender-SMTP. Program-B is then in the initial
1606 state as if the transmission channel just opened, and it
1607 then expects to receive the 220 service ready greeting.
1609 To refuse to change roles the receiver sends the 502 reply.
1618 Simple Mail Transfer Protocol
1622 There are restrictions on the order in which these command may
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
1631 The NOOP, HELP, EXPN, and VRFY commands can be used at any
1632 time during a session.
1634 The MAIL, SEND, SOML, or SAML commands begin a mail
1635 transaction. Once started a mail transaction consists of
1636 one of the transaction beginning commands, one or more RCPT
1637 commands, and a DATA command, in that order. A mail
1638 transaction may be aborted by the RSET command. There may
1639 be zero or more transactions in a session.
1641 If the transaction beginning command argument is not
1642 acceptable a 501 failure reply must be returned and the
1643 receiver-SMTP must stay in the same state. If the commands
1644 in a transaction are out of order a 503 failure reply must
1645 be returned and the receiver-SMTP must stay in the same
1648 The last command in a session must be the QUIT command. The
1649 QUIT command can not be used at any other time in a session.
1651 4.1.2. COMMAND SYNTAX
1653 The commands consist of a command code followed by an argument
1654 field. Command codes are four alphabetic characters. Upper
1655 and lower case alphabetic characters are to be treated
1656 identically. Thus, any of the following may represent the mail
1659 MAIL Mail mail MaIl mAIl
1661 This also applies to any symbols representing parameter values,
1662 such as "TO" or "to" for the forward-path. Command codes and
1663 the argument fields are separated by one or more spaces.
1664 However, within the reverse-path and forward-path arguments
1665 case is important. In particular, in some hosts the user
1666 "smith" is different from the user "Smith".
1676Simple Mail Transfer Protocol
1680 The argument field consists of a variable length character
1681 string ending with the character sequence <CRLF>. The receiver
1682 is to take no action until this sequence is received.
1684 Square brackets denote an optional argument field. If the
1685 option is not taken, the appropriate default is implied.
1734 Simple Mail Transfer Protocol
1738 The following are the SMTP commands:
1740 HELO <SP> <domain> <CRLF>
1742 MAIL <SP> FROM:<reverse-path> <CRLF>
1744 RCPT <SP> TO:<forward-path> <CRLF>
1750 SEND <SP> FROM:<reverse-path> <CRLF>
1752 SOML <SP> FROM:<reverse-path> <CRLF>
1754 SAML <SP> FROM:<reverse-path> <CRLF>
1756 VRFY <SP> <string> <CRLF>
1758 EXPN <SP> <string> <CRLF>
1760 HELP [<SP> <string>] <CRLF>
1792Simple Mail Transfer Protocol
1796 The syntax of the above argument fields (using BNF notation
1797 where applicable) is given below. The "..." notation indicates
1798 that a field may be repeated one or more times.
1800 <reverse-path> ::= <path>
1802 <forward-path> ::= <path>
1804 <path> ::= "<" [ <a-d-l> ":" ] <mailbox> ">"
1806 <a-d-l> ::= <at-domain> | <at-domain> "," <a-d-l>
1808 <at-domain> ::= "@" <domain>
1810 <domain> ::= <element> | <element> "." <domain>
1812 <element> ::= <name> | "#" <number> | "[" <dotnum> "]"
1814 <mailbox> ::= <local-part> "@" <domain>
1816 <local-part> ::= <dot-string> | <quoted-string>
1818 <name> ::= <a> <ldh-str> <let-dig>
1820 <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
1822 <let-dig> ::= <a> | <d>
1824 <let-dig-hyp> ::= <a> | <d> | "-"
1826 <dot-string> ::= <string> | <string> "." <dot-string>
1828 <string> ::= <char> | <char> <string>
1830 <quoted-string> ::= """ <qtext> """
1832 <qtext> ::= "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>
1834 <char> ::= <c> | "\" <x>
1836 <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>
1838 <number> ::= <d> | <d> <number>
1840 <CRLF> ::= <CR> <LF>
1850 Simple Mail Transfer Protocol
1854 <CR> ::= the carriage return character (ASCII code 13)
1856 <LF> ::= the line feed character (ASCII code 10)
1858 <SP> ::= the space character (ASCII code 32)
1860 <snum> ::= one, two, or three digits representing a decimal
1861 integer value in the range 0 through 255
1863 <a> ::= any one of the 52 alphabetic characters A through Z
1864 in upper case and a through z in lower case
1866 <c> ::= any one of the 128 ASCII characters, but not any
1869 <d> ::= any one of the ten digits 0 through 9
1871 <q> ::= any one of the 128 ASCII characters except <CR>,
1872 <LF>, quote ("), or backslash (\)
1874 <x> ::= any one of the 128 ASCII characters (no exceptions)
1876 <special> ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "."
1877 | "," | ";" | ":" | "@" """ | the control
1878 characters (ASCII codes 0 through 31 inclusive and
1881 Note that the backslash, "\", is a quote character, which is
1882 used to indicate that the next character is to be used
1883 literally (instead of its normal interpretation). For example,
1884 "Joe\,Smith" could be used to indicate a single nine character
1885 user field with comma being the fourth character of the field.
1887 Hosts are generally known by names which are translated to
1888 addresses in each host. Note that the name elements of domains
1889 are the official names -- no use of nicknames or aliases is
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.
1908Simple Mail Transfer Protocol
1912 The time stamp line and the return path line are formally
1915 <return-path-line> ::= "Return-Path:" <SP><reverse-path><CRLF>
1917 <time-stamp-line> ::= "Received:" <SP> <stamp> <CRLF>
1919 <stamp> ::= <from-domain> <by-domain> <opt-info> ";"
1922 <from-domain> ::= "FROM" <SP> <domain> <SP>
1924 <by-domain> ::= "BY" <SP> <domain> <SP>
1926 <opt-info> ::= [<via>] [<with>] [<id>] [<for>]
1928 <via> ::= "VIA" <SP> <link> <SP>
1930 <with> ::= "WITH" <SP> <protocol> <SP>
1932 <id> ::= "ID" <SP> <string> <SP>
1934 <for> ::= "FOR" <SP> <path> <SP>
1936 <link> ::= The standard names for links are registered with
1937 the Network Information Center.
1939 <protocol> ::= The standard names for protocols are
1940 registered with the Network Information Center.
1942 <daytime> ::= <SP> <date> <SP> <time>
1944 <date> ::= <dd> <SP> <mon> <SP> <yy>
1946 <time> ::= <hh> ":" <mm> ":" <ss> <SP> <zone>
1948 <dd> ::= the one or two decimal integer day of the month in
1951 <mon> ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" |
1952 "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"
1954 <yy> ::= the two decimal integer year of the century in the
1966 Simple Mail Transfer Protocol
1970 <hh> ::= the two decimal integer hour of the day in the
1973 <mm> ::= the two decimal integer minute of the hour in the
1976 <ss> ::= the two decimal integer second of the minute in the
1979 <zone> ::= "UT" for Universal Time (the default) or other
1980 time zone designator (as in [2]).
1984 -------------------------------------------------------------
1988 Return-Path: <@CHARLIE.ARPA,@BAKER.ARPA:JOE@ABLE.ARPA>
1992 -------------------------------------------------------------
1994 -------------------------------------------------------------
1996 Time Stamp Line Example
1998 Received: FROM ABC.ARPA BY XYZ.ARPA ; 22 OCT 81 09:23:59 PDT
2000 Received: from ABC.ARPA by XYZ.ARPA via TELENET with X25
2001 id M12345 for Smith@PDQ.ARPA ; 22 OCT 81 09:23:59 PDT
2005 -------------------------------------------------------------
2024Simple Mail Transfer Protocol
2030 Replies to SMTP commands are devised to ensure the synchronization
2031 of requests and actions in the process of mail transfer, and to
2032 guarantee that the sender-SMTP always knows the state of the
2033 receiver-SMTP. Every command must generate exactly one reply.
2035 The details of the command-reply sequence are made explicit in
2036 Section 5.3 on Sequencing and Section 5.4 State Diagrams.
2038 An SMTP reply consists of a three digit number (transmitted as
2039 three alphanumeric characters) followed by some text. The number
2040 is intended for use by automata to determine what state to enter
2041 next; the text is meant for the human user. It is intended that
2042 the three digits contain enough encoded information that the
2043 sender-SMTP need not examine the text and may either discard it or
2044 pass it on to the user, as appropriate. In particular, the text
2045 may be receiver-dependent and context dependent, so there are
2046 likely to be varying texts for each reply code. A discussion of
2047 the theory of reply codes is given in Appendix E. Formally, a
2048 reply is defined to be the sequence: a three-digit code, <SP>,
2049 one line of text, and <CRLF>, or a multiline reply (as defined in
2050 Appendix E). Only the EXPN and HELP commands are expected to
2051 result in multiline replies in normal circumstances, however
2052 multiline replies are allowed for any command.
2082 Simple Mail Transfer Protocol
2086 4.2.1. REPLY CODES BY FUNCTION GROUPS
2088 500 Syntax error, command unrecognized
2089 [This may include errors such as command line too long]
2090 501 Syntax error in parameters or arguments
2091 502 Command not implemented
2092 503 Bad sequence of commands
2093 504 Command parameter not implemented
2095 211 System status, or system help reply
2097 [Information on how to use the receiver or the meaning of a
2098 particular non-standard command; this reply is useful only
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
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
2140Simple Mail Transfer Protocol
2144 4.2.2. NUMERIC ORDER LIST OF REPLY CODES
2146 211 System status, or system help reply
2148 [Information on how to use the receiver or the meaning of a
2149 particular non-standard command; this reply is useful only
2151 220 <domain> Service ready
2152 221 <domain> Service closing transmission channel
2153 250 Requested mail action okay, completed
2154 251 User not local; will forward to <forward-path>
2156 354 Start mail input; end with <CRLF>.<CRLF>
2158 421 <domain> Service not available,
2159 closing transmission channel
2160 [This may be a reply to any command if the service knows it
2162 450 Requested mail action not taken: mailbox unavailable
2163 [E.g., mailbox busy]
2164 451 Requested action aborted: local error in processing
2165 452 Requested action not taken: insufficient system storage
2167 500 Syntax error, command unrecognized
2168 [This may include errors such as command line too long]
2169 501 Syntax error in parameters or arguments
2170 502 Command not implemented
2171 503 Bad sequence of commands
2172 504 Command parameter not implemented
2173 550 Requested action not taken: mailbox unavailable
2174 [E.g., mailbox not found, no access]
2175 551 User not local; please try <forward-path>
2176 552 Requested mail action aborted: exceeded storage allocation
2177 553 Requested action not taken: mailbox name not allowed
2178 [E.g., mailbox syntax incorrect]
2179 554 Transaction failed
2198 Simple Mail Transfer Protocol
2202 4.3. SEQUENCING OF COMMANDS AND REPLIES
2204 The communication between the sender and receiver is intended to
2205 be an alternating dialogue, controlled by the sender. As such,
2206 the sender issues a command and the receiver responds with a
2207 reply. The sender must wait for this response before sending
2210 One important reply is the connection greeting. Normally, a
2211 receiver will send a 220 "Service ready" reply when the connection
2212 is completed. The sender should wait for this greeting message
2213 before sending any commands.
2215 Note: all the greeting type replies have the official name of
2216 the server host as the first word following the reply code.
2220 220 <SP> USC-ISIF.ARPA <SP> Service ready <CRLF>
2222 The table below lists alternative success and failure replies for
2223 each command. These must be strictly adhered to; a receiver may
2224 substitute text in the replies, but the meaning and action implied
2225 by the code numbers and by the specific command reply sequence
2228 COMMAND-REPLY SEQUENCES
2230 Each command is listed with its possible replies. The prefixes
2231 used before the possible replies are "P" for preliminary (not
2232 used in SMTP), "I" for intermediate, "S" for success, "F" for
2233 failure, and "E" for error. The 421 reply (service not
2234 available, closing transmission channel) may be given to any
2235 command if the SMTP-receiver knows it must shut down. This
2236 listing forms the basis for the State Diagrams in Section 4.4.
2238 CONNECTION ESTABLISHMENT
2243 E: 500, 501, 504, 421
2256Simple Mail Transfer Protocol
2262 F: 550, 551, 552, 553, 450, 451, 452
2263 E: 500, 501, 503, 421
2265 I: 354 -> data -> S: 250
2266 F: 552, 554, 451, 452
2268 E: 500, 501, 503, 421
2271 E: 500, 501, 504, 421
2275 E: 500, 501, 502, 421
2279 E: 500, 501, 502, 421
2283 E: 500, 501, 502, 421
2287 E: 500, 501, 502, 504, 421
2291 E: 500, 501, 502, 504, 421
2294 E: 500, 501, 502, 504, 421
2314 Simple Mail Transfer Protocol
2320 Following are state diagrams for a simple-minded SMTP
2321 implementation. Only the first digit of the reply codes is used.
2322 There is one state diagram for each group of SMTP commands. The
2323 command groupings were determined by constructing a model for each
2324 command and then collecting together the commands with
2325 structurally identical models.
2327 For each command there are three possible outcomes: "success"
2328 (S), "failure" (F), and "error" (E). In the state diagrams below
2329 we use the symbol B for "begin", and the symbol W for "wait for
2332 First, the diagram that represents most of the SMTP commands:
2339 +---+ cmd +---+ 2 +---+
2340 | B |---------->| W |---------->| S |
2348 This diagram models the commands:
2350 HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP,
2372Simple Mail Transfer Protocol
2376 A more complex diagram models the DATA command:
2379 +---+ DATA +---+ 1,2 +---+
2380 | B |---------->| W |-------------------->| E |
2381 +---+ +---+ ------------>+---+
2384 -------------- ----- |
2386 | ---------- -------->| S |
2391 +---+ data +---+ --------------->+---+
2392 | |---------->| W | | F |
2393 +---+ +---+-------------------->+---+
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
2430 Simple Mail Transfer Protocol
2436 4.5.1. MINIMUM IMPLEMENTATION
2438 In order to make SMTP workable, the following minimum
2439 implementation is required for all receivers:
2451 Without some provision for data transparency the character
2452 sequence "<CRLF>.<CRLF>" ends the mail text and cannot be sent
2453 by the user. In general, users are not aware of such
2454 "forbidden" sequences. To allow all user composed text to be
2455 transmitted transparently the following procedures are used.
2457 1. Before sending a line of mail text the sender-SMTP checks
2458 the first character of the line. If it is a period, one
2459 additional period is inserted at the beginning of the line.
2461 2. When a line of mail text is received by the receiver-SMTP
2462 it checks the line. If the line is composed of a single
2463 period it is the end of mail. If the first character is a
2464 period and there are other characters on the line, the first
2465 character is deleted.
2467 The mail data may contain any of the 128 ASCII characters. All
2468 characters are to be delivered to the recipient's mailbox
2469 including format effectors and other control characters. If
2470 the transmission channel provides an 8-bit byte (octets) data
2471 stream, the 7-bit ASCII codes are transmitted right justified
2472 in the octets with the high order bits cleared to zero.
2474 In some systems it may be necessary to transform the data as
2475 it is received and stored. This may be necessary for hosts
2476 that use a different character set than ASCII as their local
2477 character set, or that store data in records rather than
2488Simple Mail Transfer Protocol
2492 strings. If such transforms are necessary, they must be
2493 reversible -- especially if such transforms are applied to
2498 There are several objects that have required minimum maximum
2499 sizes. That is, every implementation must be able to receive
2500 objects of at least these sizes, but must not send objects
2501 larger than these sizes.
2504 ****************************************************
2506 * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION *
2507 * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
2508 * OF THESE OBJECTS SHOULD BE USED. *
2510 ****************************************************
2514 The maximum total length of a user name is 64 characters.
2518 The maximum total length of a domain name or number is 64
2523 The maximum total length of a reverse-path or
2524 forward-path is 256 characters (including the punctuation
2525 and element separators).
2529 The maximum total length of a command line including the
2530 command word and the <CRLF> is 512 characters.
2534 The maximum total length of a reply line including the
2535 reply code and the <CRLF> is 512 characters.
2546 Simple Mail Transfer Protocol
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).
2558 The maximum total number of recipients that must be
2559 buffered is 100 recipients.
2562 ****************************************************
2564 * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION *
2565 * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
2566 * OF THESE OBJECTS SHOULD BE USED. *
2568 ****************************************************
2570 Errors due to exceeding these limits may be reported by using
2571 the reply codes, for example:
2577 552 Too many recipients.
2579 552 Too much mail data.
2604Simple Mail Transfer Protocol
2610 TCP Transport service
2612 The Transmission Control Protocol [3] is used in the ARPA
2613 Internet, and in any network following the US DoD standards for
2614 internetwork protocols.
2616 Connection Establishment
2618 The SMTP transmission channel is a TCP connection established
2619 between the sender process port U and the receiver process port
2620 L. This single full duplex connection is used as the
2621 transmission channel. This protocol is assigned the service
2622 port 25 (31 octal), that is L=25.
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
2662 Simple Mail Transfer Protocol
2668 NCP Transport service
2670 The ARPANET Host-to-Host Protocol [4] (implemented by the Network
2671 Control Program) may be used in the ARPANET.
2673 Connection Establishment
2675 The SMTP transmission channel is established via NCP between
2676 the sender process socket U and receiver process socket L. The
2677 Initial Connection Protocol [5] is followed resulting in a pair
2678 of simplex connections. This pair of connections is used as
2679 the transmission channel. This protocol is assigned the
2680 contact socket 25 (31 octal), that is L=25.
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
2720Simple Mail Transfer Protocol
2728 The Network Independent Transport Service [6] may be used.
2730 Connection Establishment
2732 The SMTP transmission channel is established via NITS between
2733 the sender process and receiver process. The sender process
2734 executes the CONNECT primitive, and the waiting receiver
2735 process executes the ACCEPT primitive.
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
2778 Simple Mail Transfer Protocol
2784 X.25 Transport service
2786 It may be possible to use the X.25 service [7] as provided by the
2787 Public Data Networks directly, however, it is suggested that a
2788 reliable end-to-end protocol such as TCP be used on top of X.25
2836Simple Mail Transfer Protocol
2842 Theory of Reply Codes
2844 The three digits of the reply each have a special significance.
2845 The first digit denotes whether the response is good, bad or
2846 incomplete. An unsophisticated sender-SMTP will be able to
2847 determine its next action (proceed as planned, redo, retrench,
2848 etc.) by simply examining this first digit. A sender-SMTP that
2849 wants to know approximately what kind of error occurred (e.g.,
2850 mail system error, command syntax error) may examine the second
2851 digit, reserving the third digit for the finest gradation of
2854 There are five values for the first digit of the reply code:
2856 1yz Positive Preliminary reply
2858 The command has been accepted, but the requested action
2859 is being held in abeyance, pending confirmation of the
2860 information in this reply. The sender-SMTP should send
2861 another command specifying whether to continue or abort
2864 [Note: SMTP does not have any commands that allow this
2865 type of reply, and so does not have the continue or
2868 2yz Positive Completion reply
2870 The requested action has been successfully completed. A
2871 new request may be initiated.
2873 3yz Positive Intermediate reply
2875 The command has been accepted, but the requested action
2876 is being held in abeyance, pending receipt of further
2877 information. The sender-SMTP should send another command
2878 specifying this information. This reply is used in
2879 command sequence groups.
2881 4yz Transient Negative Completion reply
2883 The command was not accepted and the requested action did
2884 not occur. However, the error condition is temporary and
2885 the action may be requested again. The sender should
2894 Simple Mail Transfer Protocol
2898 return to the beginning of the command sequence (if any).
2899 It is difficult to assign a meaning to "transient" when
2900 two different sites (receiver- and sender- SMTPs) must
2901 agree on the interpretation. Each reply in this category
2902 might have a different time value, but the sender-SMTP is
2903 encouraged to try again. A rule of thumb to determine if
2904 a reply fits into the 4yz or the 5yz category (see below)
2905 is that replies are 4yz if they can be repeated without
2906 any change in command form or in properties of the sender
2907 or receiver. (E.g., the command is repeated identically
2908 and the receiver does not put up a new implementation.)
2910 5yz Permanent Negative Completion reply
2912 The command was not accepted and the requested action did
2913 not occur. The sender-SMTP is discouraged from repeating
2914 the exact request (in the same sequence). Even some
2915 "permanent" error conditions can be corrected, so the
2916 human user may want to direct the sender-SMTP to
2917 reinitiate the command sequence by direct action at some
2918 point in the future (e.g., after the spelling has been
2919 changed, or the user has altered the account status).
2921 The second digit encodes responses in specific categories:
2923 x0z Syntax -- These replies refer to syntax errors,
2924 syntactically correct commands that don't fit any
2925 functional category, and unimplemented or superfluous
2928 x1z Information -- These are replies to requests for
2929 information, such as status or help.
2931 x2z Connections -- These are replies referring to the
2932 transmission channel.
2934 x3z Unspecified as yet.
2936 x4z Unspecified as yet.
2938 x5z Mail system -- These replies indicate the status of
2939 the receiver mail system vis-a-vis the requested
2940 transfer or other mail system action.
2942 The third digit gives a finer gradation of meaning in each
2943 category specified by the second digit. The list of replies
2952Simple Mail Transfer Protocol
2956 illustrates this. Each reply text is recommended rather than
2957 mandatory, and may even change according to the command with
2958 which it is associated. On the other hand, the reply codes
2959 must strictly follow the specifications in this section.
2960 Receiver implementations should not invent new codes for
2961 slightly different situations from the ones described here, but
2962 rather adapt codes already defined.
2964 For example, a command such as NOOP whose successful execution
2965 does not offer the sender-SMTP any new information will return
2966 a 250 reply. The response is 502 when the command requests an
2967 unimplemented non-site-specific action. A refinement of that
2968 is the 504 reply for a command that is implemented, but that
2969 requests an unimplemented parameter.
2971 The reply text may be longer than a single line; in these cases
2972 the complete text must be marked so the sender-SMTP knows when it
2973 can stop reading the reply. This requires a special format to
2974 indicate a multiple line reply.
2976 The format for multiline replies requires that every line,
2977 except the last, begin with the reply code, followed
2978 immediately by a hyphen, "-" (also known as minus), followed by
2979 text. The last line will begin with the reply code, followed
2980 immediately by <SP>, optionally some text, and <CRLF>.
2985 123-234 text beginning with numbers
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.
3010 Simple Mail Transfer Protocol
3018 This section presents complete scenarios of several types of SMTP
3021 A Typical SMTP Transaction Scenario
3023 This SMTP example shows mail sent by Smith at host USC-ISIF, to
3024 Jones, Green, and Brown at host BBN-UNIX. Here we assume that
3025 host USC-ISIF contacts host BBN-UNIX directly. The mail is
3026 accepted for Jones and Brown. Green does not have a mailbox at
3029 -------------------------------------------------------------
3031 R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
3032 S: HELO USC-ISIF.ARPA
3033 R: 250 BBN-UNIX.ARPA
3035 S: MAIL FROM:<Smith@USC-ISIF.ARPA>
3038 S: RCPT TO:<Jones@BBN-UNIX.ARPA>
3041 S: RCPT TO:<Green@BBN-UNIX.ARPA>
3042 R: 550 No such user here
3044 S: RCPT TO:<Brown@BBN-UNIX.ARPA>
3048 R: 354 Start mail input; end with <CRLF>.<CRLF>
3049 S: Blah blah blah...
3050 S: ...etc. etc. etc.
3055 R: 221 BBN-UNIX.ARPA Service closing transmission channel
3059 -------------------------------------------------------------
3068Simple Mail Transfer Protocol
3072 Aborted SMTP Transaction Scenario
3074 -------------------------------------------------------------
3076 R: 220 MIT-Multics.ARPA Simple Mail Transfer Service Ready
3077 S: HELO ISI-VAXA.ARPA
3078 R: 250 MIT-Multics.ARPA
3080 S: MAIL FROM:<Smith@ISI-VAXA.ARPA>
3083 S: RCPT TO:<Jones@MIT-Multics.ARPA>
3086 S: RCPT TO:<Green@MIT-Multics.ARPA>
3087 R: 550 No such user here
3093 R: 221 MIT-Multics.ARPA Service closing transmission channel
3097 -------------------------------------------------------------
3126 Simple Mail Transfer Protocol
3130 Relayed Mail Scenario
3132 -------------------------------------------------------------
3134 Step 1 -- Source Host to Relay Host
3136 R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
3138 R: 250 USC-ISIE.ARPA
3140 S: MAIL FROM:<JQP@MIT-AI.ARPA>
3143 S: RCPT TO:<@USC-ISIE.ARPA:Jones@BBN-VAX.ARPA>
3147 R: 354 Start mail input; end with <CRLF>.<CRLF>
3148 S: Date: 2 Nov 81 22:33:44
3149 S: From: John Q. Public <JQP@MIT-AI.ARPA>
3150 S: Subject: The Next Meeting of the Board
3151 S: To: Jones@BBN-Vax.ARPA
3154 S: The next meeting of the board of directors will be
3161 R: 221 USC-ISIE.ARPA Service closing transmission channel
3184Simple Mail Transfer Protocol
3188 Step 2 -- Relay Host to Destination Host
3190 R: 220 BBN-VAX.ARPA Simple Mail Transfer Service Ready
3191 S: HELO USC-ISIE.ARPA
3194 S: MAIL FROM:<@USC-ISIE.ARPA:JQP@MIT-AI.ARPA>
3197 S: RCPT TO:<Jones@BBN-VAX.ARPA>
3201 R: 354 Start mail input; end with <CRLF>.<CRLF>
3202 S: Received: from MIT-AI.ARPA by USC-ISIE.ARPA ;
3203 2 Nov 81 22:40:10 UT
3204 S: Date: 2 Nov 81 22:33:44
3205 S: From: John Q. Public <JQP@MIT-AI.ARPA>
3206 S: Subject: The Next Meeting of the Board
3207 S: To: Jones@BBN-Vax.ARPA
3210 S: The next meeting of the board of directors will be
3217 R: 221 USC-ISIE.ARPA Service closing transmission channel
3221 -------------------------------------------------------------
3242 Simple Mail Transfer Protocol
3246 Verifying and Sending Scenario
3248 -------------------------------------------------------------
3250 R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
3252 R: 250 SU-SCORE.ARPA
3255 R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA>
3257 S: SEND FROM:<EAK@MIT-MC.ARPA>
3260 S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
3264 R: 354 Start mail input; end with <CRLF>.<CRLF>
3265 S: Blah blah blah...
3266 S: ...etc. etc. etc.
3271 R: 221 SU-SCORE.ARPA Service closing transmission channel
3275 -------------------------------------------------------------
3300Simple Mail Transfer Protocol
3304 Sending and Mailing Scenarios
3306 First the user's name is verified, then an attempt is made to
3307 send to the user's terminal. When that fails, the messages is
3308 mailed to the user's mailbox.
3310 -------------------------------------------------------------
3312 R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
3314 R: 250 SU-SCORE.ARPA
3317 R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA>
3319 S: SEND FROM:<EAK@MIT-MC.ARPA>
3322 S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
3323 R: 450 User not active now
3328 S: MAIL FROM:<EAK@MIT-MC.ARPA>
3331 S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
3335 R: 354 Start mail input; end with <CRLF>.<CRLF>
3336 S: Blah blah blah...
3337 S: ...etc. etc. etc.
3342 R: 221 SU-SCORE.ARPA Service closing transmission channel
3346 -------------------------------------------------------------
3358 Simple Mail Transfer Protocol
3362 Doing the preceding scenario more efficiently.
3364 -------------------------------------------------------------
3366 R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
3368 R: 250 SU-SCORE.ARPA
3371 R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA>
3373 S: SOML FROM:<EAK@MIT-MC.ARPA>
3376 S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
3377 R: 250 User not active now, so will do mail.
3380 R: 354 Start mail input; end with <CRLF>.<CRLF>
3381 S: Blah blah blah...
3382 S: ...etc. etc. etc.
3387 R: 221 SU-SCORE.ARPA Service closing transmission channel
3391 -------------------------------------------------------------
3416Simple Mail Transfer Protocol
3420 Mailing List Scenario
3422 First each of two mailing lists are expanded in separate sessions
3423 with different hosts. Then the message is sent to everyone that
3424 appeared on either list (but no duplicates) via a relay host.
3426 -------------------------------------------------------------
3428 Step 1 -- Expanding the First List
3430 R: 220 MIT-AI.ARPA Simple Mail Transfer Service Ready
3431 S: HELO SU-SCORE.ARPA
3434 S: EXPN Example-People
3435 R: 250-<ABC@MIT-MC.ARPA>
3436 R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA>
3437 R: 250-Xenon Y. Zither <XYZ@MIT-AI.ARPA>
3438 R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
3439 R: 250-<joe@foo-unix.ARPA>
3440 R: 250 <xyz@bar-unix.ARPA>
3443 R: 221 MIT-AI.ARPA Service closing transmission channel
3474 Simple Mail Transfer Protocol
3478 Step 2 -- Expanding the Second List
3480 R: 220 MIT-MC.ARPA Simple Mail Transfer Service Ready
3481 S: HELO SU-SCORE.ARPA
3484 S: EXPN Interested-Parties
3485 R: 250-Al Calico <ABC@MIT-MC.ARPA>
3486 R: 250-<XYZ@MIT-AI.ARPA>
3487 R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
3488 R: 250-<fred@BBN-UNIX.ARPA>
3489 R: 250 <xyz@bar-unix.ARPA>
3492 R: 221 MIT-MC.ARPA Service closing transmission channel
3532Simple Mail Transfer Protocol
3536 Step 3 -- Mailing to All via a Relay Host
3538 R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
3539 S: HELO SU-SCORE.ARPA
3540 R: 250 USC-ISIE.ARPA
3542 S: MAIL FROM:<Account.Person@SU-SCORE.ARPA>
3544 S: RCPT TO:<@USC-ISIE.ARPA:ABC@MIT-MC.ARPA>
3546 S: RCPT TO:<@USC-ISIE.ARPA:Fonebone@USC-ISIQA.ARPA>
3548 S: RCPT TO:<@USC-ISIE.ARPA:XYZ@MIT-AI.ARPA>
3551 TO:<@USC-ISIE.ARPA,@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
3553 S: RCPT TO:<@USC-ISIE.ARPA:joe@FOO-UNIX.ARPA>
3555 S: RCPT TO:<@USC-ISIE.ARPA:xyz@BAR-UNIX.ARPA>
3557 S: RCPT TO:<@USC-ISIE.ARPA:fred@BBN-UNIX.ARPA>
3561 R: 354 Start mail input; end with <CRLF>.<CRLF>
3562 S: Blah blah blah...
3563 S: ...etc. etc. etc.
3568 R: 221 USC-ISIE.ARPA Service closing transmission channel
3572 -------------------------------------------------------------
3590 Simple Mail Transfer Protocol
3594 Forwarding Scenarios
3596 -------------------------------------------------------------
3598 R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready
3599 S: HELO LBL-UNIX.ARPA
3600 R: 250 USC-ISIF.ARPA
3602 S: MAIL FROM:<mo@LBL-UNIX.ARPA>
3605 S: RCPT TO:<fred@USC-ISIF.ARPA>
3606 R: 251 User not local; will forward to <Jones@USC-ISI.ARPA>
3609 R: 354 Start mail input; end with <CRLF>.<CRLF>
3610 S: Blah blah blah...
3611 S: ...etc. etc. etc.
3616 R: 221 USC-ISIF.ARPA Service closing transmission channel
3620 -------------------------------------------------------------
3648Simple Mail Transfer Protocol
3652 -------------------------------------------------------------
3654 Step 1 -- Trying the Mailbox at the First Host
3656 R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready
3657 S: HELO LBL-UNIX.ARPA
3658 R: 250 USC-ISIF.ARPA
3660 S: MAIL FROM:<mo@LBL-UNIX.ARPA>
3663 S: RCPT TO:<fred@USC-ISIF.ARPA>
3664 R: 251 User not local; will forward to <Jones@USC-ISI.ARPA>
3670 R: 221 USC-ISIF.ARPA Service closing transmission channel
3672 Step 2 -- Delivering the Mail at the Second Host
3674 R: 220 USC-ISI.ARPA Simple Mail Transfer Service Ready
3675 S: HELO LBL-UNIX.ARPA
3678 S: MAIL FROM:<mo@LBL-UNIX.ARPA>
3681 S: RCPT TO:<Jones@USC-ISI.ARPA>
3685 R: 354 Start mail input; end with <CRLF>.<CRLF>
3686 S: Blah blah blah...
3687 S: ...etc. etc. etc.
3692 R: 221 USC-ISI.ARPA Service closing transmission channel
3696 -------------------------------------------------------------
3706 Simple Mail Transfer Protocol
3710 Too Many Recipients Scenario
3712 -------------------------------------------------------------
3714 R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready
3715 S: HELO USC-ISIF.ARPA
3716 R: 250 BERKELEY.ARPA
3718 S: MAIL FROM:<Postel@USC-ISIF.ARPA>
3721 S: RCPT TO:<fabry@BERKELEY.ARPA>
3724 S: RCPT TO:<eric@BERKELEY.ARPA>
3725 R: 552 Recipient storage full, try again in another transaction
3728 R: 354 Start mail input; end with <CRLF>.<CRLF>
3729 S: Blah blah blah...
3730 S: ...etc. etc. etc.
3734 S: MAIL FROM:<Postel@USC-ISIF.ARPA>
3737 S: RCPT TO:<eric@BERKELEY.ARPA>
3741 R: 354 Start mail input; end with <CRLF>.<CRLF>
3742 S: Blah blah blah...
3743 S: ...etc. etc. etc.
3748 R: 221 BERKELEY.ARPA Service closing transmission channel
3752 -------------------------------------------------------------
3754 Note that a real implementation must handle many recipients as
3755 specified in Section 4.5.3.
3764Simple Mail Transfer Protocol
3772 American Standard Code for Information Interchange [1].
3776 A request for a mail service action sent by the sender-SMTP to the
3781 The hierarchially structured global character string address of a
3782 host computer in the mail system.
3784 end of mail data indication
3786 A special sequence of characters that indicates the end of the
3787 mail data. In particular, the five characters carriage return,
3788 line feed, period, carriage return, line feed, in that order.
3792 A computer in the internetwork environment on which mailboxes or
3793 SMTP processes reside.
3797 A a sequence of ASCII characters ending with a <CRLF>.
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]).
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
3822 Simple Mail Transfer Protocol
3826 receiver-SMTP process
3828 A process which transfers mail in cooperation with a sender-SMTP
3829 process. It waits for a connection to be established via the
3830 transport service. It receives SMTP commands from the
3831 sender-SMTP, sends replies, and performs the specified operations.
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
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.
3852 The set of exchanges that occur while the transmission channel is
3857 The set of exchanges required for one message to be transmitted
3858 for one or more recipients.
3860 transmission channel
3862 A full-duplex communication path between a sender-SMTP and a
3863 receiver-SMTP for the exchange of commands, replies, and mail
3868 Any reliable stream-oriented data communication services. For
3869 example, NCP, TCP, NITS.
3880Simple Mail Transfer Protocol
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
3892 A sequence of printing characters.
3896 The characters carriage return and line feed (in that order).
3900 The space character.
3938 Simple Mail Transfer Protocol
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.
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.
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.
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
3974 [5] Initial Connection Protocol
3976 Postel, J., "Official Initial Connection Protocol", NIC 7101,
3977 11 June 1971. Also in: Feinler, E. and J. Postel, eds., "ARPANET
3978 Protocol Handbook", NIC 7104, for the Defense Communications
3979 Agency by SRI International, Menlo Park, California, Revised
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.
3996Simple Mail Transfer Protocol
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.