idnits 2.17.1 draft-ietf-fax-smtp-session-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 9 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 754 has weird spacing: '...for the purpo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'REPORT-EXTEND' is mentioned on line 57, but not defined == Missing Reference: 'FAX-DSN' is mentioned on line 78, but not defined == Missing Reference: 'DSN' is mentioned on line 295, but not defined == Unused Reference: 'REPORT-EXTENSIONS' is defined on line 703, but no explicit reference was found in the text -- No information found for draft-ietf-drums-smtpupd- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'DRUMS' -- No information found for draft-ietf-fax-report-extensions - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'REPORT-EXTENSIONS' ** Obsolete normative reference: RFC 821 (Obsoleted by RFC 2821) ** Downref: Normative reference to an Unknown state RFC: RFC 1047 ** Obsolete normative reference: RFC 1830 (Obsoleted by RFC 3030) ** Obsolete normative reference: RFC 1891 (Obsoleted by RFC 3461) ** Obsolete normative reference: RFC 1893 (Obsoleted by RFC 3463) ** Obsolete normative reference: RFC 1869 (Obsoleted by RFC 2821) ** Downref: Normative reference to an Informational RFC: RFC 2033 ** Obsolete normative reference: RFC 2197 (Obsoleted by RFC 2920) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 18 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Applications Area Neil Joffe 3 Internet Draft Dan Wing 4 August 7, 1998 Cisco Systems 5 Expires January 1999 Larry Masinter 6 Xerox Corporation 8 SMTP Service Extension for 9 Immediate Delivery 11 draft-ietf-fax-smtp-session-04.txt 13 Status of this memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 To view the entire list of current Internet-Drafts, please check 26 the "1id-abstracts.txt" listing contained in the Internet-Drafts 27 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 28 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 29 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 30 (US West Coast). 32 NOTE: although this work has been discussed in the IETF-FAX 33 working group, it does not purport to represent the 34 consensus of the group. 36 Copyright Notice 38 Copyright (C) The Internet Society (1997, 1998). All Rights 39 Reserved. 41 Abstract 43 This memo defines an extension to SMTP which provides a mechanism for 44 requesting immediate message delivery over SMTP instead of normal 45 store-and-forward delivery. It also provides a mechanism for 46 querying the SMTP server if immediate delivery was successful, is 47 still in progress, or was simply queued as a normal store-and-forward 48 message. 50 0. Administrivia 52 0.1. Changes Since Previous Versions 54 Changes from -03 to -04: 55 * Added "failed" code. 56 * Added status=x.y.z, where x.y.z is from RFC1893 and 57 FAX Report Extensions [REPORT-EXTEND]. 59 Changes from draft-ietf-fax-smtp-session-02.txt to -03: 60 * Corrected grammer and typos. Added clarifications to 61 some areas. 63 Changes from draft-ietf-fax-smtp-session-01.txt to -02: 65 * Added sequence of events and state diagram sections 66 to clarify timing and responsibility issues. 68 * Server's reply to STAT is now a sequence of simple codes instead 69 of a multipart/report. 71 * STAT command polls for all recipients that had SESSION 72 on the RCPT command. 74 Changes from draft-ietf-fax-smtp-session-00.txt to -01: 76 * Added copyright notice 78 * Reference to [FAX-DSN]. 80 Changes from draft-wing-smtp-session-00 to 81 draft-ietf-fax-smtp-session-00.txt: 83 * Server's reply to STAT is now a complete multipart/report 85 * Language clarifications 87 * Require immediate SMTP server reply after client sends "." 89 * Specify SMTP server must respond to STAT within 30 seconds 91 1. Introduction 93 Historically, SMTP [RFC821] has been used for store and forward 94 delivery of messages. This memo describes a new SMTP extension 95 called SESSION. This new extension allows an SMTP client to request 96 immediate delivery by the SMTP server. 98 This Session extension was motivated by an analysis of the 99 requirements for using the Internet to deliver fax messages, and, 100 coupled with a mechanism for exchanging capabilities and preferences 101 of sender and recipient, can be used by email<->fax gateway 102 applications. In addition, the SESSION extension may be useful for 103 other messaging applications where immediate delivery and 104 confirmation of immediate delivery are requested. 106 The LMTP protocol [RFC2033] provides immediate delivery, but as 107 discussed in [RFC2033] can aggravate the duplicate message delivery 108 problem [RFC1047], especially over a WAN. The Session extension 109 described in this memo is intended to provide immediate delivery of 110 SMTP messages without aggravating the duplicate message delivery 111 problem. 113 This extension presumes either a direct connection between sender and 114 recipient or a chain of session-enabled servers in which each 115 supports this Session extension. 117 If an MTA in the SMTP "path" does not support Session, delivery 118 automatically falls back to normal store and forward, and such 119 fallback is communicated to the SMTP client, as described in section 120 3.2. 122 Unlike the deprecated SAML, SOML and SEND commands (documented in 123 [RFC821] and deprecated in [DRUMS]) the SESSION extension allows for a 124 mix of immediate and store & forward delivery recipients. 126 This memo uses the mechanism described in [RFC1869] to define an 127 extension to the SMTP protocol for immediate delivery. 129 1.2. Discussion of This Draft 131 This draft is being discussed on the "ietf-fax" mailing list. To 132 subscribe, send a message to with the line 133 "subscribe" in the body of the message. Archives are available from 134 http://www.imc.org/ietf-fax. 136 1.3. Requirements Notation 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 2. Framework for Immediate Delivery Support 144 The immediate message delivery is defined as follows: 146 (1) The name of the immediate extension is Session; 148 (2) the EHLO keyword value associated with the immediate 149 extension is SESSION; 151 (3) no parameter is used with the SESSION EHLO keyword; 153 (4) one new SMTP verb, STAT (used to determine if immediate 154 delivery was successful) is defined with this extension, and 155 is described in section 3; 157 (5) one optional parameter is added to the RCPT command, using 158 the esmtp-keyword SESSION, and is described in section 4, 160 no parameters are added to the MAIL FROM command; 162 (6) the maximum length of a RCPT TO is increased by 8 163 characters. 165 3. Esmtp-keyword SESSION 167 Upon receiving a RCPT command with the esmtp-keyword SESSION, a 168 session-enabled server will normally send either a positive (2xx) or 169 negative (5xx) reply to the SMTP client. 171 A 250 reply code indicates that the session-enabled server believes 172 the message will be sent immediately -- that is, that the request for 173 SESSION delivery will be honored. 175 If a session-enabled server is aware that it will be unable to 176 send the message immediately (that is, the request for SESSION will 177 not be honored), but the session-enabled server is willing to send 178 the message via its normal SMTP queue, it SHOULD respond with a 252 179 reply code. The SMTP client can use this information to inform the 180 user that immediate delivery isn't available, and the SMTP client (or 181 the user) may decide on a different transmission mechanism. 183 3.1. Delivery Responsibility 185 As per normal SMTP, once a sender has received a positive response to 186 its end of mail data indicator, the receiver has accepted all 187 responsibility for message delivery. 189 If an MTA is relaying a message using this Session extension, 190 and it fails to receive a positive response to its end of mail data 191 indicator from the next-hop mailer, the Session-enabled MTA MUST 192 queue the message as a normal SMTP store-and-forward message for 193 later delivery. This is because the MTA performing the relaying 194 accepted responsibility for message delivery at this point. See 195 the section "Sequence of Events" for details. 197 3.2. Fallback to Store and Forward 199 This section describes scenarios which would cause immediate delivery 200 to fallback to normal store-and-forward delivery. 202 3.2.1. Mailers that do not implemention this Session extension 204 If an MTA is encountered which does not support the Session 205 extension, the MTA which detected this SHOULD respond to 206 its incoming SMTP connection with a 252 response code. As 207 Session delivery is not possible to the next-hop mailer, 208 normal store-and-forward mail delivery will occur. 210 3.2.1. Excessive Delays with Multiple MTAs 212 The cumulative delays of going through many MTAs will cause Session 213 delivery to fail (by falling back to normal store-and-forward). 214 Proper configuration and deployment of SMTP servers will prevent this 215 problem. 217 Implementors must carefully design session-enabled MTAs to respond 218 quickly when Session recipients are present to minimize timing 219 problems. Each MTA is maintaining its own SMTP timeouts 220 which can't be exceeded by the entire end-to-end delay [RFC1123]. 222 Additionally, Session is not expected to work reliably across 223 lossy links or with overloaded mailers. 225 3.3. Sequence of Events and State Diagrams 227 This section describes the sequence of events for a RCPT command 228 that contains the esmtp-keyword SESSION, and also includes 229 State Diagrams for various components. 231 3.3.1. Events - Single Remote MTA 233 If the RCPT command contains the esmtp-keyword SESSION, the 234 SMTP server SHOULD connect to the next-hop mailer prior to 235 responding to the SMTP client's RCPT command. 237 +-----+ +--------+ +-------+ +-----------+ 238 | user| => |Original| ==> | MTA-1 | => | receiving | user@host-x 239 |agent| | MTA | | | | MTA-1 | 240 +-----+ +--------+ +-------+ +-----------+ 241 (A) (B) (C) (D) 243 Using the above diagram: 245 1. the SMTP client (A) would initiate an SMTP transaction with 246 (B), and send a RCPT command with the esmtp-keyword SESSION to 247 (B), then 249 2. (B) would initiate an SMTP transaction with (C) and send the 250 same RCPT command with the esmtp-keyword SESSION to (C), then 252 3. (C) would initiate an SMTP transaction with (D) and send the 253 same RCPT command with the esmtp-keyword to (D), then 255 4. (D) would send its response to (C), which would send the 256 response to (B), which would send the response to (A), then 258 5. (A) would send its next RCPT command (if sending to 259 multiple recipients), then 261 6. (A) would indicate it wants to send the message body by 262 sending the DATA (or BDAT if using [RFC1830]) command, then 264 7. (B) would send the DATA (or BDAT) command to (C), 265 which would send it to (D), which would send its response 266 code to (C), which is sent to (B), which is sent to 267 (A), then 269 8. (A) sends its message body to (B), which SHOULD spool 270 it to a local disk while sending it to (C), which SHOULD 271 spool it to a local disk while sending it to (D), which 272 writes it to the local user's mailstore. 274 9. (A) sends its end of mail data indicator ("." unless using 275 [RFC1830]), then 277 10. (B) responds to the end of mail data indicator immediately 278 (and is now responsible for message delivery should it 279 fail after this point), then (B) sends the end of mail data 280 indicator to (C), then 282 11. (C) responds to the end of mail data indicator 283 immediately (and is now responsible for message delivery 284 should it fail after this point), then (C) sends the end of 285 mail data indicator to (D) 287 12. (D) responds to the end of mail data indicator when it has 288 finished writing to the user's mailbox. 290 If there are multiple local recipients and one or more 291 recipients succeeded, but at least one failed, (D) must issue 292 a postive response code to prevent duplicate message delivery 293 [RFC1047]. It MUST generate a bounce message for the failed 294 local recipient(s), and the bounce SHOULD be in the format 295 of a DSN [DSN]. 297 3.3.2. Events - Multiple Remote MTAs 299 The case where there are multiple remote MTAs is a more complex 300 case than described above, but the same rules apply. 302 +-----------+ 303 -=> | receiving | user@host-x 304 / | MTA-1 | 305 +-----+ +--------+ / +-----------+ 306 | user| => |Original| =< (C) 307 |agent| | MTA | \ 308 +-----+ +--------+ \ +-----------+ 309 (A) (B) -=> | receiving | user@host-y 310 | MTA-2 | 311 +-----------+ 312 (D) 314 (B) would have to send the appropriate RCPT command with the 315 esmtp-keyword SESSION, the appropriate next-hop MTA (C or D) for each 316 recipient (user@host-x, user@host-y) and echo the responses back to 317 (A). 319 When (A) sends its DATA command, (B) would have to send the DATA 320 command to both MTAs, and reply to (A) if both MTAs have responded 321 positively. 323 When (A) sends its end of mail data indicator, (B) must respond 324 immediately, and then (B) can send the end of mail data indicator 325 to (C) and (D). 327 If (B) does not receive a positive (2xx) response from (C) or (D), 328 (B) must queue the message as a normal store and forward message. 330 3.3.3. State diagram - MTA relay 332 The following state diagram describes the behavior of an MTA relaying 333 Session connection. 335 | 336 V (1) 337 +---------+ (2) +---------+ 338 | Setup |------>| Connect | 339 | message |<------| forward | 340 +---------+ (3) +---------+ 341 | 342 V (4) 343 +---------+ (5) +---------+ (6) +---------+ (7) +--------+ 344 | Sending |---->| Waiting |---->| Gather |---->| Query | 345 | data | | |<----| status |<----| status | 346 +---------+ +---------+ (9) +---------+ (8) +--------+ 347 | 348 V (10) 349 +----------+ 350 | Complete | 351 +----------+ 353 (1) Event: Incoming MAIL FROM. 354 Test: - 355 Action: Prepare to forward message. 357 (2) Event: incoming RCPT TO 358 Test: 359 Action: IF connection to next-hop server for this message does 360 not already exist then create connection and issue MAIL 361 FROM command. Issue RCPT TO command to next-hop 362 server. 364 (3) Event: Response to RCPT TO command. 365 Test: - 366 Action: Respond to incoming RCPT TO. 368 (4) Event: Incoming DATA/BDAT. 369 Test: - 370 Action: Issue DATA/BDAT on forward connections, and 371 forward data as it is received. 373 (5) Event: End of data, with confirmation from all downstream MTAs 374 Test: - 375 Action: Wait 377 (6) Event: Incoming STAT command. 378 Test: - 379 Action: Start gathering status - straight to (7) 381 (7) Event: - 382 Test: There are more downstream MTAs to query. 383 Action: Issue STAT command on next downstream MTA. 385 (8) Event: Response to STAT command. 386 Test: - 387 Action: Pass back as response to incoming STAT. If status 388 indicates completion then close the downstream 389 connection. 391 (9) Event: - 392 Test: There are no more downstream MTAs to query. 393 Action: Wait. 395 (10) Event: Incoming RSET, MAIL FROM or SMTP connection broken. 396 Test: - 397 Action: Close any remaining downstream connections. 399 4. New SMTP Verb STAT 401 One new SMTP verb is introduced with this extension. The STAT verb 402 causes the SMTP server to respond with the Session delivery status of 403 all Session recipients. 405 An SMTP client MAY send the STAT command if it used the esmtp-keyword 406 SESSION on one of its RCPT commands, but the SMTP client is not 407 required to use the STAT verb. SMTP servers which implement the 408 SESSION extension MUST implement the STAT verb. 410 The SMTP client MUST NOT send the STAT command unless all of the 411 following are true: (1) the SMTP client sent a RCPT command with the 412 esmtp-keyword SESSION; (2) the SMTP server sent a positive response 413 to that RCPT command; (3) the SMTP client has finished sending the 414 message body and sent the end of mail data indicator ("." or BDAT 415 LAST). If the SMTP client sends the STAT command when not all of the 416 above conditions are met, the SMTP server MUST send a response code 417 of 503. 419 The syntax of the STAT verb, using the notation described in 420 [RFC2234], is: 422 stat-cmd = "STAT" CR LF 424 4.1. Format of STAT Response 426 The SMTP server's positive response to the STAT command is a 427 multiline SMTP response. Each line contains information on each 428 Session recipient, in the order specified by the SMTP client. 430 If the SMTP server is making a negative response to the STAT command 431 the response should be a 5xx response code and follow the normal SMTP 432 rules for multiple line responses. There is no specific format of 433 5xx responses. 435 The syntax of the positive response must be parsable by an SMTP 436 client. Using the notation described in [RFC2234], the syntax is: 438 stat-response = *( "250-" [cmd-status SP] resp-line CR LF ) 439 "250 " [cmd-status SP] resp-line CR LF 441 resp-line = forward-path SP session-status 442 [SP "by=" mta-hostname] 444 session-status = "delivered" terminal / 445 "in-progress" SP prog-value / 446 "queued" terminal / 447 "failed" terminal 449 terminal = SP trans-status [SP trans-id] 451 trans-status = "status=" status-code 453 trans-id = "trans=" transaction 455 status-code = <"status-code" from [RFC1893], with 456 extensions defined in [REPORT-EXTENSIONS]> 458 prog-value = sent-count "/" total-count 460 sent-count = 1*DIGIT 462 total-count = 1*DIGIT 464 mta-hostname = *( ALPHA / DIGIT / "." / "-" / "_" ) 466 transaction = *( ALPHA / DIGIT / "." / "-" / "_" ) 468 cmd-status = "2.5.0" 471 forward-path = " characters> 474 The can be spelled in any combination of uppercase 475 and lowercase letters. The meaning of the various values are 476 as follows: 478 "delivered" Session delivery was successful. Message was 479 delivered to the recipient immediately. This is a 480 terminal value. This can optionally be followed 481 with . 483 "in-progress" Session delivery has not yet completed. A STAT 484 command issued later will show final status of this 485 message. This is the only non-terminal value. This 486 must be followed by . 488 "queued" Session delivery failed for some reason, but the MTA 489 was able to successfully queue the message using 490 normal SMTP store-and-forward. One cause of this 491 status is when the session-enabled server forwards the 492 message to a non-session-enabled server. This is a 493 terminal value. This can optionally be followed 494 with . 496 "failed" Delivery failed. The message will be bounced if 497 no DSN was requested, or if a DSN including 498 "NOTIFY=FAILED" was requested [RFC1891]. 500 indicates the host generating the information, 501 and can be used to help trace a message passing along a path 502 of session-aware mailers. 504 is used to provide the client with a unique transaction 505 number to associate with each delivery. This can be useful for 506 accounting or tracing messages. This number need only be unique 507 for that MTA, it doesn't need to be world-unique. 509 The two values of the element can be page numbers, byte 510 counts, disk blocks, or any other useful count of the progress of 511 this transaction, as determined by the SMTP server. The values 512 can be displayed by the MUA to the user as-is, or the MUA can use the 513 values to calculate the percentage of completion for presentation 514 to the user. The value of is the number of units 515 the SMTP server has received, the value of is the 516 number of units the SMTP server has sent to the next-hop 517 mailer. See example 6.1. 519 If an SMTP client sends a STAT command and the SMTP server has 520 already informed the SMTP client (in the response to a previous 521 STAT command) that all recipients had terminal values, the SMTP 522 server MAY return a 503 reply. 524 4.2. Sequence of Events 526 The STAT command has a similar sequence of events as described 527 in section 3.3, above. 529 Note that the STAT command can only be issued in the same 530 SMTP transaction. There is no provision for an SMTP client to 531 start a new SMTP transaction and query the status of Session 532 delivery for a previous SMTP transaction. 534 4.3. Timing Considerations 536 The SMTP server SHOULD respond to a STAT command no later than 60 537 seconds after a STAT command is received. After 120 seconds an SMTP 538 client MAY assume the connection to the SMTP server is broken. 540 To prevent excessive network activity by an SMTP client querying 541 delivery status "too often", the SMTP server may delay responding to 542 a client's STAT command. Such a delay MUST NOT exceed 10 seconds. 544 Due to the delays inherent in establishing connections with each MTA 545 in the SMTP "path", SMTP servers that implement the Session extension 546 SHOULD also implement [RFC2197], and SMTP clients SHOULD use 547 pipelining if available. 549 5. Security Considerations 551 This section describes new security vulnerabilities that are 552 introduced with this SMTP extension. Security vulnerabilities 553 that are inherient to SMTP itself are not described. 555 5.1. Denial of Service 557 As Session consumes more resources on MTAs, denial of service attacks 558 against MTAs may be more effective. 560 XXX - more verbage 562 5.2. Abuse of Immediate Delivery 564 This is some concern that users will always choose the 'deliver 565 immediately' button or mailer option in their MUA. As immediate 566 delivery requires more resources on MTAs, this is indeed a 567 concern. 569 To alleviate such concerns, ISPs could charge extra for immediate 570 delivery involving their mailers, offering immediate delivery 571 as a value-add service, not accept Session messages during periods of 572 high usage, or limit the total number of Session connections or 573 the number of Session connections to/from certain hosts or 574 domains. 576 6. Examples 578 In examples, "C:" and "S:" indicate lines sent by the client and 579 server respectively. If such lines are wrapped without a new "C:" or 580 "S:" label, then the wrapping is for editorial clarity and is not 581 part of the command. 583 6.1. Successful Session Delivery to Two Recipients 585 This example shows a successful Session delivery with two recipients. 586 The first recipient, bill@fuggles.com, was still being queued when 587 the first STAT command was sent by the client, but a subsequent STAT 588 command shows the final status. 590 S: 220 mailer.cisco.com ESMTP service ready 591 C: EHLO pc.cisco.com 592 S: 250-mailer.cisco.com says hello 593 S: 250 SESSION 594 C: MAIL FROM: 595 S: 250 Sender ok 596 C: RCPT TO: SESSION 597 S: 250 and options ok 598 C: RCPT TO: SESSION 599 S: 250 and options ok 600 C: DATA 601 S: 354 Enter your data 602 C: From: Dan Wing 603 C: To: njoffe@cisco.com, bill@fuggles.com 604 C: Date: Mon, 6 Oct 1997 12:42:32 -0700 605 C: Subject: Palo Alto Coffee shops 606 C: 607 C: What is a good coffee shop in Palo Alto? 608 C: . 609 S: 250 message accepted 610 C: STAT 611 S: 250- in-progress 5/184 by=fwall.cisco.com 612 S: 250 delivered by=popstore.cisco.com 613 trans=E23132 614 C: STAT 615 S: 250- in-progress 43/50 by=example.com 616 S: 250 delivered by=popstore.cisco.com 617 trans=E23132 618 C: STAT 619 S: 250- delivered by=mailer.fuggles.com 620 S: 250 delivered by=popstore.cisco.com 621 trans=E23132 622 C: QUIT 623 S: 221 Goodbye 625 (The string "trans=E23132" is shown on a separate line in 626 this example for clarity. The string would appear on one line. 628 6.2. Unsuccessful Session Delivery 630 This example shows the client wanted to send the message 631 immediately, and the server responded with a "250" (indicating 632 it believed the message could be sent immediately), but a problem 633 occurred forcing the mailer at pea.com to deliver the message 634 using store-and-forward. 636 S: 220 mailer.cisco.com ESMTP service ready 637 C: EHLO pc.cisco.com 638 S: 250-mailer.cisco.com says hello 639 S: 250 SESSION 640 C: MAIL FROM: 641 S: 250 Sender ok 642 C: RCPT TO: SESSION 643 S: 250 and options ok 644 C: DATA 645 S: 354 Enter your data 646 C: From: Dan Wing 647 C: To: "Jolly" 648 C: Date: Mon, 6 Oct 1997 12:42:32 -0700 649 C: Subject: Veggies 650 C: 651 C: Veggies are good for you, but from a can? 652 C: . 653 S: 250 message accepted 654 C: STAT 655 S: 250 queued by=peas.com 656 C: QUIT 657 S: 221 Goodbye 659 6.3. SMTP Client Disconnects Before Sending STAT 661 The SMTP client is not required to query the success/failure 662 of immediate message delivery. The following transaction 663 is legal. 665 S: 220 mailer.cisco.com ESMTP service ready 666 C: EHLO pc.cisco.com 667 S: 250-mailer.cisco.com says hello 668 S: 250 SESSION 669 C: MAIL FROM: 670 S: 250 Sender ok 671 C: RCPT TO: SESSION 672 S: 250 and options ok 673 C: DATA 674 S: 354 Enter your data 675 C: From: Dan Wing 676 C: To: masinter@parc.xerox.com 677 C: Date: Mon, 6 Oct 1997 12:42:32 -0700 678 C: Subject: Palo Alto Coffee shops 679 C: 680 C: How does this look? 681 C: . 682 S: 250 message accepted 683 C: QUIT 684 S: 221 Goodbye 686 7. Acknowledgments 688 Much of this document was produced by work begun in the Internet FAX 689 Working Group of the IETF. 691 The authors would like to thank Ned Freed (Innosoft), Graham Klyne 692 (Integralis), Keith Moore (University of Tennessee), Jeff 693 VanDyke (NetCentric), and Greg Vaudreuil (Lucent) for their 694 contributions to this work. 696 ((others?)) 698 8. References 700 [DRUMS] J. Klensin, D. Mann, "Simple Mail Transfer Protocol", 701 Internet Draft, Work in Progress, draft-ietf-drums-smtpupd-??.txt. 703 [REPORT-EXTENSIONS] D. Wing, "Fax Extensions to DSN and MDN", 704 Internet Draft, Work in Progress, 705 draft-ietf-fax-report-extensions.txt. 707 [RFC821] J. Postel, "Simple Mail Transfer Protocol", STD-10, RFC 821, 708 August 1982. 710 [RFC1047] C. Partridge, "DUPLICATE MESSAGES AND SMTP", RFC 1047, 711 February 1988. 713 [RFC1123] R. Braden, "Requirements for Internet Hosts -- Application 714 and Support", RFC 1123, October 1989. 716 [RFC1830] G. Vaudreuil, "SMTP Service Extensions for Transmission of 717 Large and Binary MIME Messages", RFC 1830 (Experimental), August 718 1995. 720 [RFC1891] K. Moore, "SMTP Service Extension for Delivery Status 721 Notifications", RFC 1891, January 1996. 723 [RFC1893] G. Vaudreuil, "Enhanced Mail System Status Codes", RFC 724 1893, January 1996. 726 [RFC1869] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, 727 "SMTP Service Extensions", STD-10, RFC 1869, November 1995. 729 [RFC2033] J. Myers, "Local Mail Transfer Protocol", RFC 2033, October 730 1996. 732 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 733 Requirement Levels", BCP-14, RFC 2119, March 1997. 735 [RFC2197] N. Freed, "SMTP Service Extension for Command Pipelining", 736 RFC 2197, September 1997. .in -5 738 [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax 739 Specifications: ABNF", RFC 2234, November 1997. 741 9. Copyright 743 Copyright (C) The Internet Society (1997, 1998). All Rights 744 Reserved. 746 This document and translations of it may be copied and furnished to 747 others, and derivative works that comment on or otherwise explain it 748 or assist in its implmentation may be prepared, copied, published and 749 distributed, in whole or in part, without restriction of any kind, 750 provided that the above copyright notice and this paragraph are 751 included on all such copies and derivative works. However, this 752 document itself may not be modified in any way, such as by removing 753 the copyright notice or references to the Internet Society or other 754 Internet organizations, except as needed for the purpose of 755 developing Internet standards in which case the procedures for 756 copyrights defined in the Internet Standards process must be 757 followed, or as required to translate it into languages other than 758 English. 760 The limited permissions granted above are perpetual and will not be 761 revoked by the Internet Society or its successors or assigns. 763 This document and the information contained herein is provided on an 764 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 765 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 766 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 767 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 768 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 770 10. Authors' Addresses 772 Neil Joffe 773 Cisco Systems, Inc. 774 170 West Tasman Drive 775 San Jose, CA 95134-1706 USA 777 Phone: +1 408 526 4000 778 Email: njoffe@cisco.com 780 Dan Wing 781 Cisco Systems, Inc. 782 101 Cooper Street 783 Santa Cruz, CA 95060 USA 785 Phone: +1 408 457 5200 786 Fax: +1 408 457 5208 787 Email: dwing@cisco.com 789 Larry Masinter 790 Xerox Palo Alto Research Center 791 3333 Coyote Hill Road 792 Palo Alto, CA 94304 USA 794 Phone: +1 415 812 4365 795 Fax: +1 415 812 4333 796 Email: masinter@parc.xerox.com