smtp-rfc821.txt (115883B)
1 2 SIMPLE MAIL TRANSFER PROTOCOL 3 4 Jonathan B. Postel 5 6 August 1982 7 8 Information Sciences Institute 9 University of Southern California 10 4676 Admiralty Way 11 Marina del Rey, California 90291 12 13 (213) 822-1511 14 15 August 1982 16 Simple Mail Transfer Protocol 17 18 TABLE OF CONTENTS 19 20 1. INTRODUCTION .................................................. 1 21 22 2. THE SMTP MODEL ................................................ 2 23 24 3. THE SMTP PROCEDURE ............................................ 4 25 26 3.1. Mail ..................................................... 4 27 3.2. Forwarding ............................................... 7 28 3.3. Verifying and Expanding .................................. 8 29 3.4. Sending and Mailing ..................................... 11 30 3.5. Opening and Closing ..................................... 13 31 3.6. Relaying ................................................ 14 32 3.7. Domains ................................................. 17 33 3.8. Changing Roles .......................................... 18 34 35 4. THE SMTP SPECIFICATIONS ...................................... 19 36 37 4.1. SMTP Commands ........................................... 19 38 4.1.1. Command Semantics ..................................... 19 39 4.1.2. Command Syntax ........................................ 27 40 4.2. SMTP Replies ............................................ 34 41 4.2.1. Reply Codes by Function Group ......................... 35 42 4.2.2. Reply Codes in Numeric Order .......................... 36 43 4.3. Sequencing of Commands and Replies ...................... 37 44 4.4. State Diagrams .......................................... 39 45 4.5. Details ................................................. 41 46 4.5.1. Minimum Implementation ................................ 41 47 4.5.2. Transparency .......................................... 41 48 4.5.3. Sizes ................................................. 42 49 50 APPENDIX A: TCP ................................................. 44 51 APPENDIX B: NCP ................................................. 45 52 APPENDIX C: NITS ................................................ 46 53 APPENDIX D: X.25 ................................................ 47 54 APPENDIX E: Theory of Reply Codes ............................... 48 55 APPENDIX F: Scenarios ........................................... 51 56 57 GLOSSARY ......................................................... 64 58 59 REFERENCES ....................................................... 67 60 61 Network Working Group J. Postel 62 Request for Comments: DRAFT ISI 63 Replaces: _R_F_C_ _7_8_8, 780, 772 August 1982 64 65 SIMPLE MAIL TRANSFER PROTOCOL 66 67 1. INTRODUCTION 68 69 The objective of Simple Mail Transfer Protocol (SMTP) is to transfer 70 mail reliably and efficiently. 71 72 SMTP is independent of the particular transmission subsystem and 73 requires only a reliable ordered data stream channel. Appendices A, 74 B, C, and D describe the use of SMTP with various transport services. 75 A Glossary provides the definitions of terms as used in this 76 document. 77 78 An important feature of SMTP is its capability to relay mail across 79 transport service environments. A transport service provides an 80 interprocess communication environment (IPCE). An IPCE may cover one 81 network, several networks, or a subset of a network. It is important 82 to realize that transport systems (or IPCEs) are not one-to-one with 83 networks. A process can communicate directly with another process 84 through any mutually known IPCE. Mail is an application or use of 85 interprocess communication. Mail can be communicated between 86 processes in different IPCEs by relaying through a process connected 87 to two (or more) IPCEs. More specifically, mail can be relayed 88 between hosts on different transport systems by a host on both 89 transport systems. 90 91 August 1982 _R_F_C_ _8_2_1 92 Simple Mail Transfer Protocol 93 94 2. THE SMTP MODEL 95 96 The SMTP design is based on the following model of communication: as 97 the result of a user mail request, the sender-SMTP establishes a 98 two-way transmission channel to a receiver-SMTP. The receiver-SMTP 99 may be either the ultimate destination or an intermediate. SMTP 100 commands are generated by the sender-SMTP and sent to the 101 receiver-SMTP. SMTP replies are sent from the receiver-SMTP to the 102 sender-SMTP in response to the commands. 103 104 Once the transmission channel is established, the SMTP-sender sends a 105 MAIL command indicating the sender of the mail. If the SMTP-receiver 106 can accept mail it responds with an OK reply. The SMTP-sender then 107 sends a RCPT command identifying a recipient of the mail. If the 108 SMTP-receiver can accept mail for that recipient it responds with an 109 OK reply; if not, it responds with a reply rejecting that recipient 110 (but not the whole mail transaction). The SMTP-sender and 111 SMTP-receiver may negotiate several recipients. When the recipients 112 have been negotiated the SMTP-sender sends the mail data, terminating 113 with a special sequence. If the SMTP-receiver successfully processes 114 the mail data it responds with an OK reply. The dialog is purposely 115 lock-step, one-at-a-time. 116 117 ------------------------------------------------------------- 118 119 +----------+ +----------+ 120 +------+ | | | | 121 | User |<-->| | SMTP | | 122 +------+ | Sender- |Commands/Replies| Receiver-| 123 +------+ | SMTP |<-------------->| SMTP | +------+ 124 | File |<-->| | and Mail | |<-->| File | 125 |System| | | | | |System| 126 +------+ +----------+ +----------+ +------+ 127 128 Sender-SMTP Receiver-SMTP 129 130 Model for SMTP Use 131 132 Figure 1 133 134 ------------------------------------------------------------- 135 136 The SMTP provides mechanisms for the transmission of mail; directly 137 from the sending user's host to the receiving user's host when the 138 139 _R_F_C_ _8_2_1 August 1982 140 Simple Mail Transfer Protocol 141 142 two host are connected to the same transport service, or via one or 143 more relay SMTP-servers when the source and destination hosts are not 144 connected to the same transport service. 145 146 To be able to provide the relay capability the SMTP-server must be 147 supplied with the name of the ultimate destination host as well as 148 the destination mailbox name. 149 150 The argument to the MAIL command is a reverse-path, which specifies 151 who the mail is from. The argument to the RCPT command is a 152 forward-path, which specifies who the mail is to. The forward-path 153 is a source route, while the reverse-path is a return route (which 154 may be used to return a message to the sender when an error occurs 155 with a relayed message). 156 157 When the same message is sent to multiple recipients the SMTP 158 encourages the transmission of only one copy of the data for all the 159 recipients at the same destination host. 160 161 The mail commands and replies have a rigid syntax. Replies also have 162 a numeric code. In the following, examples appear which use actual 163 commands and replies. The complete lists of commands and replies 164 appears in Section 4 on specifications. 165 166 Commands and replies are not case sensitive. That is, a command or 167 reply word may be upper case, lower case, or any mixture of upper and 168 lower case. Note that this is not true of mailbox user names. For 169 some hosts the user name is case sensitive, and SMTP implementations 170 must take case to preserve the case of user names as they appear in 171 mailbox arguments. Host names are not case sensitive. 172 173 Commands and replies are composed of characters from the ASCII 174 character set [1]. When the transport service provides an 8-bit byte 175 (octet) transmission channel, each 7-bit character is transmitted 176 right justified in an octet with the high order bit cleared to zero. 177 178 When specifying the general form of a command or reply, an argument 179 (or special symbol) will be denoted by a meta-linguistic variable (or 180 constant), for example, "<string>" or "<reverse-path>". Here the 181 angle brackets indicate these are meta-linguistic variables. 182 However, some arguments use the angle brackets literally. For 183 example, an actual reverse-path is enclosed in angle brackets, i.e., 184 "<_J_o_h_n_._S_m_i_t_h_@_U_S_C_-_I_S_I_._A_R_P_A>" is an instance of <reverse-path> (the 185 angle brackets are actually transmitted in the command or reply). 186 187 August 1982 _R_F_C_ _8_2_1 188 Simple Mail Transfer Protocol 189 190 3. THE SMTP PROCEDURES 191 192 This section presents the procedures used in SMTP in several parts. 193 First comes the basic mail procedure defined as a mail transaction. 194 Following this are descriptions of forwarding mail, verifying mailbox 195 names and expanding mailing lists, sending to terminals instead of or 196 in combination with mailboxes, and the opening and closing exchanges. 197 At the end of this section are comments on relaying, a note on mail 198 domains, and a discussion of changing roles. Throughout this section 199 are examples of partial command and reply sequences, several complete 200 scenarios are presented in Appendix F. 201 202 3.1. MAIL 203 204 There are three steps to SMTP mail transactions. The transaction 205 is started with a MAIL command which gives the sender 206 identification. A series of one or more RCPT commands follows 207 giving the receiver information. Then a DATA command gives the 208 mail data. And finally, the end of mail data indicator confirms 209 the transaction. 210 211 The first step in the procedure is the MAIL command. The 212 <reverse-path> contains the source mailbox. 213 214 MAIL <SP> FROM:<reverse-path> <CRLF> 215 216 This command tells the SMTP-receiver that a new mail 217 transaction is starting and to reset all its state tables and 218 buffers, including any recipients or mail data. It gives the 219 reverse-path which can be used to report errors. If accepted, 220 the receiver-SMTP returns a 250 OK reply. 221 222 The <reverse-path> can contain more than just a mailbox. The 223 <reverse-path> is a reverse source routing list of hosts and 224 source mailbox. The first host in the <reverse-path> should be 225 the host sending this command. 226 227 The second step in the procedure is the RCPT command. 228 229 RCPT <SP> TO:<forward-path> <CRLF> 230 231 This command gives a forward-path identifying one recipient. 232 If accepted, the receiver-SMTP returns a 250 OK reply, and 233 stores the forward-path. If the recipient is unknown the 234 receiver-SMTP returns a 550 Failure reply. This second step of 235 the procedure can be repeated any number of times. 236 237 _R_F_C_ _8_2_1 August 1982 238 Simple Mail Transfer Protocol 239 240 The <forward-path> can contain more than just a mailbox. The 241 <forward-path> is a source routing list of hosts and the 242 destination mailbox. The first host in the <forward-path> 243 should be the host receiving this command. 244 245 The third step in the procedure is the DATA command. 246 247 DATA <CRLF> 248 249 If accepted, the receiver-SMTP returns a 354 Intermediate reply 250 and considers all succeeding lines to be the message text. 251 When the end of text is received and stored the SMTP-receiver 252 sends a 250 OK reply. 253 254 Since the mail data is sent on the transmission channel the end 255 of the mail data must be indicated so that the command and 256 reply dialog can be resumed. SMTP indicates the end of the 257 mail data by sending a line containing only a period. A 258 transparency procedure is used to prevent this from interfering 259 with the user's text (see Section 4.5.2). 260 261 Please note that the mail data includes the memo header 262 items such as Date, Subject, To, Cc, From [2]. 263 264 The end of mail data indicator also confirms the mail 265 transaction and tells the receiver-SMTP to now process the 266 stored recipients and mail data. If accepted, the 267 receiver-SMTP returns a 250 OK reply. The DATA command should 268 fail only if the mail transaction was incomplete (for example, 269 no recipients), or if resources are not available. 270 271 The above procedure is an example of a mail transaction. These 272 commands must be used only in the order discussed above. 273 Example 1 (below) illustrates the use of these commands in a mail 274 transaction. 275 276 August 1982 _R_F_C_ _8_2_1 277 Simple Mail Transfer Protocol 278 279 ------------------------------------------------------------- 280 281 Example of the SMTP Procedure 282 283 This SMTP example shows mail sent by Smith at host Alpha.ARPA, 284 to Jones, Green, and Brown at host Beta.ARPA. Here we assume 285 that host Alpha contacts host Beta directly. 286 287 S: MAIL FROM:<_S_m_i_t_h_@_A_l_p_h_a_._A_R_P_A> 288 R: 250 OK 289 290 S: RCPT TO:<_J_o_n_e_s_@_B_e_t_a_._A_R_P_A> 291 R: 250 OK 292 293 S: RCPT TO:<_G_r_e_e_n_@_B_e_t_a_._A_R_P_A> 294 R: 550 No such user here 295 296 S: RCPT TO:<_B_r_o_w_n_@_B_e_t_a_._A_R_P_A> 297 R: 250 OK 298 299 S: DATA 300 R: 354 Start mail input; end with <CRLF>.<CRLF> 301 S: Blah blah blah... 302 S: ...etc. etc. etc. 303 S: <CRLF>.<CRLF> 304 R: 250 OK 305 306 The mail has now been accepted for Jones and Brown. Green did 307 not have a mailbox at host Beta. 308 309 Example 1 310 311 ------------------------------------------------------------- 312 313 _R_F_C_ _8_2_1 August 1982 314 Simple Mail Transfer Protocol 315 316 3.2. FORWARDING 317 318 There are some cases where the destination information in the 319 <forward-path> is incorrect, but the receiver-SMTP knows the 320 correct destination. In such cases, one of the following replies 321 should be used to allow the sender to contact the correct 322 destination. 323 324 251 User not local; will forward to <forward-path> 325 326 This reply indicates that the receiver-SMTP knows the user's 327 mailbox is on another host and indicates the correct 328 forward-path to use in the future. Note that either the 329 host or user or both may be different. The receiver takes 330 responsibility for delivering the message. 331 332 551 User not local; please try <forward-path> 333 334 This reply indicates that the receiver-SMTP knows the user's 335 mailbox is on another host and indicates the correct 336 forward-path to use. Note that either the host or user or 337 both may be different. The receiver refuses to accept mail 338 for this user, and the sender must either redirect the mail 339 according to the information provided or return an error 340 response to the originating user. 341 342 Example 2 illustrates the use of these responses. 343 344 ------------------------------------------------------------- 345 346 Example of Forwarding 347 348 Either 349 350 S: RCPT TO:<_P_o_s_t_e_l_@_U_S_C_-_I_S_I_._A_R_P_A> 351 R: 251 User not local; will forward to <_P_o_s_t_e_l_@_U_S_C_-_I_S_I_F_._A_R_P_A> 352 353 Or 354 355 S: RCPT TO:<_P_a_u_l_@_U_S_C_-_I_S_I_B_._A_R_P_A> 356 R: 551 User not local; please try <_M_o_c_k_a_p_e_t_r_i_s_@_U_S_C_-_I_S_I_F_._A_R_P_A> 357 358 Example 2 359 360 ------------------------------------------------------------- 361 362 August 1982 _R_F_C_ _8_2_1 363 Simple Mail Transfer Protocol 364 365 3.3. VERIFYING AND EXPANDING 366 367 SMTP provides as additional features, commands to verify a user 368 name or expand a mailing list. This is done with the VRFY and 369 EXPN commands, which have character string arguments. For the 370 VRFY command, the string is a user name, and the response may 371 include the full name of the user and must include the mailbox of 372 the user. For the EXPN command, the string identifies a mailing 373 list, and the multiline response may include the full name of the 374 users and must give the mailboxes on the mailing list. 375 376 "User name" is a fuzzy term and used purposely. If a host 377 implements the VRFY or EXPN commands then at least local mailboxes 378 must be recognized as "user names". If a host chooses to 379 recognize other strings as "user names" that is allowed. 380 381 In some hosts the distinction between a mailing list and an alias 382 for a single mailbox is a bit fuzzy, since a common data structure 383 may hold both types of entries, and it is possible to have mailing 384 lists of one mailbox. If a request is made to verify a mailing 385 list a positive response can be given if on receipt of a message 386 so addressed it will be delivered to everyone on the list, 387 otherwise an error should be reported (e.g., "550 That is a 388 mailing list, not a user"). If a request is made to expand a user 389 name a positive response can be formed by returning a list 390 containing one name, or an error can be reported (e.g., "550 That 391 is a user name, not a mailing list"). 392 393 In the case of a multiline reply (normal for EXPN) exactly one 394 mailbox is to be specified on each line of the reply. In the case 395 of an ambiguous request, for example, "VRFY Smith", where there 396 are two Smith's the response must be "553 User ambiguous". 397 398 The case of verifying a user name is straightforward as shown in 399 example 3. 400 401 _R_F_C_ _8_2_1 August 1982 402 Simple Mail Transfer Protocol 403 404 ------------------------------------------------------------- 405 406 Example of Verifying a User Name 407 408 Either 409 410 S: VRFY Smith 411 R: 250 Fred Smith <_S_m_i_t_h_@_U_S_C_-_I_S_I_F_._A_R_P_A> 412 413 Or 414 415 S: VRFY Smith 416 R: 251 User not local; will forward to <_S_m_i_t_h_@_U_S_C_-_I_S_I_Q_._A_R_P_A> 417 418 Or 419 420 S: VRFY Jones 421 R: 550 String does not match anything. 422 423 Or 424 425 S: VRFY Jones 426 R: 551 User not local; please try <_J_o_n_e_s_@_U_S_C_-_I_S_I_Q_._A_R_P_A> 427 428 Or 429 430 S: VRFY Gourzenkyinplatz 431 R: 553 User ambiguous. 432 433 Example 3 434 435 ------------------------------------------------------------- 436 437 August 1982 _R_F_C_ _8_2_1 438 Simple Mail Transfer Protocol 439 440 The case of expanding a mailbox list requires a multiline reply as 441 shown in example 4. 442 443 ------------------------------------------------------------- 444 445 Example of Expanding a Mailing List 446 447 Either 448 449 S: EXPN Example-People 450 R: 250-Jon Postel <_P_o_s_t_e_l_@_U_S_C_-_I_S_I_F_._A_R_P_A> 451 R: 250-Fred Fonebone <_F_o_n_e_b_o_n_e_@_U_S_C_-_I_S_I_Q_._A_R_P_A> 452 R: 250-Sam Q. Smith <_S_Q_S_m_i_t_h_@_U_S_C_-_I_S_I_Q_._A_R_P_A> 453 R: 250-Quincy Smith <@USC-ISIF.ARPA:_Q_-_S_m_i_t_h_@_I_S_I_-_V_A_X_A_._A_R_P_A> 454 R: 250-<_j_o_e_@_f_o_o_-_u_n_i_x_._A_R_P_A> 455 R: 250 <_x_y_z_@_b_a_r_-_u_n_i_x_._A_R_P_A> 456 457 Or 458 459 S: EXPN Executive-Washroom-List 460 R: 550 Access Denied to You. 461 462 Example 4 463 464 ------------------------------------------------------------- 465 466 The character string arguments of the VRFY and EXPN commands 467 cannot be further restricted due to the variety of implementations 468 of the user name and mailbox list concepts. On some systems it 469 may be appropriate for the argument of the EXPN command to be a 470 file name for a file containing a mailing list, but again there is 471 a variety of file naming conventions in the Internet. 472 473 The VRFY and EXPN commands are not included in the minimum 474 implementation (Section 4.5.1), and are not required to work 475 across relays when they are implemented. 476 477 _R_F_C_ _8_2_1 August 1982 478 Simple Mail Transfer Protocol 479 480 3.4. SENDING AND MAILING 481 482 The main purpose of SMTP is to deliver messages to user's 483 mailboxes. A very similar service provided by some hosts is to 484 deliver messages to user's terminals (provided the user is active 485 on the host). The delivery to the user's mailbox is called 486 "mailing", the delivery to the user's terminal is called 487 "sending". Because in many hosts the implementation of sending is 488 nearly identical to the implementation of mailing these two 489 functions are combined in SMTP. However the sending commands are 490 not included in the required minimum implementation 491 (Section 4.5.1). Users should have the ability to control the 492 writing of messages on their terminals. Most hosts permit the 493 users to accept or refuse such messages. 494 495 The following three command are defined to support the sending 496 options. These are used in the mail transaction instead of the 497 MAIL command and inform the receiver-SMTP of the special semantics 498 of this transaction: 499 500 SEND <SP> FROM:<reverse-path> <CRLF> 501 502 The SEND command requires that the mail data be delivered to 503 the user's terminal. If the user is not active (or not 504 accepting terminal messages) on the host a 450 reply may 505 returned to a RCPT command. The mail transaction is 506 successful if the message is delivered the terminal. 507 508 SOML <SP> FROM:<reverse-path> <CRLF> 509 510 The Send Or MaiL command requires that the mail data be 511 delivered to the user's terminal if the user is active (and 512 accepting terminal messages) on the host. If the user is 513 not active (or not accepting terminal messages) then the 514 mail data is entered into the user's mailbox. The mail 515 transaction is successful if the message is delivered either 516 to the terminal or the mailbox. 517 518 SAML <SP> FROM:<reverse-path> <CRLF> 519 520 The Send And MaiL command requires that the mail data be 521 delivered to the user's terminal if the user is active (and 522 accepting terminal messages) on the host. In any case the 523 mail data is entered into the user's mailbox. The mail 524 transaction is successful if the message is delivered the 525 mailbox. 526 527 August 1982 _R_F_C_ _8_2_1 528 Simple Mail Transfer Protocol 529 530 The same reply codes that are used for the MAIL commands are used 531 for these commands. 532 533 _R_F_C_ _8_2_1 August 1982 534 Simple Mail Transfer Protocol 535 536 3.5. OPENING AND CLOSING 537 538 At the time the transmission channel is opened there is an 539 exchange to ensure that the hosts are communicating with the hosts 540 they think they are. 541 542 The following two commands are used in transmission channel 543 opening and closing: 544 545 HELO <SP> <domain> <CRLF> 546 547 QUIT <CRLF> 548 549 In the HELO command the host sending the command identifies 550 itself; the command may be interpreted as saying "Hello, I am 551 <domain>". 552 553 ------------------------------------------------------------- 554 555 Example of Connection Opening 556 557 R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready 558 S: HELO USC-ISIF.ARPA 559 R: 250 BBN-UNIX.ARPA 560 561 Example 5 562 563 ------------------------------------------------------------- 564 565 ------------------------------------------------------------- 566 567 Example of Connection Closing 568 569 S: QUIT 570 R: 221 BBN-UNIX.ARPA Service closing transmission channel 571 572 Example 6 573 574 ------------------------------------------------------------- 575 576 August 1982 _R_F_C_ _8_2_1 577 Simple Mail Transfer Protocol 578 579 3.6. RELAYING 580 581 The forward-path may be a source route of the form 582 "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE are hosts. This 583 form is used to emphasize the distinction between an address and a 584 route. The mailbox is an absolute address, and the route is 585 information about how to get there. The two concepts should not 586 be confused. 587 588 Conceptually the elements of the forward-path are moved to the 589 reverse-path as the message is relayed from one server-SMTP to 590 another. The reverse-path is a reverse source route, (i.e., a 591 source route from the current location of the message to the 592 originator of the message). When a server-SMTP deletes its 593 identifier from the forward-path and inserts it into the 594 reverse-path, it must use the name it is known by in the 595 environment it is sending into, not the environment the mail came 596 from, in case the server-SMTP is known by different names in 597 different environments. 598 599 If when the message arrives at an SMTP the first element of the 600 forward-path is not the identifier of that SMTP the element is not 601 deleted from the forward-path and is used to determine the next 602 SMTP to send the message to. In any case, the SMTP adds its own 603 identifier to the reverse-path. 604 605 Using source routing the receiver-SMTP receives mail to be relayed 606 to another server-SMTP The receiver-SMTP may accept or reject the 607 task of relaying the mail in the same way it accepts or rejects 608 mail for a local user. The receiver-SMTP transforms the command 609 arguments by moving its own identifier from the forward-path to 610 the beginning of the reverse-path. The receiver-SMTP then becomes 611 a sender-SMTP, establishes a transmission channel to the next SMTP 612 in the forward-path, and sends it the mail. 613 614 The first host in the reverse-path should be the host sending the 615 SMTP commands, and the first host in the forward-path should be 616 the host receiving the SMTP commands. 617 618 Notice that the forward-path and reverse-path appear in the SMTP 619 commands and replies, but not necessarily in the message. That 620 is, there is no need for these paths and especially this syntax to 621 appear in the "To:" , "From:", "CC:", etc. fields of the message 622 header. 623 624 If a server-SMTP has accepted the task of relaying the mail and 625 626 _R_F_C_ _8_2_1 August 1982 627 Simple Mail Transfer Protocol 628 629 later finds that the forward-path is incorrect or that the mail 630 cannot be delivered for whatever reason, then it must construct an 631 "undeliverable mail" notification message and send it to the 632 originator of the undeliverable mail (as indicated by the 633 reverse-path). 634 635 This notification message must be from the server-SMTP at this 636 host. Of course, server-SMTPs should not send notification 637 messages about problems with notification messages. One way to 638 prevent loops in error reporting is to specify a null reverse-path 639 in the MAIL command of a notification message. When such a 640 message is relayed it is permissible to leave the reverse-path 641 null. A MAIL command with a null reverse-path appears as follows: 642 643 MAIL FROM:<> 644 645 An undeliverable mail notification message is shown in example 7. 646 This notification is in response to a message originated by JOE at 647 HOSTW and sent via HOSTX to HOSTY with instructions to relay it on 648 to HOSTZ. What we see in the example is the transaction between 649 HOSTY and HOSTX, which is the first step in the return of the 650 notification message. 651 652 August 1982 _R_F_C_ _8_2_1 653 Simple Mail Transfer Protocol 654 655 ------------------------------------------------------------- 656 657 Example Undeliverable Mail Notification Message 658 659 S: MAIL FROM:<> 660 R: 250 ok 661 S: RCPT TO:<@HOSTX.ARPA:_J_O_E_@_H_O_S_T_W_._A_R_P_A> 662 R: 250 ok 663 S: DATA 664 R: 354 send the mail data, end with . 665 S: Date: 23 Oct 81 11:22:33 666 S: From: _S_M_T_P_@_H_O_S_T_Y_._A_R_P_A 667 S: To: _J_O_E_@_H_O_S_T_W_._A_R_P_A 668 S: Subject: Mail System Problem 669 S: 670 S: Sorry JOE, your message to _S_A_M_@_H_O_S_T_Z_._A_R_P_A lost. 671 S: HOSTZ.ARPA said this: 672 S: "550 No Such User" 673 S: . 674 R: 250 ok 675 676 Example 7 677 678 ------------------------------------------------------------- 679 680 _R_F_C_ _8_2_1 August 1982 681 Simple Mail Transfer Protocol 682 683 3.7. DOMAINS 684 685 Domains are a recently introduced concept in the ARPA Internet 686 mail system. The use of domains changes the address space from a 687 flat global space of simple character string host names to a 688 hierarchically structured rooted tree of global addresses. The 689 host name is replaced by a domain and host designator which is a 690 sequence of domain element strings separated by periods with the 691 understanding that the domain elements are ordered from the most 692 specific to the most general. 693 694 For example, "USC-ISIF.ARPA", "Fred.Cambridge.UK", and 695 "PC7.LCS.MIT.ARPA" might be host-and-domain identifiers. 696 697 Whenever domain names are used in SMTP only the official names are 698 used, the use of nicknames or aliases is not allowed. 699 700 August 1982 _R_F_C_ _8_2_1 701 Simple Mail Transfer Protocol 702 703 3.8. CHANGING ROLES 704 705 The TURN command may be used to reverse the roles of the two 706 programs communicating over the transmission channel. 707 708 If program-A is currently the sender-SMTP and it sends the TURN 709 command and receives an ok reply (250) then program-A becomes the 710 receiver-SMTP. 711 712 If program-B is currently the receiver-SMTP and it receives the 713 TURN command and sends an ok reply (250) then program-B becomes 714 the sender-SMTP. 715 716 To refuse to change roles the receiver sends the 502 reply. 717 718 Please note that this command is optional. It would not normally 719 be used in situations where the transmission channel is TCP. 720 However, when the cost of establishing the transmission channel is 721 high, this command may be quite useful. For example, this command 722 may be useful in supporting be mail exchange using the public 723 switched telephone system as a transmission channel, especially if 724 some hosts poll other hosts for mail exchanges. 725 726 _R_F_C_ _8_2_1 August 1982 727 Simple Mail Transfer Protocol 728 729 4. THE SMTP SPECIFICATIONS 730 731 4.1. SMTP COMMANDS 732 733 4.1.1. COMMAND SEMANTICS 734 735 The SMTP commands define the mail transfer or the mail system 736 function requested by the user. SMTP commands are character 737 strings terminated by <CRLF>. The command codes themselves are 738 alphabetic characters terminated by <SP> if parameters follow 739 and <CRLF> otherwise. The syntax of mailboxes must conform to 740 receiver site conventions. The SMTP commands are discussed 741 below. The SMTP replies are discussed in the Section 4.2. 742 743 A mail transaction involves several data objects which are 744 communicated as arguments to different commands. The 745 reverse-path is the argument of the MAIL command, the 746 forward-path is the argument of the RCPT command, and the mail 747 data is the argument of the DATA command. These arguments or 748 data objects must be transmitted and held pending the 749 confirmation communicated by the end of mail data indication 750 which finalizes the transaction. The model for this is that 751 distinct buffers are provided to hold the types of data 752 objects, that is, there is a reverse-path buffer, a 753 forward-path buffer, and a mail data buffer. Specific commands 754 cause information to be appended to a specific buffer, or cause 755 one or more buffers to be cleared. 756 757 HELLO (HELO) 758 759 This command is used to identify the sender-SMTP to the 760 receiver-SMTP. The argument field contains the host name of 761 the sender-SMTP. 762 763 The receiver-SMTP identifies itself to the sender-SMTP in 764 the connection greeting reply, and in the response to this 765 command. 766 767 This command and an OK reply to it confirm that both the 768 sender-SMTP and the receiver-SMTP are in the initial state, 769 that is, there is no transaction in progress and all state 770 tables and buffers are cleared. 771 772 August 1982 _R_F_C_ _8_2_1 773 Simple Mail Transfer Protocol 774 775 MAIL (MAIL) 776 777 This command is used to initiate a mail transaction in which 778 the mail data is delivered to one or more mailboxes. The 779 argument field contains a reverse-path. 780 781 The reverse-path consists of an optional list of hosts and 782 the sender mailbox. When the list of hosts is present, it 783 is a "reverse" source route and indicates that the mail was 784 relayed through each host on the list (the first host in the 785 list was the most recent relay). This list is used as a 786 source route to return non-delivery notices to the sender. 787 As each relay host adds itself to the beginning of the list, 788 it must use its name as known in the IPCE to which it is 789 relaying the mail rather than the IPCE from which the mail 790 came (if they are different). In some types of error 791 reporting messages (for example, undeliverable mail 792 notifications) the reverse-path may be null (see Example 7). 793 794 This command clears the reverse-path buffer, the 795 forward-path buffer, and the mail data buffer; and inserts 796 the reverse-path information from this command into the 797 reverse-path buffer. 798 799 RECIPIENT (RCPT) 800 801 This command is used to identify an individual recipient of 802 the mail data; multiple recipients are specified by multiple 803 use of this command. 804 805 The forward-path consists of an optional list of hosts and a 806 required destination mailbox. When the list of hosts is 807 present, it is a source route and indicates that the mail 808 must be relayed to the next host on the list. If the 809 receiver-SMTP does not implement the relay function it may 810 user the same reply it would for an unknown local user 811 (550). 812 813 When mail is relayed, the relay host must remove itself from 814 the beginning forward-path and put itself at the beginning 815 of the reverse-path. When mail reaches its ultimate 816 destination (the forward-path contains only a destination 817 mailbox), the receiver-SMTP inserts it into the destination 818 mailbox in accordance with its host mail conventions. 819 820 _R_F_C_ _8_2_1 August 1982 821 Simple Mail Transfer Protocol 822 823 For example, mail received at relay host A with arguments 824 825 FROM:<_U_S_E_R_X_@_H_O_S_T_Y_._A_R_P_A> 826 TO:<@HOSTA.ARPA,@HOSTB.ARPA:_U_S_E_R_C_@_H_O_S_T_D_._A_R_P_A> 827 828 will be relayed on to host B with arguments 829 830 FROM:<@HOSTA.ARPA:_U_S_E_R_X_@_H_O_S_T_Y_._A_R_P_A> 831 TO:<@HOSTB.ARPA:_U_S_E_R_C_@_H_O_S_T_D_._A_R_P_A>. 832 833 This command causes its forward-path argument to be appended 834 to the forward-path buffer. 835 836 DATA (DATA) 837 838 The receiver treats the lines following the command as mail 839 data from the sender. This command causes the mail data 840 from this command to be appended to the mail data buffer. 841 The mail data may contain any of the 128 ASCII character 842 codes. 843 844 The mail data is terminated by a line containing only a 845 period, that is the character sequence "<CRLF>.<CRLF>" (see 846 Section 4.5.2 on Transparency). This is the end of mail 847 data indication. 848 849 The end of mail data indication requires that the receiver 850 must now process the stored mail transaction information. 851 This processing consumes the information in the reverse-path 852 buffer, the forward-path buffer, and the mail data buffer, 853 and on the completion of this command these buffers are 854 cleared. If the processing is successful the receiver must 855 send an OK reply. If the processing fails completely the 856 receiver must send a failure reply. 857 858 When the receiver-SMTP accepts a message either for relaying 859 or for final delivery it inserts at the beginning of the 860 mail data a time stamp line. The time stamp line indicates 861 the identity of the host that sent the message, and the 862 identity of the host that received the message (and is 863 inserting this time stamp), and the date and time the 864 message was received. Relayed messages will have multiple 865 time stamp lines. 866 867 When the receiver-SMTP makes the "final delivery" of a 868 message it inserts at the beginning of the mail data a 869 870 August 1982 _R_F_C_ _8_2_1 871 Simple Mail Transfer Protocol 872 873 return path line. The return path line preserves the 874 information in the <reverse-path> from the MAIL command. 875 Here, final delivery means the message leaves the SMTP 876 world. Normally, this would mean it has been delivered to 877 the destination user, but in some cases it may be further 878 processed and transmitted by another mail system. 879 880 It is possible for the mailbox in the return path be 881 different from the actual sender's mailbox, for example, 882 if error responses are to be delivered a special error 883 handling mailbox rather than the message senders. 884 885 The preceding two paragraphs imply that the final mail data 886 will begin with a return path line, followed by one or more 887 time stamp lines. These lines will be followed by the mail 888 data header and body [2]. See Example 8. 889 890 Special mention is needed of the response and further action 891 required when the processing following the end of mail data 892 indication is partially successful. This could arise if 893 after accepting several recipients and the mail data, the 894 receiver-SMTP finds that the mail data can be successfully 895 delivered to some of the recipients, but it cannot be to 896 others (for example, due to mailbox space allocation 897 problems). In such a situation, the response to the DATA 898 command must be an OK reply. But, the receiver-SMTP must 899 compose and send an "undeliverable mail" notification 900 message to the originator of the message. Either a single 901 notification which lists all of the recipients that failed 902 to get the message, or separate notification messages must 903 be sent for each failed recipient (see Example 7). All 904 undeliverable mail notification messages are sent using the 905 MAIL command (even if they result from processing a SEND, 906 SOML, or SAML command). 907 908 _R_F_C_ _8_2_1 August 1982 909 Simple Mail Transfer Protocol 910 911 ------------------------------------------------------------- 912 913 Example of Return Path and Received Time Stamps 914 915 Return-Path: <@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:_J_O_E_@_A_B_C_._A_R_P_A> 916 Received: from GHI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 PST 917 Received: from DEF.ARPA by GHI.ARPA ; 27 Oct 81 15:15:13 PST 918 Received: from ABC.ARPA by DEF.ARPA ; 27 Oct 81 15:01:59 PST 919 Date: 27 Oct 81 15:01:01 PST 920 From: _J_O_E_@_A_B_C_._A_R_P_A 921 Subject: Improved Mailing System Installed 922 To: _S_A_M_@_J_K_L_._A_R_P_A 923 924 This is to inform you that ... 925 926 Example 8 927 928 ------------------------------------------------------------- 929 930 SEND (SEND) 931 932 This command is used to initiate a mail transaction in which 933 the mail data is delivered to one or more terminals. The 934 argument field contains a reverse-path. This command is 935 successful if the message is delivered to a terminal. 936 937 The reverse-path consists of an optional list of hosts and 938 the sender mailbox. When the list of hosts is present, it 939 is a "reverse" source route and indicates that the mail was 940 relayed through each host on the list (the first host in the 941 list was the most recent relay). This list is used as a 942 source route to return non-delivery notices to the sender. 943 As each relay host adds itself to the beginning of the list, 944 it must use its name as known in the IPCE to which it is 945 relaying the mail rather than the IPCE from which the mail 946 came (if they are different). 947 948 This command clears the reverse-path buffer, the 949 forward-path buffer, and the mail data buffer; and inserts 950 the reverse-path information from this command into the 951 reverse-path buffer. 952 953 SEND OR MAIL (SOML) 954 955 This command is used to initiate a mail transaction in which 956 the mail data is delivered to one or more terminals or 957 958 August 1982 _R_F_C_ _8_2_1 959 Simple Mail Transfer Protocol 960 961 mailboxes. For each recipient the mail data is delivered to 962 the recipient's terminal if the recipient is active on the 963 host (and accepting terminal messages), otherwise to the 964 recipient's mailbox. The argument field contains a 965 reverse-path. This command is successful if the message is 966 delivered to a terminal or the mailbox. 967 968 The reverse-path consists of an optional list of hosts and 969 the sender mailbox. When the list of hosts is present, it 970 is a "reverse" source route and indicates that the mail was 971 relayed through each host on the list (the first host in the 972 list was the most recent relay). This list is used as a 973 source route to return non-delivery notices to the sender. 974 As each relay host adds itself to the beginning of the list, 975 it must use its name as known in the IPCE to which it is 976 relaying the mail rather than the IPCE from which the mail 977 came (if they are different). 978 979 This command clears the reverse-path buffer, the 980 forward-path buffer, and the mail data buffer; and inserts 981 the reverse-path information from this command into the 982 reverse-path buffer. 983 984 SEND AND MAIL (SAML) 985 986 This command is used to initiate a mail transaction in which 987 the mail data is delivered to one or more terminals and 988 mailboxes. For each recipient the mail data is delivered to 989 the recipient's terminal if the recipient is active on the 990 host (and accepting terminal messages), and for all 991 recipients to the recipient's mailbox. The argument field 992 contains a reverse-path. This command is successful if the 993 message is delivered to the mailbox. 994 995 The reverse-path consists of an optional list of hosts and 996 the sender mailbox. When the list of hosts is present, it 997 is a "reverse" source route and indicates that the mail was 998 relayed through each host on the list (the first host in the 999 list was the most recent relay). This list is used as a 1000 source route to return non-delivery notices to the sender. 1001 As each relay host adds itself to the beginning of the list, 1002 it must use its name as known in the IPCE to which it is 1003 relaying the mail rather than the IPCE from which the mail 1004 came (if they are different). 1005 1006 This command clears the reverse-path buffer, the 1007 1008 _R_F_C_ _8_2_1 August 1982 1009 Simple Mail Transfer Protocol 1010 1011 forward-path buffer, and the mail data buffer; and inserts 1012 the reverse-path information from this command into the 1013 reverse-path buffer. 1014 1015 RESET (RSET) 1016 1017 This command specifies that the current mail transaction is 1018 to be aborted. Any stored sender, recipients, and mail data 1019 must be discarded, and all buffers and state tables cleared. 1020 The receiver must send an OK reply. 1021 1022 VERIFY (VRFY) 1023 1024 This command asks the receiver to confirm that the argument 1025 identifies a user. If it is a user name, the full name of 1026 the user (if known) and the fully specified mailbox are 1027 returned. 1028 1029 This command has no effect on any of the reverse-path 1030 buffer, the forward-path buffer, or the mail data buffer. 1031 1032 EXPAND (EXPN) 1033 1034 This command asks the receiver to confirm that the argument 1035 identifies a mailing list, and if so, to return the 1036 membership of that list. The full name of the users (if 1037 known) and the fully specified mailboxes are returned in a 1038 multiline reply. 1039 1040 This command has no effect on any of the reverse-path 1041 buffer, the forward-path buffer, or the mail data buffer. 1042 1043 HELP (HELP) 1044 1045 This command causes the receiver to send helpful information 1046 to the sender of the HELP command. The command may take an 1047 argument (e.g., any command name) and return more specific 1048 information as a response. 1049 1050 This command has no effect on any of the reverse-path 1051 buffer, the forward-path buffer, or the mail data buffer. 1052 1053 August 1982 _R_F_C_ _8_2_1 1054 Simple Mail Transfer Protocol 1055 1056 NOOP (NOOP) 1057 1058 This command does not affect any parameters or previously 1059 entered commands. It specifies no action other than that 1060 the receiver send an OK reply. 1061 1062 This command has no effect on any of the reverse-path 1063 buffer, the forward-path buffer, or the mail data buffer. 1064 1065 QUIT (QUIT) 1066 1067 This command specifies that the receiver must send an OK 1068 reply, and then close the transmission channel. 1069 1070 The receiver should not close the transmission channel until 1071 it receives and replies to a QUIT command (even if there was 1072 an error). The sender should not close the transmission 1073 channel until it send a QUIT command and receives the reply 1074 (even if there was an error response to a previous command). 1075 If the connection is closed prematurely the receiver should 1076 act as if a RSET command had been received (canceling any 1077 pending transaction, but not undoing any previously 1078 completed transaction), the sender should act as if the 1079 command or transaction in progress had received a temporary 1080 error (4xx). 1081 1082 TURN (TURN) 1083 1084 This command specifies that the receiver must either (1) 1085 send an OK reply and then take on the role of the 1086 sender-SMTP, or (2) send a refusal reply and retain the role 1087 of the receiver-SMTP. 1088 1089 If program-A is currently the sender-SMTP and it sends the 1090 TURN command and receives an OK reply (250) then program-A 1091 becomes the receiver-SMTP. Program-A is then in the initial 1092 state as if the transmission channel just opened, and it 1093 then sends the 220 service ready greeting. 1094 1095 If program-B is currently the receiver-SMTP and it receives 1096 the TURN command and sends an OK reply (250) then program-B 1097 becomes the sender-SMTP. Program-B is then in the initial 1098 state as if the transmission channel just opened, and it 1099 then expects to receive the 220 service ready greeting. 1100 1101 To refuse to change roles the receiver sends the 502 reply. 1102 1103 _R_F_C_ _8_2_1 August 1982 1104 Simple Mail Transfer Protocol 1105 1106 There are restrictions on the order in which these command may 1107 be used. 1108 1109 The first command in a session must be the HELO command. 1110 The HELO command may be used later in a session as well. If 1111 the HELO command argument is not acceptable a 501 failure 1112 reply must be returned and the receiver-SMTP must stay in 1113 the same state. 1114 1115 The NOOP, HELP, EXPN, and VRFY commands can be used at any 1116 time during a session. 1117 1118 The MAIL, SEND, SOML, or SAML commands begin a mail 1119 transaction. Once started a mail transaction consists of 1120 one of the transaction beginning commands, one or more RCPT 1121 commands, and a DATA command, in that order. A mail 1122 transaction may be aborted by the RSET command. There may 1123 be zero or more transactions in a session. 1124 1125 If the transaction beginning command argument is not 1126 acceptable a 501 failure reply must be returned and the 1127 receiver-SMTP must stay in the same state. If the commands 1128 in a transaction are out of order a 503 failure reply must 1129 be returned and the receiver-SMTP must stay in the same 1130 state. 1131 1132 The last command in a session must be the QUIT command. The 1133 QUIT command can not be used at any other time in a session. 1134 1135 4.1.2. COMMAND SYNTAX 1136 1137 The commands consist of a command code followed by an argument 1138 field. Command codes are four alphabetic characters. Upper 1139 and lower case alphabetic characters are to be treated 1140 identically. Thus, any of the following may represent the mail 1141 command: 1142 1143 MAIL Mail mail MaIl mAIl 1144 1145 This also applies to any symbols representing parameter values, 1146 such as "TO" or "to" for the forward-path. Command codes and 1147 the argument fields are separated by one or more spaces. 1148 However, within the reverse-path and forward-path arguments 1149 case is important. In particular, in some hosts the user 1150 "smith" is different from the user "Smith". 1151 1152 August 1982 _R_F_C_ _8_2_1 1153 Simple Mail Transfer Protocol 1154 1155 The argument field consists of a variable length character 1156 string ending with the character sequence <CRLF>. The receiver 1157 is to take no action until this sequence is received. 1158 1159 Square brackets denote an optional argument field. If the 1160 option is not taken, the appropriate default is implied. 1161 1162 _R_F_C_ _8_2_1 August 1982 1163 Simple Mail Transfer Protocol 1164 1165 The following are the SMTP commands: 1166 1167 HELO <SP> <domain> <CRLF> 1168 1169 MAIL <SP> FROM:<reverse-path> <CRLF> 1170 1171 RCPT <SP> TO:<forward-path> <CRLF> 1172 1173 DATA <CRLF> 1174 1175 RSET <CRLF> 1176 1177 SEND <SP> FROM:<reverse-path> <CRLF> 1178 1179 SOML <SP> FROM:<reverse-path> <CRLF> 1180 1181 SAML <SP> FROM:<reverse-path> <CRLF> 1182 1183 VRFY <SP> <string> <CRLF> 1184 1185 EXPN <SP> <string> <CRLF> 1186 1187 HELP [<SP> <string>] <CRLF> 1188 1189 NOOP <CRLF> 1190 1191 QUIT <CRLF> 1192 1193 TURN <CRLF> 1194 1195 August 1982 _R_F_C_ _8_2_1 1196 Simple Mail Transfer Protocol 1197 1198 The syntax of the above argument fields (using BNF notation 1199 where applicable) is given below. The "..." notation indicates 1200 that a field may be repeated one or more times. 1201 1202 <reverse-path> ::= <path> 1203 1204 <forward-path> ::= <path> 1205 1206 <path> ::= "<" [ <a-d-l> ":" ] <mailbox> ">" 1207 1208 <a-d-l> ::= <at-domain> | <at-domain> "," <a-d-l> 1209 1210 <at-domain> ::= "@" <domain> 1211 1212 <domain> ::= <element> | <element> "." <domain> 1213 1214 <element> ::= <name> | "#" <number> | "[" <dotnum> "]" 1215 1216 <mailbox> ::= <local-part> "@" <domain> 1217 1218 <local-part> ::= <dot-string> | <quoted-string> 1219 1220 <name> ::= <a> <ldh-str> <let-dig> 1221 1222 <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str> 1223 1224 <let-dig> ::= <a> | <d> 1225 1226 <let-dig-hyp> ::= <a> | <d> | "-" 1227 1228 <dot-string> ::= <string> | <string> "." <dot-string> 1229 1230 <string> ::= <char> | <char> <string> 1231 1232 <quoted-string> ::= """ <qtext> """ 1233 1234 <qtext> ::= "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext> 1235 1236 <char> ::= <c> | "\" <x> 1237 1238 <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum> 1239 1240 <number> ::= <d> | <d> <number> 1241 1242 <CRLF> ::= <CR> <LF> 1243 1244 _R_F_C_ _8_2_1 August 1982 1245 Simple Mail Transfer Protocol 1246 1247 <CR> ::= the carriage return character (ASCII code 13) 1248 1249 <LF> ::= the line feed character (ASCII code 10) 1250 1251 <SP> ::= the space character (ASCII code 32) 1252 1253 <snum> ::= one, two, or three digits representing a decimal 1254 integer value in the range 0 through 255 1255 1256 <a> ::= any one of the 52 alphabetic characters A through Z 1257 in upper case and a through z in lower case 1258 1259 <c> ::= any one of the 128 ASCII characters, but not any 1260 <special> or <SP> 1261 1262 <d> ::= any one of the ten digits 0 through 9 1263 1264 <q> ::= any one of the 128 ASCII characters except <CR>, 1265 <LF>, quote ("), or backslash (\) 1266 1267 <x> ::= any one of the 128 ASCII characters (no exceptions) 1268 1269 <special> ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "." 1270 | "," | ";" | ":" | "@" """ | the control 1271 characters (ASCII codes 0 through 31 inclusive and 1272 127) 1273 1274 Note that the backslash, "\", is a quote character, which is 1275 used to indicate that the next character is to be used 1276 literally (instead of its normal interpretation). For example, 1277 "Joe\,Smith" could be used to indicate a single nine character 1278 user field with comma being the fourth character of the field. 1279 1280 Hosts are generally known by names which are translated to 1281 addresses in each host. Note that the name elements of domains 1282 are the official names -- no use of nicknames or aliases is 1283 allowed. 1284 1285 Sometimes a host is not known to the translation function and 1286 communication is blocked. To bypass this barrier two numeric 1287 forms are also allowed for host "names". One form is a decimal 1288 integer prefixed by a pound sign, "#", which indicates the 1289 number is the address of the host. Another form is four small 1290 decimal integers separated by dots and enclosed by brackets, 1291 e.g., "[123.255.37.2]", which indicates a 32-bit ARPA Internet 1292 Address in four 8-bit fields. 1293 1294 August 1982 _R_F_C_ _8_2_1 1295 Simple Mail Transfer Protocol 1296 1297 The time stamp line and the return path line are formally 1298 defined as follows: 1299 1300 <return-path-line> ::= "Return-Path:" <SP><reverse-path><CRLF> 1301 1302 <time-stamp-line> ::= "Received:" <SP> <stamp> <CRLF> 1303 1304 <stamp> ::= <from-domain> <by-domain> <opt-info> ";" 1305 <daytime> 1306 1307 <from-domain> ::= "FROM" <SP> <domain> <SP> 1308 1309 <by-domain> ::= "BY" <SP> <domain> <SP> 1310 1311 <opt-info> ::= [<via>] [<with>] [<id>] [<for>] 1312 1313 <via> ::= "VIA" <SP> <link> <SP> 1314 1315 <with> ::= "WITH" <SP> <protocol> <SP> 1316 1317 <id> ::= "ID" <SP> <string> <SP> 1318 1319 <for> ::= "FOR" <SP> <path> <SP> 1320 1321 <link> ::= The standard names for links are registered with 1322 the Network Information Center. 1323 1324 <protocol> ::= The standard names for protocols are 1325 registered with the Network Information Center. 1326 1327 <daytime> ::= <SP> <date> <SP> <time> 1328 1329 <date> ::= <dd> <SP> <mon> <SP> <yy> 1330 1331 <time> ::= <hh> ":" <mm> ":" <ss> <SP> <zone> 1332 1333 <dd> ::= the one or two decimal integer day of the month in 1334 the range 1 to 31. 1335 1336 <mon> ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" | 1337 "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC" 1338 1339 <yy> ::= the two decimal integer year of the century in the 1340 range 00 to 99. 1341 1342 _R_F_C_ _8_2_1 August 1982 1343 Simple Mail Transfer Protocol 1344 1345 <hh> ::= the two decimal integer hour of the day in the 1346 range 00 to 24. 1347 1348 <mm> ::= the two decimal integer minute of the hour in the 1349 range 00 to 59. 1350 1351 <ss> ::= the two decimal integer second of the minute in the 1352 range 00 to 59. 1353 1354 <zone> ::= "UT" for Universal Time (the default) or other 1355 time zone designator (as in [2]). 1356 1357 ------------------------------------------------------------- 1358 1359 Return Path Example 1360 1361 Return-Path: <@CHARLIE.ARPA,@BAKER.ARPA:_J_O_E_@_A_B_L_E_._A_R_P_A> 1362 1363 Example 9 1364 1365 ------------------------------------------------------------- 1366 1367 ------------------------------------------------------------- 1368 1369 Time Stamp Line Example 1370 1371 Received: FROM ABC.ARPA BY XYZ.ARPA ; 22 OCT 81 09:23:59 PDT 1372 1373 Received: from ABC.ARPA by XYZ.ARPA via TELENET with X25 1374 id M12345 for _S_m_i_t_h_@_P_D_Q_._A_R_P_A ; 22 OCT 81 09:23:59 PDT 1375 1376 Example 10 1377 1378 ------------------------------------------------------------- 1379 1380 August 1982 _R_F_C_ _8_2_1 1381 Simple Mail Transfer Protocol 1382 1383 4.2. SMTP REPLIES 1384 1385 Replies to SMTP commands are devised to ensure the synchronization 1386 of requests and actions in the process of mail transfer, and to 1387 guarantee that the sender-SMTP always knows the state of the 1388 receiver-SMTP. Every command must generate exactly one reply. 1389 1390 The details of the command-reply sequence are made explicit in 1391 Section 5.3 on Sequencing and Section 5.4 State Diagrams. 1392 1393 An SMTP reply consists of a three digit number (transmitted as 1394 three alphanumeric characters) followed by some text. The number 1395 is intended for use by automata to determine what state to enter 1396 next; the text is meant for the human user. It is intended that 1397 the three digits contain enough encoded information that the 1398 sender-SMTP need not examine the text and may either discard it or 1399 pass it on to the user, as appropriate. In particular, the text 1400 may be receiver-dependent and context dependent, so there are 1401 likely to be varying texts for each reply code. A discussion of 1402 the theory of reply codes is given in Appendix E. Formally, a 1403 reply is defined to be the sequence: a three-digit code, <SP>, 1404 one line of text, and <CRLF>, or a multiline reply (as defined in 1405 Appendix E). Only the EXPN and HELP commands are expected to 1406 result in multiline replies in normal circumstances, however 1407 multiline replies are allowed for any command. 1408 1409 _R_F_C_ _8_2_1 August 1982 1410 Simple Mail Transfer Protocol 1411 1412 4.2.1. REPLY CODES BY FUNCTION GROUPS 1413 1414 500 Syntax error, command unrecognized 1415 [This may include errors such as command line too long] 1416 501 Syntax error in parameters or arguments 1417 502 Command not implemented 1418 503 Bad sequence of commands 1419 504 Command parameter not implemented 1420 1421 211 System status, or system help reply 1422 214 Help message 1423 [Information on how to use the receiver or the meaning of a 1424 particular non-standard command; this reply is useful only 1425 to the human user] 1426 1427 220 <domain> Service ready 1428 221 <domain> Service closing transmission channel 1429 421 <domain> Service not available, 1430 closing transmission channel 1431 [This may be a reply to any command if the service knows it 1432 must shut down] 1433 1434 250 Requested mail action okay, completed 1435 251 User not local; will forward to <forward-path> 1436 450 Requested mail action not taken: mailbox unavailable 1437 [E.g., mailbox busy] 1438 550 Requested action not taken: mailbox unavailable 1439 [E.g., mailbox not found, no access] 1440 451 Requested action aborted: error in processing 1441 551 User not local; please try <forward-path> 1442 452 Requested action not taken: insufficient system storage 1443 552 Requested mail action aborted: exceeded storage allocation 1444 553 Requested action not taken: mailbox name not allowed 1445 [E.g., mailbox syntax incorrect] 1446 354 Start mail input; end with <CRLF>.<CRLF> 1447 554 Transaction failed 1448 1449 August 1982 _R_F_C_ _8_2_1 1450 Simple Mail Transfer Protocol 1451 1452 4.2.2. NUMERIC ORDER LIST OF REPLY CODES 1453 1454 211 System status, or system help reply 1455 214 Help message 1456 [Information on how to use the receiver or the meaning of a 1457 particular non-standard command; this reply is useful only 1458 to the human user] 1459 220 <domain> Service ready 1460 221 <domain> Service closing transmission channel 1461 250 Requested mail action okay, completed 1462 251 User not local; will forward to <forward-path> 1463 1464 354 Start mail input; end with <CRLF>.<CRLF> 1465 1466 421 <domain> Service not available, 1467 closing transmission channel 1468 [This may be a reply to any command if the service knows it 1469 must shut down] 1470 450 Requested mail action not taken: mailbox unavailable 1471 [E.g., mailbox busy] 1472 451 Requested action aborted: local error in processing 1473 452 Requested action not taken: insufficient system storage 1474 1475 500 Syntax error, command unrecognized 1476 [This may include errors such as command line too long] 1477 501 Syntax error in parameters or arguments 1478 502 Command not implemented 1479 503 Bad sequence of commands 1480 504 Command parameter not implemented 1481 550 Requested action not taken: mailbox unavailable 1482 [E.g., mailbox not found, no access] 1483 551 User not local; please try <forward-path> 1484 552 Requested mail action aborted: exceeded storage allocation 1485 553 Requested action not taken: mailbox name not allowed 1486 [E.g., mailbox syntax incorrect] 1487 554 Transaction failed 1488 1489 _R_F_C_ _8_2_1 August 1982 1490 Simple Mail Transfer Protocol 1491 1492 4.3. SEQUENCING OF COMMANDS AND REPLIES 1493 1494 The communication between the sender and receiver is intended to 1495 be an alternating dialogue, controlled by the sender. As such, 1496 the sender issues a command and the receiver responds with a 1497 reply. The sender must wait for this response before sending 1498 further commands. 1499 1500 One important reply is the connection greeting. Normally, a 1501 receiver will send a 220 "Service ready" reply when the connection 1502 is completed. The sender should wait for this greeting message 1503 before sending any commands. 1504 1505 Note: all the greeting type replies have the official name of 1506 the server host as the first word following the reply code. 1507 1508 For example, 1509 1510 220 <SP> USC-ISIF.ARPA <SP> Service ready <CRLF> 1511 1512 The table below lists alternative success and failure replies for 1513 each command. These must be strictly adhered to; a receiver may 1514 substitute text in the replies, but the meaning and action implied 1515 by the code numbers and by the specific command reply sequence 1516 cannot be altered. 1517 1518 COMMAND-REPLY SEQUENCES 1519 1520 Each command is listed with its possible replies. The prefixes 1521 used before the possible replies are "P" for preliminary (not 1522 used in SMTP), "I" for intermediate, "S" for success, "F" for 1523 failure, and "E" for error. The 421 reply (service not 1524 available, closing transmission channel) may be given to any 1525 command if the SMTP-receiver knows it must shut down. This 1526 listing forms the basis for the State Diagrams in Section 4.4. 1527 1528 CONNECTION ESTABLISHMENT 1529 S: 220 1530 F: 421 1531 HELO 1532 S: 250 1533 E: 500, 501, 504, 421 1534 MAIL 1535 S: 250 1536 F: 552, 451, 452 1537 E: 500, 501, 421 1538 1539 August 1982 _R_F_C_ _8_2_1 1540 Simple Mail Transfer Protocol 1541 1542 RCPT 1543 S: 250, 251 1544 F: 550, 551, 552, 553, 450, 451, 452 1545 E: 500, 501, 503, 421 1546 DATA 1547 I: 354 -> data -> S: 250 1548 F: 552, 554, 451, 452 1549 F: 451, 554 1550 E: 500, 501, 503, 421 1551 RSET 1552 S: 250 1553 E: 500, 501, 504, 421 1554 SEND 1555 S: 250 1556 F: 552, 451, 452 1557 E: 500, 501, 502, 421 1558 SOML 1559 S: 250 1560 F: 552, 451, 452 1561 E: 500, 501, 502, 421 1562 SAML 1563 S: 250 1564 F: 552, 451, 452 1565 E: 500, 501, 502, 421 1566 VRFY 1567 S: 250, 251 1568 F: 550, 551, 553 1569 E: 500, 501, 502, 504, 421 1570 EXPN 1571 S: 250 1572 F: 550 1573 E: 500, 501, 502, 504, 421 1574 HELP 1575 S: 211, 214 1576 E: 500, 501, 502, 504, 421 1577 NOOP 1578 S: 250 1579 E: 500, 421 1580 QUIT 1581 S: 221 1582 E: 500 1583 TURN 1584 S: 250 1585 F: 502 1586 E: 500, 503 1587 1588 _R_F_C_ _8_2_1 August 1982 1589 Simple Mail Transfer Protocol 1590 1591 4.4. STATE DIAGRAMS 1592 1593 Following are state diagrams for a simple-minded SMTP 1594 implementation. Only the first digit of the reply codes is used. 1595 There is one state diagram for each group of SMTP commands. The 1596 command groupings were determined by constructing a model for each 1597 command and then collecting together the commands with 1598 structurally identical models. 1599 1600 For each command there are three possible outcomes: "success" 1601 (S), "failure" (F), and "error" (E). In the state diagrams below 1602 we use the symbol B for "begin", and the symbol W for "wait for 1603 reply". 1604 1605 First, the diagram that represents most of the SMTP commands: 1606 1607 1,3 +---+ 1608 ----------->| E | 1609 | +---+ 1610 | 1611 +---+ cmd +---+ 2 +---+ 1612 | B |---------->| W |---------->| S | 1613 +---+ +---+ +---+ 1614 | 1615 | 4,5 +---+ 1616 ----------->| F | 1617 +---+ 1618 1619 This diagram models the commands: 1620 1621 HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP, 1622 NOOP, QUIT, TURN. 1623 1624 August 1982 _R_F_C_ _8_2_1 1625 Simple Mail Transfer Protocol 1626 1627 A more complex diagram models the DATA command: 1628 1629 +---+ DATA +---+ 1,2 +---+ 1630 | B |---------->| W |-------------------->| E | 1631 +---+ +---+ ------------>+---+ 1632 3| |4,5 | 1633 | | | 1634 -------------- ----- | 1635 | | | +---+ 1636 | ---------- -------->| S | 1637 | | | | +---+ 1638 | | ------------ 1639 | | | | 1640 V 1,3| |2 | 1641 +---+ data +---+ --------------->+---+ 1642 | |---------->| W | | F | 1643 +---+ +---+-------------------->+---+ 1644 4,5 1645 1646 Note that the "data" here is a series of lines sent from the 1647 sender to the receiver with no response expected until the last 1648 line is sent. 1649 1650 _R_F_C_ _8_2_1 August 1982 1651 Simple Mail Transfer Protocol 1652 1653 4.5. DETAILS 1654 1655 4.5.1. MINIMUM IMPLEMENTATION 1656 1657 In order to make SMTP workable, the following minimum 1658 implementation is required for all receivers: 1659 1660 COMMANDS -- HELO 1661 MAIL 1662 RCPT 1663 DATA 1664 RSET 1665 NOOP 1666 QUIT 1667 1668 4.5.2. TRANSPARENCY 1669 1670 Without some provision for data transparency the character 1671 sequence "<CRLF>.<CRLF>" ends the mail text and cannot be sent 1672 by the user. In general, users are not aware of such 1673 "forbidden" sequences. To allow all user composed text to be 1674 transmitted transparently the following procedures are used. 1675 1676 1. Before sending a line of mail text the sender-SMTP checks 1677 the first character of the line. If it is a period, one 1678 additional period is inserted at the beginning of the line. 1679 1680 2. When a line of mail text is received by the receiver-SMTP 1681 it checks the line. If the line is composed of a single 1682 period it is the end of mail. If the first character is a 1683 period and there are other characters on the line, the first 1684 character is deleted. 1685 1686 The mail data may contain any of the 128 ASCII characters. All 1687 characters are to be delivered to the recipient's mailbox 1688 including format effectors and other control characters. If 1689 the transmission channel provides an 8-bit byte (octets) data 1690 stream, the 7-bit ASCII codes are transmitted right justified 1691 in the octets with the high order bits cleared to zero. 1692 1693 In some systems it may be necessary to transform the data as 1694 it is received and stored. This may be necessary for hosts 1695 that use a different character set than ASCII as their local 1696 character set, or that store data in records rather than 1697 1698 August 1982 _R_F_C_ _8_2_1 1699 Simple Mail Transfer Protocol 1700 1701 strings. If such transforms are necessary, they must be 1702 reversible -- especially if such transforms are applied to 1703 mail being relayed. 1704 1705 4.5.3. SIZES 1706 1707 There are several objects that have required minimum maximum 1708 sizes. That is, every implementation must be able to receive 1709 objects of at least these sizes, but must not send objects 1710 larger than these sizes. 1711 1712 **************************************************** 1713 * * 1714 * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * 1715 * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * 1716 * OF THESE OBJECTS SHOULD BE USED. * 1717 * * 1718 **************************************************** 1719 1720 user 1721 1722 The maximum total length of a user name is 64 characters. 1723 1724 domain 1725 1726 The maximum total length of a domain name or number is 64 1727 characters. 1728 1729 path 1730 1731 The maximum total length of a reverse-path or 1732 forward-path is 256 characters (including the punctuation 1733 and element separators). 1734 1735 command line 1736 1737 The maximum total length of a command line including the 1738 command word and the <CRLF> is 512 characters. 1739 1740 reply line 1741 1742 The maximum total length of a reply line including the 1743 reply code and the <CRLF> is 512 characters. 1744 1745 _R_F_C_ _8_2_1 August 1982 1746 Simple Mail Transfer Protocol 1747 1748 text line 1749 1750 The maximum total length of a text line including the 1751 <CRLF> is 1000 characters (but not counting the leading 1752 dot duplicated for transparency). 1753 1754 recipients buffer 1755 1756 The maximum total number of recipients that must be 1757 buffered is 100 recipients. 1758 1759 **************************************************** 1760 * * 1761 * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * 1762 * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * 1763 * OF THESE OBJECTS SHOULD BE USED. * 1764 * * 1765 **************************************************** 1766 1767 Errors due to exceeding these limits may be reported by using 1768 the reply codes, for example: 1769 1770 500 Line too long. 1771 1772 501 Path too long 1773 1774 552 Too many recipients. 1775 1776 552 Too much mail data. 1777 1778 August 1982 _R_F_C_ _8_2_1 1779 Simple Mail Transfer Protocol 1780 1781 APPENDIX A 1782 1783 TCP Transport service 1784 1785 The Transmission Control Protocol [3] is used in the ARPA 1786 Internet, and in any network following the US DoD standards for 1787 internetwork protocols. 1788 1789 Connection Establishment 1790 1791 The SMTP transmission channel is a TCP connection established 1792 between the sender process port U and the receiver process port 1793 L. This single full duplex connection is used as the 1794 transmission channel. This protocol is assigned the service 1795 port 25 (31 octal), that is L=25. 1796 1797 Data Transfer 1798 1799 The TCP connection supports the transmission of 8-bit bytes. 1800 The SMTP data is 7-bit ASCII characters. Each character is 1801 transmitted as an 8-bit byte with the high-order bit cleared to 1802 zero. 1803 1804 _R_F_C_ _8_2_1 August 1982 1805 Simple Mail Transfer Protocol 1806 1807 APPENDIX B 1808 1809 NCP Transport service 1810 1811 The ARPANET Host-to-Host Protocol [4] (implemented by the Network 1812 Control Program) may be used in the ARPANET. 1813 1814 Connection Establishment 1815 1816 The SMTP transmission channel is established via NCP between 1817 the sender process socket U and receiver process socket L. The 1818 Initial Connection Protocol [5] is followed resulting in a pair 1819 of simplex connections. This pair of connections is used as 1820 the transmission channel. This protocol is assigned the 1821 contact socket 25 (31 octal), that is L=25. 1822 1823 Data Transfer 1824 1825 The NCP data connections are established in 8-bit byte mode. 1826 The SMTP data is 7-bit ASCII characters. Each character is 1827 transmitted as an 8-bit byte with the high-order bit cleared to 1828 zero. 1829 1830 August 1982 _R_F_C_ _8_2_1 1831 Simple Mail Transfer Protocol 1832 1833 APPENDIX C 1834 1835 NITS 1836 1837 The Network Independent Transport Service [6] may be used. 1838 1839 Connection Establishment 1840 1841 The SMTP transmission channel is established via NITS between 1842 the sender process and receiver process. The sender process 1843 executes the CONNECT primitive, and the waiting receiver 1844 process executes the ACCEPT primitive. 1845 1846 Data Transfer 1847 1848 The NITS connection supports the transmission of 8-bit bytes. 1849 The SMTP data is 7-bit ASCII characters. Each character is 1850 transmitted as an 8-bit byte with the high-order bit cleared to 1851 zero. 1852 1853 _R_F_C_ _8_2_1 August 1982 1854 Simple Mail Transfer Protocol 1855 1856 APPENDIX D 1857 1858 X.25 Transport service 1859 1860 It may be possible to use the X.25 service [7] as provided by the 1861 Public Data Networks directly, however, it is suggested that a 1862 reliable end-to-end protocol such as TCP be used on top of X.25 1863 connections. 1864 1865 August 1982 _R_F_C_ _8_2_1 1866 Simple Mail Transfer Protocol 1867 1868 APPENDIX E 1869 1870 Theory of Reply Codes 1871 1872 The three digits of the reply each have a special significance. 1873 The first digit denotes whether the response is good, bad or 1874 incomplete. An unsophisticated sender-SMTP will be able to 1875 determine its next action (proceed as planned, redo, retrench, 1876 etc.) by simply examining this first digit. A sender-SMTP that 1877 wants to know approximately what kind of error occurred (e.g., 1878 mail system error, command syntax error) may examine the second 1879 digit, reserving the third digit for the finest gradation of 1880 information. 1881 1882 There are five values for the first digit of the reply code: 1883 1884 1yz Positive Preliminary reply 1885 1886 The command has been accepted, but the requested action 1887 is being held in abeyance, pending confirmation of the 1888 information in this reply. The sender-SMTP should send 1889 another command specifying whether to continue or abort 1890 the action. 1891 1892 [Note: SMTP does not have any commands that allow this 1893 type of reply, and so does not have the continue or 1894 abort commands.] 1895 1896 2yz Positive Completion reply 1897 1898 The requested action has been successfully completed. A 1899 new request may be initiated. 1900 1901 3yz Positive Intermediate reply 1902 1903 The command has been accepted, but the requested action 1904 is being held in abeyance, pending receipt of further 1905 information. The sender-SMTP should send another command 1906 specifying this information. This reply is used in 1907 command sequence groups. 1908 1909 4yz Transient Negative Completion reply 1910 1911 The command was not accepted and the requested action did 1912 not occur. However, the error condition is temporary and 1913 the action may be requested again. The sender should 1914 1915 _R_F_C_ _8_2_1 August 1982 1916 Simple Mail Transfer Protocol 1917 1918 return to the beginning of the command sequence (if any). 1919 It is difficult to assign a meaning to "transient" when 1920 two different sites (receiver- and sender- SMTPs) must 1921 agree on the interpretation. Each reply in this category 1922 might have a different time value, but the sender-SMTP is 1923 encouraged to try again. A rule of thumb to determine if 1924 a reply fits into the 4yz or the 5yz category (see below) 1925 is that replies are 4yz if they can be repeated without 1926 any change in command form or in properties of the sender 1927 or receiver. (E.g., the command is repeated identically 1928 and the receiver does not put up a new implementation.) 1929 1930 5yz Permanent Negative Completion reply 1931 1932 The command was not accepted and the requested action did 1933 not occur. The sender-SMTP is discouraged from repeating 1934 the exact request (in the same sequence). Even some 1935 "permanent" error conditions can be corrected, so the 1936 human user may want to direct the sender-SMTP to 1937 reinitiate the command sequence by direct action at some 1938 point in the future (e.g., after the spelling has been 1939 changed, or the user has altered the account status). 1940 1941 The second digit encodes responses in specific categories: 1942 1943 x0z Syntax -- These replies refer to syntax errors, 1944 syntactically correct commands that don't fit any 1945 functional category, and unimplemented or superfluous 1946 commands. 1947 1948 x1z Information -- These are replies to requests for 1949 information, such as status or help. 1950 1951 x2z Connections -- These are replies referring to the 1952 transmission channel. 1953 1954 x3z Unspecified as yet. 1955 1956 x4z Unspecified as yet. 1957 1958 x5z Mail system -- These replies indicate the status of 1959 the receiver mail system vis-a-vis the requested 1960 transfer or other mail system action. 1961 1962 The third digit gives a finer gradation of meaning in each 1963 category specified by the second digit. The list of replies 1964 1965 August 1982 _R_F_C_ _8_2_1 1966 Simple Mail Transfer Protocol 1967 1968 illustrates this. Each reply text is recommended rather than 1969 mandatory, and may even change according to the command with 1970 which it is associated. On the other hand, the reply codes 1971 must strictly follow the specifications in this section. 1972 Receiver implementations should not invent new codes for 1973 slightly different situations from the ones described here, but 1974 rather adapt codes already defined. 1975 1976 For example, a command such as NOOP whose successful execution 1977 does not offer the sender-SMTP any new information will return 1978 a 250 reply. The response is 502 when the command requests an 1979 unimplemented non-site-specific action. A refinement of that 1980 is the 504 reply for a command that is implemented, but that 1981 requests an unimplemented parameter. 1982 1983 The reply text may be longer than a single line; in these cases 1984 the complete text must be marked so the sender-SMTP knows when it 1985 can stop reading the reply. This requires a special format to 1986 indicate a multiple line reply. 1987 1988 The format for multiline replies requires that every line, 1989 except the last, begin with the reply code, followed 1990 immediately by a hyphen, "-" (also known as minus), followed by 1991 text. The last line will begin with the reply code, followed 1992 immediately by <SP>, optionally some text, and <CRLF>. 1993 1994 For example: 1995 123-First line 1996 123-Second line 1997 123-234 text beginning with numbers 1998 123 The last line 1999 2000 In many cases the sender-SMTP then simply needs to search for 2001 the reply code followed by <SP> at the beginning of a line, and 2002 ignore all preceding lines. In a few cases, there is important 2003 data for the sender in the reply "text". The sender will know 2004 these cases from the current context. 2005 2006 _R_F_C_ _8_2_1 August 1982 2007 Simple Mail Transfer Protocol 2008 2009 APPENDIX F 2010 2011 Scenarios 2012 2013 This section presents complete scenarios of several types of SMTP 2014 sessions. 2015 2016 A Typical SMTP Transaction Scenario 2017 2018 This SMTP example shows mail sent by Smith at host USC-ISIF, to 2019 Jones, Green, and Brown at host BBN-UNIX. Here we assume that 2020 host USC-ISIF contacts host BBN-UNIX directly. The mail is 2021 accepted for Jones and Brown. Green does not have a mailbox at 2022 host BBN-UNIX. 2023 2024 ------------------------------------------------------------- 2025 2026 R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready 2027 S: HELO USC-ISIF.ARPA 2028 R: 250 BBN-UNIX.ARPA 2029 2030 S: MAIL FROM:<_S_m_i_t_h_@_U_S_C_-_I_S_I_F_._A_R_P_A> 2031 R: 250 OK 2032 2033 S: RCPT TO:<_J_o_n_e_s_@_B_B_N_-_U_N_I_X_._A_R_P_A> 2034 R: 250 OK 2035 2036 S: RCPT TO:<_G_r_e_e_n_@_B_B_N_-_U_N_I_X_._A_R_P_A> 2037 R: 550 No such user here 2038 2039 S: RCPT TO:<_B_r_o_w_n_@_B_B_N_-_U_N_I_X_._A_R_P_A> 2040 R: 250 OK 2041 2042 S: DATA 2043 R: 354 Start mail input; end with <CRLF>.<CRLF> 2044 S: Blah blah blah... 2045 S: ...etc. etc. etc. 2046 S: . 2047 R: 250 OK 2048 2049 S: QUIT 2050 R: 221 BBN-UNIX.ARPA Service closing transmission channel 2051 2052 Scenario 1 2053 2054 ------------------------------------------------------------- 2055 2056 August 1982 _R_F_C_ _8_2_1 2057 Simple Mail Transfer Protocol 2058 2059 Aborted SMTP Transaction Scenario 2060 2061 ------------------------------------------------------------- 2062 2063 R: 220 MIT-Multics.ARPA Simple Mail Transfer Service Ready 2064 S: HELO ISI-VAXA.ARPA 2065 R: 250 MIT-Multics.ARPA 2066 2067 S: MAIL FROM:<_S_m_i_t_h_@_I_S_I_-_V_A_X_A_._A_R_P_A> 2068 R: 250 OK 2069 2070 S: RCPT TO:<_J_o_n_e_s_@_M_I_T_-_M_u_l_t_i_c_s_._A_R_P_A> 2071 R: 250 OK 2072 2073 S: RCPT TO:<_G_r_e_e_n_@_M_I_T_-_M_u_l_t_i_c_s_._A_R_P_A> 2074 R: 550 No such user here 2075 2076 S: RSET 2077 R: 250 OK 2078 2079 S: QUIT 2080 R: 221 MIT-Multics.ARPA Service closing transmission channel 2081 2082 Scenario 2 2083 2084 ------------------------------------------------------------- 2085 2086 _R_F_C_ _8_2_1 August 1982 2087 Simple Mail Transfer Protocol 2088 2089 Relayed Mail Scenario 2090 2091 ------------------------------------------------------------- 2092 2093 Step 1 -- Source Host to Relay Host 2094 2095 R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready 2096 S: HELO MIT-AI.ARPA 2097 R: 250 USC-ISIE.ARPA 2098 2099 S: MAIL FROM:<_J_Q_P_@_M_I_T_-_A_I_._A_R_P_A> 2100 R: 250 OK 2101 2102 S: RCPT TO:<@USC-ISIE.ARPA:_J_o_n_e_s_@_B_B_N_-_V_A_X_._A_R_P_A> 2103 R: 250 OK 2104 2105 S: DATA 2106 R: 354 Start mail input; end with <CRLF>.<CRLF> 2107 S: Date: 2 Nov 81 22:33:44 2108 S: From: John Q. Public <_J_Q_P_@_M_I_T_-_A_I_._A_R_P_A> 2109 S: Subject: The Next Meeting of the Board 2110 S: To: _J_o_n_e_s_@_B_B_N_-_V_a_x_._A_R_P_A 2111 S: 2112 S: Bill: 2113 S: The next meeting of the board of directors will be 2114 S: on Tuesday. 2115 S: John. 2116 S: . 2117 R: 250 OK 2118 2119 S: QUIT 2120 R: 221 USC-ISIE.ARPA Service closing transmission channel 2121 2122 August 1982 _R_F_C_ _8_2_1 2123 Simple Mail Transfer Protocol 2124 2125 Step 2 -- Relay Host to Destination Host 2126 2127 R: 220 BBN-VAX.ARPA Simple Mail Transfer Service Ready 2128 S: HELO USC-ISIE.ARPA 2129 R: 250 BBN-VAX.ARPA 2130 2131 S: MAIL FROM:<@USC-ISIE.ARPA:_J_Q_P_@_M_I_T_-_A_I_._A_R_P_A> 2132 R: 250 OK 2133 2134 S: RCPT TO:<_J_o_n_e_s_@_B_B_N_-_V_A_X_._A_R_P_A> 2135 R: 250 OK 2136 2137 S: DATA 2138 R: 354 Start mail input; end with <CRLF>.<CRLF> 2139 S: Received: from MIT-AI.ARPA by USC-ISIE.ARPA ; 2140 2 Nov 81 22:40:10 UT 2141 S: Date: 2 Nov 81 22:33:44 2142 S: From: John Q. Public <_J_Q_P_@_M_I_T_-_A_I_._A_R_P_A> 2143 S: Subject: The Next Meeting of the Board 2144 S: To: _J_o_n_e_s_@_B_B_N_-_V_a_x_._A_R_P_A 2145 S: 2146 S: Bill: 2147 S: The next meeting of the board of directors will be 2148 S: on Tuesday. 2149 S: John. 2150 S: . 2151 R: 250 OK 2152 2153 S: QUIT 2154 R: 221 USC-ISIE.ARPA Service closing transmission channel 2155 2156 Scenario 3 2157 2158 ------------------------------------------------------------- 2159 2160 _R_F_C_ _8_2_1 August 1982 2161 Simple Mail Transfer Protocol 2162 2163 Verifying and Sending Scenario 2164 2165 ------------------------------------------------------------- 2166 2167 R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready 2168 S: HELO MIT-MC.ARPA 2169 R: 250 SU-SCORE.ARPA 2170 2171 S: VRFY Crispin 2172 R: 250 Mark Crispin <_A_d_m_i_n_._M_R_C_@_S_U_-_S_C_O_R_E_._A_R_P_A> 2173 2174 S: SEND FROM:<_E_A_K_@_M_I_T_-_M_C_._A_R_P_A> 2175 R: 250 OK 2176 2177 S: RCPT TO:<_A_d_m_i_n_._M_R_C_@_S_U_-_S_C_O_R_E_._A_R_P_A> 2178 R: 250 OK 2179 2180 S: DATA 2181 R: 354 Start mail input; end with <CRLF>.<CRLF> 2182 S: Blah blah blah... 2183 S: ...etc. etc. etc. 2184 S: . 2185 R: 250 OK 2186 2187 S: QUIT 2188 R: 221 SU-SCORE.ARPA Service closing transmission channel 2189 2190 Scenario 4 2191 2192 ------------------------------------------------------------- 2193 2194 August 1982 _R_F_C_ _8_2_1 2195 Simple Mail Transfer Protocol 2196 2197 Sending and Mailing Scenarios 2198 2199 First the user's name is verified, then an attempt is made to 2200 send to the user's terminal. When that fails, the messages is 2201 mailed to the user's mailbox. 2202 2203 ------------------------------------------------------------- 2204 2205 R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready 2206 S: HELO MIT-MC.ARPA 2207 R: 250 SU-SCORE.ARPA 2208 2209 S: VRFY Crispin 2210 R: 250 Mark Crispin <_A_d_m_i_n_._M_R_C_@_S_U_-_S_C_O_R_E_._A_R_P_A> 2211 2212 S: SEND FROM:<_E_A_K_@_M_I_T_-_M_C_._A_R_P_A> 2213 R: 250 OK 2214 2215 S: RCPT TO:<_A_d_m_i_n_._M_R_C_@_S_U_-_S_C_O_R_E_._A_R_P_A> 2216 R: 450 User not active now 2217 2218 S: RSET 2219 R: 250 OK 2220 2221 S: MAIL FROM:<_E_A_K_@_M_I_T_-_M_C_._A_R_P_A> 2222 R: 250 OK 2223 2224 S: RCPT TO:<_A_d_m_i_n_._M_R_C_@_S_U_-_S_C_O_R_E_._A_R_P_A> 2225 R: 250 OK 2226 2227 S: DATA 2228 R: 354 Start mail input; end with <CRLF>.<CRLF> 2229 S: Blah blah blah... 2230 S: ...etc. etc. etc. 2231 S: . 2232 R: 250 OK 2233 2234 S: QUIT 2235 R: 221 SU-SCORE.ARPA Service closing transmission channel 2236 2237 Scenario 5 2238 2239 ------------------------------------------------------------- 2240 2241 _R_F_C_ _8_2_1 August 1982 2242 Simple Mail Transfer Protocol 2243 2244 Doing the preceding scenario more efficiently. 2245 2246 ------------------------------------------------------------- 2247 2248 R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready 2249 S: HELO MIT-MC.ARPA 2250 R: 250 SU-SCORE.ARPA 2251 2252 S: VRFY Crispin 2253 R: 250 Mark Crispin <_A_d_m_i_n_._M_R_C_@_S_U_-_S_C_O_R_E_._A_R_P_A> 2254 2255 S: SOML FROM:<_E_A_K_@_M_I_T_-_M_C_._A_R_P_A> 2256 R: 250 OK 2257 2258 S: RCPT TO:<_A_d_m_i_n_._M_R_C_@_S_U_-_S_C_O_R_E_._A_R_P_A> 2259 R: 250 User not active now, so will do mail. 2260 2261 S: DATA 2262 R: 354 Start mail input; end with <CRLF>.<CRLF> 2263 S: Blah blah blah... 2264 S: ...etc. etc. etc. 2265 S: . 2266 R: 250 OK 2267 2268 S: QUIT 2269 R: 221 SU-SCORE.ARPA Service closing transmission channel 2270 2271 Scenario 6 2272 2273 ------------------------------------------------------------- 2274 2275 August 1982 _R_F_C_ _8_2_1 2276 Simple Mail Transfer Protocol 2277 2278 Mailing List Scenario 2279 2280 First each of two mailing lists are expanded in separate sessions 2281 with different hosts. Then the message is sent to everyone that 2282 appeared on either list (but no duplicates) via a relay host. 2283 2284 ------------------------------------------------------------- 2285 2286 Step 1 -- Expanding the First List 2287 2288 R: 220 MIT-AI.ARPA Simple Mail Transfer Service Ready 2289 S: HELO SU-SCORE.ARPA 2290 R: 250 MIT-AI.ARPA 2291 2292 S: EXPN Example-People 2293 R: 250-<_A_B_C_@_M_I_T_-_M_C_._A_R_P_A> 2294 R: 250-Fred Fonebone <_F_o_n_e_b_o_n_e_@_U_S_C_-_I_S_I_Q_._A_R_P_A> 2295 R: 250-Xenon Y. Zither <_X_Y_Z_@_M_I_T_-_A_I_._A_R_P_A> 2296 R: 250-Quincy Smith <@USC-ISIF.ARPA:_Q_-_S_m_i_t_h_@_I_S_I_-_V_A_X_A_._A_R_P_A> 2297 R: 250-<_j_o_e_@_f_o_o_-_u_n_i_x_._A_R_P_A> 2298 R: 250 <_x_y_z_@_b_a_r_-_u_n_i_x_._A_R_P_A> 2299 2300 S: QUIT 2301 R: 221 MIT-AI.ARPA Service closing transmission channel 2302 2303 _R_F_C_ _8_2_1 August 1982 2304 Simple Mail Transfer Protocol 2305 2306 Step 2 -- Expanding the Second List 2307 2308 R: 220 MIT-MC.ARPA Simple Mail Transfer Service Ready 2309 S: HELO SU-SCORE.ARPA 2310 R: 250 MIT-MC.ARPA 2311 2312 S: EXPN Interested-Parties 2313 R: 250-Al Calico <_A_B_C_@_M_I_T_-_M_C_._A_R_P_A> 2314 R: 250-<_X_Y_Z_@_M_I_T_-_A_I_._A_R_P_A> 2315 R: 250-Quincy Smith <@USC-ISIF.ARPA:_Q_-_S_m_i_t_h_@_I_S_I_-_V_A_X_A_._A_R_P_A> 2316 R: 250-<_f_r_e_d_@_B_B_N_-_U_N_I_X_._A_R_P_A> 2317 R: 250 <_x_y_z_@_b_a_r_-_u_n_i_x_._A_R_P_A> 2318 2319 S: QUIT 2320 R: 221 MIT-MC.ARPA Service closing transmission channel 2321 2322 August 1982 _R_F_C_ _8_2_1 2323 Simple Mail Transfer Protocol 2324 2325 Step 3 -- Mailing to All via a Relay Host 2326 2327 R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready 2328 S: HELO SU-SCORE.ARPA 2329 R: 250 USC-ISIE.ARPA 2330 2331 S: MAIL FROM:<_A_c_c_o_u_n_t_._P_e_r_s_o_n_@_S_U_-_S_C_O_R_E_._A_R_P_A> 2332 R: 250 OK 2333 S: RCPT TO:<@USC-ISIE.ARPA:_A_B_C_@_M_I_T_-_M_C_._A_R_P_A> 2334 R: 250 OK 2335 S: RCPT TO:<@USC-ISIE.ARPA:_F_o_n_e_b_o_n_e_@_U_S_C_-_I_S_I_Q_A_._A_R_P_A> 2336 R: 250 OK 2337 S: RCPT TO:<@USC-ISIE.ARPA:_X_Y_Z_@_M_I_T_-_A_I_._A_R_P_A> 2338 R: 250 OK 2339 S: RCPT 2340 TO:<@USC-ISIE.ARPA,@USC-ISIF.ARPA:_Q_-_S_m_i_t_h_@_I_S_I_-_V_A_X_A_._A_R_P_A> 2341 R: 250 OK 2342 S: RCPT TO:<@USC-ISIE.ARPA:_j_o_e_@_F_O_O_-_U_N_I_X_._A_R_P_A> 2343 R: 250 OK 2344 S: RCPT TO:<@USC-ISIE.ARPA:_x_y_z_@_B_A_R_-_U_N_I_X_._A_R_P_A> 2345 R: 250 OK 2346 S: RCPT TO:<@USC-ISIE.ARPA:_f_r_e_d_@_B_B_N_-_U_N_I_X_._A_R_P_A> 2347 R: 250 OK 2348 2349 S: DATA 2350 R: 354 Start mail input; end with <CRLF>.<CRLF> 2351 S: Blah blah blah... 2352 S: ...etc. etc. etc. 2353 S: . 2354 R: 250 OK 2355 2356 S: QUIT 2357 R: 221 USC-ISIE.ARPA Service closing transmission channel 2358 2359 Scenario 7 2360 2361 ------------------------------------------------------------- 2362 2363 _R_F_C_ _8_2_1 August 1982 2364 Simple Mail Transfer Protocol 2365 2366 Forwarding Scenarios 2367 2368 ------------------------------------------------------------- 2369 2370 R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready 2371 S: HELO LBL-UNIX.ARPA 2372 R: 250 USC-ISIF.ARPA 2373 2374 S: MAIL FROM:<_m_o_@_L_B_L_-_U_N_I_X_._A_R_P_A> 2375 R: 250 OK 2376 2377 S: RCPT TO:<_f_r_e_d_@_U_S_C_-_I_S_I_F_._A_R_P_A> 2378 R: 251 User not local; will forward to <_J_o_n_e_s_@_U_S_C_-_I_S_I_._A_R_P_A> 2379 2380 S: DATA 2381 R: 354 Start mail input; end with <CRLF>.<CRLF> 2382 S: Blah blah blah... 2383 S: ...etc. etc. etc. 2384 S: . 2385 R: 250 OK 2386 2387 S: QUIT 2388 R: 221 USC-ISIF.ARPA Service closing transmission channel 2389 2390 Scenario 8 2391 2392 ------------------------------------------------------------- 2393 2394 August 1982 _R_F_C_ _8_2_1 2395 Simple Mail Transfer Protocol 2396 2397 ------------------------------------------------------------- 2398 2399 Step 1 -- Trying the Mailbox at the First Host 2400 2401 R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready 2402 S: HELO LBL-UNIX.ARPA 2403 R: 250 USC-ISIF.ARPA 2404 2405 S: MAIL FROM:<_m_o_@_L_B_L_-_U_N_I_X_._A_R_P_A> 2406 R: 250 OK 2407 2408 S: RCPT TO:<_f_r_e_d_@_U_S_C_-_I_S_I_F_._A_R_P_A> 2409 R: 251 User not local; will forward to <_J_o_n_e_s_@_U_S_C_-_I_S_I_._A_R_P_A> 2410 2411 S: RSET 2412 R: 250 OK 2413 2414 S: QUIT 2415 R: 221 USC-ISIF.ARPA Service closing transmission channel 2416 2417 Step 2 -- Delivering the Mail at the Second Host 2418 2419 R: 220 USC-ISI.ARPA Simple Mail Transfer Service Ready 2420 S: HELO LBL-UNIX.ARPA 2421 R: 250 USC-ISI.ARPA 2422 2423 S: MAIL FROM:<_m_o_@_L_B_L_-_U_N_I_X_._A_R_P_A> 2424 R: 250 OK 2425 2426 S: RCPT TO:<_J_o_n_e_s_@_U_S_C_-_I_S_I_._A_R_P_A> 2427 R: OK 2428 2429 S: DATA 2430 R: 354 Start mail input; end with <CRLF>.<CRLF> 2431 S: Blah blah blah... 2432 S: ...etc. etc. etc. 2433 S: . 2434 R: 250 OK 2435 2436 S: QUIT 2437 R: 221 USC-ISI.ARPA Service closing transmission channel 2438 2439 Scenario 9 2440 2441 ------------------------------------------------------------- 2442 2443 _R_F_C_ _8_2_1 August 1982 2444 Simple Mail Transfer Protocol 2445 2446 Too Many Recipients Scenario 2447 2448 ------------------------------------------------------------- 2449 2450 R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready 2451 S: HELO USC-ISIF.ARPA 2452 R: 250 BERKELEY.ARPA 2453 2454 S: MAIL FROM:<_P_o_s_t_e_l_@_U_S_C_-_I_S_I_F_._A_R_P_A> 2455 R: 250 OK 2456 2457 S: RCPT TO:<_f_a_b_r_y_@_B_E_R_K_E_L_E_Y_._A_R_P_A> 2458 R: 250 OK 2459 2460 S: RCPT TO:<_e_r_i_c_@_B_E_R_K_E_L_E_Y_._A_R_P_A> 2461 R: 552 Recipient storage full, try again in another transaction 2462 2463 S: DATA 2464 R: 354 Start mail input; end with <CRLF>.<CRLF> 2465 S: Blah blah blah... 2466 S: ...etc. etc. etc. 2467 S: . 2468 R: 250 OK 2469 2470 S: MAIL FROM:<_P_o_s_t_e_l_@_U_S_C_-_I_S_I_F_._A_R_P_A> 2471 R: 250 OK 2472 2473 S: RCPT TO:<_e_r_i_c_@_B_E_R_K_E_L_E_Y_._A_R_P_A> 2474 R: 250 OK 2475 2476 S: DATA 2477 R: 354 Start mail input; end with <CRLF>.<CRLF> 2478 S: Blah blah blah... 2479 S: ...etc. etc. etc. 2480 S: . 2481 R: 250 OK 2482 2483 S: QUIT 2484 R: 221 BERKELEY.ARPA Service closing transmission channel 2485 2486 Scenario 10 2487 2488 ------------------------------------------------------------- 2489 2490 Note that a real implementation must handle many recipients as 2491 specified in Section 4.5.3. 2492 2493 August 1982 _R_F_C_ _8_2_1 2494 Simple Mail Transfer Protocol 2495 2496 GLOSSARY 2497 2498 ASCII 2499 2500 American Standard Code for Information Interchange [1]. 2501 2502 command 2503 2504 A request for a mail service action sent by the sender-SMTP to the 2505 receiver-SMTP. 2506 2507 domain 2508 2509 The hierarchially structured global character string address of a 2510 host computer in the mail system. 2511 2512 end of mail data indication 2513 2514 A special sequence of characters that indicates the end of the 2515 mail data. In particular, the five characters carriage return, 2516 line feed, period, carriage return, line feed, in that order. 2517 2518 host 2519 2520 A computer in the internetwork environment on which mailboxes or 2521 SMTP processes reside. 2522 2523 line 2524 2525 A a sequence of ASCII characters ending with a <CRLF>. 2526 2527 mail data 2528 2529 A sequence of ASCII characters of arbitrary length, which conforms 2530 to the standard set in the Standard for the Format of ARPA 2531 Internet Text Messages (_R_F_C_ _8_2_2 [2]). 2532 2533 mailbox 2534 2535 A character string (address) which identifies a user to whom mail 2536 is to be sent. Mailbox normally consists of the host and user 2537 specifications. The standard mailbox naming convention is defined 2538 to be "user@domain". Additionally, the "container" in which mail 2539 is stored. 2540 2541 _R_F_C_ _8_2_1 August 1982 2542 Simple Mail Transfer Protocol 2543 2544 receiver-SMTP process 2545 2546 A process which transfers mail in cooperation with a sender-SMTP 2547 process. It waits for a connection to be established via the 2548 transport service. It receives SMTP commands from the 2549 sender-SMTP, sends replies, and performs the specified operations. 2550 2551 reply 2552 2553 A reply is an acknowledgment (positive or negative) sent from 2554 receiver to sender via the transmission channel in response to a 2555 command. The general form of a reply is a completion code 2556 (including error codes) followed by a text string. The codes are 2557 for use by programs and the text is usually intended for human 2558 users. 2559 2560 sender-SMTP process 2561 2562 A process which transfers mail in cooperation with a receiver-SMTP 2563 process. A local language may be used in the user interface 2564 command/reply dialogue. The sender-SMTP initiates the transport 2565 service connection. It initiates SMTP commands, receives replies, 2566 and governs the transfer of mail. 2567 2568 session 2569 2570 The set of exchanges that occur while the transmission channel is 2571 open. 2572 2573 transaction 2574 2575 The set of exchanges required for one message to be transmitted 2576 for one or more recipients. 2577 2578 transmission channel 2579 2580 A full-duplex communication path between a sender-SMTP and a 2581 receiver-SMTP for the exchange of commands, replies, and mail 2582 text. 2583 2584 transport service 2585 2586 Any reliable stream-oriented data communication services. For 2587 example, NCP, TCP, NITS. 2588 2589 August 1982 _R_F_C_ _8_2_1 2590 Simple Mail Transfer Protocol 2591 2592 user 2593 2594 A human being (or a process on behalf of a human being) wishing to 2595 obtain mail transfer service. In addition, a recipient of 2596 computer mail. 2597 2598 word 2599 2600 A sequence of printing characters. 2601 2602 <CRLF> 2603 2604 The characters carriage return and line feed (in that order). 2605 2606 <SP> 2607 2608 The space character. 2609 2610 _R_F_C_ _8_2_1 August 1982 2611 Simple Mail Transfer Protocol 2612 2613 REFERENCES 2614 2615 [1] ASCII 2616 2617 ASCII, "USA Code for Information Interchange", United States of 2618 America Standards Institute, X3.4, 1968. Also in: Feinler, E. 2619 and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for 2620 the Defense Communications Agency by SRI International, Menlo 2621 Park, California, Revised January 1978. 2622 2623 [2] _R_F_C_ _8_2_2 2624 2625 Crocker, D., "Standard for the Format of ARPA Internet Text 2626 Messages," _R_F_C_ _8_2_2, Department of Electrical Engineering, 2627 University of Delaware, August 1982. 2628 2629 [3] TCP 2630 2631 Postel, J., ed., "Transmission Control Protocol - DARPA Internet 2632 Program Protocol Specification", _R_F_C_ _7_9_3, USC/Information Sciences 2633 Institute, NTIS AD Number A111091, September 1981. Also in: 2634 Feinler, E. and J. Postel, eds., "Internet Protocol Transition 2635 Workbook", SRI International, Menlo Park, California, March 1982. 2636 2637 [4] NCP 2638 2639 McKenzie,A., "Host/Host Protocol for the ARPA Network", NIC 8246, 2640 January 1972. Also in: Feinler, E. and J. Postel, eds., "ARPANET 2641 Protocol Handbook", NIC 7104, for the Defense Communications 2642 Agency by SRI International, Menlo Park, California, Revised 2643 January 1978. 2644 2645 [5] Initial Connection Protocol 2646 2647 Postel, J., "Official Initial Connection Protocol", NIC 7101, 2648 11 June 1971. Also in: Feinler, E. and J. Postel, eds., "ARPANET 2649 Protocol Handbook", NIC 7104, for the Defense Communications 2650 Agency by SRI International, Menlo Park, California, Revised 2651 January 1978. 2652 2653 [6] NITS 2654 2655 PSS/SG3, "A Network Independent Transport Service", Study Group 3, 2656 The Post Office PSS Users Group, February 1980. Available from 2657 the DCPU, National Physical Laboratory, Teddington, UK. 2658 2659 August 1982 _R_F_C_ _8_2_1 2660 Simple Mail Transfer Protocol 2661 2662 [7] X.25 2663 2664 CCITT, "Recommendation X.25 - Interface Between Data Terminal 2665 Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for 2666 Terminals Operating in the Packet Mode on Public Data Networks," 2667 CCITT Orange Book, Vol. VIII.2, International Telephone and 2668 Telegraph Consultative Committee, Geneva, 1976. 2669 2670 Comments about this RFC: 2671 * _R_F_C_ _8_2_1_:_ _w_h_e_r_e_ _i_ _c_a_n_ _w_r_i_t_e_ _m_y_ _s_c_r_i_p_t_s by mahmood (1/31/2004) 2672 * _R_F_C_ _8_2_1_:_ _A_ _r_o_n_a_l_d_ _r_ _d_a_v_i_s_ _o_n_ _p_a_r_o_l_e_ _h_a_s_ _h_a_c_k_e_d_ _i_n_t_o_ _m_y_ _a_c_c_o_u_n_t_._ _h_e_ _i_s_ _n_o_t 2673 _s_u_p_p_o_s_s_e_d_ _t_o_._._. by lifeisunfair (12/20/2006) 2674 * _R_F_C_ _8_2_1_:_ _I_ _a_m_ _u_n_a_b_l_e_ _t_o_ _s_e_n_d_ _o_u_t_ _e_-_m_a_i_l_s_._T_h_e_ _e_r_r_o_r_ _m_e_s_s_a_g_e_ _s_a_y_s_:_ _T_h_e 2675 _m_e_s_s_a_g_e_ _c_o_u_l_d_ _n_o_t_ _b_e_._._. by nita (11/5/2004) 2676 * _R_F_C_ _8_2_1_:_ _H_o_w_ _c_a_n_ _I_ _c_r_e_a_t_e_ _a_ _s_c_r_i_p_t_ _d_o_ _r_u_n_ _o_n_ _W_i_n_d_o_w_s_ _?_ _?_ _?_ _I_'_d_ _l_i_k_e_ _t_o 2677 _u_s_e_ _a_ _s_c_r_i_p_t_._._. by Marcelo (11/8/2004) 2678 * _R_F_C_ _8_2_1_:_ _h_o_w_ _s_m_t_p_ _w_o_r_k_s_ _i_n_ _e_x_c_h_a_n_g_e_ _s_y_t_e_m_? by saif (12/4/2005) 2679 * _R_F_C_ _8_2_1_:_ _V_e_r_y_ _G_o_o_d_ _B_u_t_ _I_ _W_a_n_t_ _C_o_d_i_n_g_ _o_f_ _S_i_m_l_e_ _M_a_i_l_ _t_r_a_n_s_f_e_r_ _p_r_o_t_o_c_o_l by 2680 Ankit Pahuja (3/23/2006) 2681 * _R_F_C_ _8_2_1_:_ _T_h_i_s_ _R_F_C_ _i_s_ _o_b_s_o_l_e_t_e_d_ _b_y_ _R_F_C_2_8_2_1_._ _A_n_y_o_n_e_ _s_e_e_k_i_n_g_ _t_o_ _u_n_d_e_r_s_t_a_n_d 2682 _m_o_d_e_r_n_ _S_M_T_P_ _o_r_._._. by William Cole (4/23/2005) 2683 * _R_F_C_ _8_2_1_:_ _C_a_n_ _I_ _a_t_t_a_c_h_ _a_ _f_i_l_e_ _t_o_ _a_n_ _o_u_t_g_o_i_n_g_ _e_-_m_a_i_l_ _o_n_ _t_h_e_ _m_a_i_n_f_r_a_m_e_? by 2684 dphill06 (5/23/2006) 2685 * _R_F_C_ _8_2_1_:_ _I_ _w_a_n_t_ _t_o_ _g_e_t_ _t_h_e_ _i_n_f_o_r_m_a_t_i_o_n_ _o_f_ _u_t_l___s_m_t_p by eagle_hawk (6/2/ 2686 2005) 2687 * _R_F_C_ _8_2_1_:_ _I_ _a_m_ _a_ _M_A_C_ _u_s_e_r_ _w_h_o_ _w_a_s_ _p_r_o_v_i_d_e_d_ _a_n_ _s_m_p_t_ _c_a_p_a_b_i_l_i_t_y_ _w_h_i_c_h_ _I_ _c_a_n 2688 _n_o_t_ _u_s_e_ _f_o_r_ _l_a_c_k_._._. by Larry Stolurow (6/22/2006) 2689 * _R_F_C_ _8_2_1_:_ _A_l_w_a_y_s_ _a_ _g_o_o_d_ _r_e_a_d_!_I_ _i_m_p_l_e_m_e_n_t_ _S_M_T_P_ _o_v_e_r_ _V_B_6_ _W_i_n_s_o_c_k_._ _W_o_r_k_s 2690 _g_r_e_a_t_,_ _r_e_f_e_r_ _t_o_._._. by python_kiss (11/3/2005) 2691 * _R_F_C_ _8_2_1_:_ _v_e_r_y_ _s_i_m_p_l_e_ _t_o_ _c_o_n_f_i_g_u_r_e by dixson (3/26/2007) 2692 * _R_F_C_ _8_2_1_:_ _R_F_C_ _8_2_1_ _d_o_e_s_ _n_o_t_ _c_o_m_m_e_n_t_ _o_n_ _t_h_e_ _v_a_l_i_d_i_t_y_ _o_f_ _t_r_a_i_l_i_n_g_ _d_o_t_s_ _f_o_r 2693 _d_o_m_a_i_n_ _n_a_m_e_s_._ _I_t_._._. by Brett (12/22/2004) 2694 * _R_F_C_ _8_2_1_:_ _W_h_a_t_ _i_s_ _R_F_C_ _f_o_r_m_a_t_?_H_o_ _i_t_ _i_s_ _u_s_e_d_? by siva (3/2/2004) 2695 * _R_F_C_ _8_2_1_:_ _s_i_r_,_w_e_ _a_r_e_ _d_o_i_n_g_ _p_r_o_j_e_c_t_ _o_n_ _S_M_S_ _f_r_o_m_ _m_o_b_i_l_e_ _t_o_ _i_n_t_e_r_n_e_t_._S_o_ _f_o_r 2696 _c_o_m_m_u_n_i_c_a_t_i_n_g_w_i_t_h_._._. by Krishna (5/9/2004) 2697 * _R_F_C_ _8_2_1_:_ _H_i_!_ _V_e_r_y_ _n_i_c_e_ _s_i_t_e_!_ _T_h_a_n_k_s_ _y_o_u_ _v_e_r_y_ _m_u_c_h_!_ _m_8_8_C_X_f_G_F_N_X_H_O_k_S by 2698 rzq9PUrVNv (1/21/2007) 2699 * _R_F_C_ _8_2_1_:_ _i_ _n_e_e_t_ _s_l_e_e_p_ _p_f_f_f_f_f_f_ _w_a_t_ _i_ _n_e_e_ _t_e_ _d_o_e by goldface (9/24/2005) 2700 2701 Previous: _R_F_C_ _0_8_2_0_ _-_ _A_s_s_i_g_n_e_d_ _n_u_m_b_e_r_s Next: _R_F_C_ _0_8_2_2_ _-_ _S_T_A_N_D_A_R_D_ _F_O_R_ _T_H_E 2702 _F_O_R_M_A_T_ _O_F_ _A_R_P_A_ _I_N_T_E_R_N_E_T_ _T_E_X_T_ _M_E_S_S_A_G_E_S 2703 2704 =============================================================================== 2705 [ _R_F_C_ _I_n_d_e_x | _R_F_C_ _S_e_a_r_c_h | _U_s_e_n_e_t_ _F_A_Q_s | _W_e_b_ _F_A_Q_s | _D_o_c_u_m_e_n_t_s | _C_i_t_i_e_s ] 2706 © 2008 FAQS.ORG. All rights reserved. 2707