idnits 2.17.1 draft-ietf-smtpext-extensions-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. == 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 8 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- The document date (April 11, 1995) is 10601 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 821 (ref. '1') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (ref. '2') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1521 (ref. '3') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1522 (ref. '4') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group John Klensin, WG Chair 2 Internet Draft Ned Freed, Editor 3 Marshall Rose 4 Einar Stefferud 5 David Crocker 7 SMTP Service Extensions 9 April 11, 1995 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are 14 working documents of the Internet Engineering Task Force 15 (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months. Internet-Drafts may be updated, replaced, or obsoleted 21 by other documents at any time. It is not appropriate to use 22 Internet-Drafts as reference material or to cite them other 23 than as a "working draft" or "work in progress". 25 To learn the current status of any Internet-Draft, please 26 check the 1id-abstracts.txt listing contained in the 27 Internet-Drafts Shadow Directories on ds.internic.net (US East 28 Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), 29 or munnari.oz.au (Pacific Rim). 31 This draft is intended to supercede RFC 1651. 33 1. Abstract 35 This memo defines a framework for extending the SMTP service 36 by defining a means whereby a server SMTP can inform a client 37 SMTP as to the service extensions it supports. Extensions to 38 the SMTP service are registered with the IANA. This framework 39 does not require modification of existing SMTP clients or 40 servers unless the features of the service extensions are to 41 be requested or provided. 43 2. Introduction 45 The Simple Mail Transfer Protocol (SMTP) [1] has provided a 46 stable, effective basis for the relay function of message 47 transfer agents. Although a decade old, SMTP has proven 48 remarkably resilient. Nevertheless, the need for a number of 49 protocol extensions has become evident. Rather than describing 50 these extensions as separate and haphazard entities, this 51 document enhances SMTP in a straightforward fashion that 52 provides a framework in which all future extensions can be 53 built in a single consistent way. 55 3. Framework for SMTP Extensions 57 For the purpose of service extensions to SMTP, SMTP relays a 58 mail object containing an envelope and a content. 60 (1) The SMTP envelope is straightforward, and is sent as a 61 series of SMTP protocol units: it consists of an 62 originator address (to which error reports should be 63 directed); a delivery mode (e.g., deliver to recipient 64 mailboxes); and, one or more recipient addresses. 66 (2) The SMTP content is sent in the SMTP DATA protocol unit 67 and has two parts: the headers and the body. The 68 headers form a collection of field/value pairs 69 structured according to RFC 822 [2], whilst the body, 70 if structured, is defined according to MIME [3]. The 71 content is textual in nature, expressed using the US 72 ASCII repertoire (ANSI X3.4-1986). Although extensions 73 (such as MIME) may relax this restriction for the 74 content body, the content headers are always encoded 75 using the US ASCII repertoire. The algorithm defined in 76 [4] is used to represent header values outside the US 77 ASCII repertoire, whilst still encoding them using the 78 US ASCII repertoire. 80 Although SMTP is widely and robustly deployed, some parts of 81 the Internet community might wish to extend the SMTP service. 82 This memo defines a means whereby both an extended SMTP client 83 and server may recognize each other as such and the server can 84 inform the client as to the service extensions that it 85 supports. 87 It must be emphasized that any extension to the SMTP service 88 should not be considered lightly. SMTP's strength comes 89 primarily from its simplicity. Experience with many protocols 90 has shown that: 92 protocols with few options tend towards ubiquity, whilst 93 protocols with many options tend towards obscurity. 95 This means that each and every extension, regardless of its 96 benefits, must be carefully scrutinized with respect to its 97 implementation, deployment, and interoperability costs. In 98 many cases, the cost of extending the SMTP service will likely 99 outweigh the benefit. 101 Given this environment, the framework for the extensions 102 described in this memo consists of: 104 (1) a new SMTP command (section 4) 106 (2) a registry of SMTP service extensions (section 5) 108 (3) additional parameters to the SMTP MAIL FROM and RCPT TO 109 commands (section 6). 111 4. The EHLO command 113 A client SMTP supporting SMTP service extensions should start 114 an SMTP session by issuing the EHLO command instead of the 115 HELO command. If the SMTP server supports the SMTP service 116 extensions it will give a successful response (see section 117 4.3), a failure response (see 4.4), or an error response 118 (4.5). If the SMTP server does not support any SMTP service 119 extensions it will generate an error response (see section 120 4.5). 122 4.1. Changes to RFC 821 124 RFC 821 states that the first command in an SMTP session must 125 be the HELO command. This requirement is hereby amended to 126 allow a session to start with either EHLO or HELO. 128 4.2. Command syntax 130 The syntax for this command, using the ABNF notation of [2], 131 is: 133 ehlo-cmd ::= "EHLO" SP domain CR LF 135 If successful, the server SMTP responds with code 250. On 136 failure, the server SMTP responds with code 550. On error, the 137 server SMTP responds with one of codes 500, 501, 502, 504, or 138 421. 140 This command is issued instead of the HELO command, and may be 141 issued at any time that a HELO command would be appropriate. 142 That is, if the EHLO command is issued, and a successful 143 response is returned, then a subsequent HELO or EHLO command 144 will result in the server SMTP replying with code 503. A 145 client SMTP must not cache any information returned if the 146 EHLO command succeeds. That is, a client SMTP must issue the 147 EHLO command at the start of each SMTP session if information 148 about extended facilities is needed. 150 4.3. Successful response 152 If the server SMTP implements and is able to perform the EHLO 153 command, it will return code 250. This indicates that both 154 the server and client SMTP are in the initial state, that is, 155 there is no transaction in progress and all state tables and 156 buffers are cleared. 158 Normally, this response will be a multiline reply. Each line 159 of the response contains a keyword and, optionally, one or 160 more parameters. The syntax for a positive response, using the 161 ABNF notation of [2], is: 163 ehlo-ok-rsp ::= "250" domain [ SP greeting ] CR LF 164 / ( "250-" domain [ SP greeting ] CR LF 165 *( "250-" ehlo-line CR LF ) 166 "250" SP ehlo-line CR LF ) 168 ; the usual HELO chit-chat 169 greeting ::= 1* 171 ehlo-line ::= ehlo-keyword *( SP ehlo-param ) 172 ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") 174 ; syntax and values depend on ehlo-keyword 175 ehlo-param ::= 1* 179 ALPHA ::= 182 DIGIT ::= 185 CR ::= 187 LF ::= 189 SP ::= 192 Although EHLO keywords may be specified in upper, lower, or 193 mixed case, they must always be recognized and processed in a 194 case-insensitive manner. This is simply an extension of 195 practices begun in RFC 821. 197 The IANA maintains a registry of SMTP service extensions. 198 Associated with each such extension is a corresponding EHLO 199 keyword value. Each service extension registered with the IANA 200 must be defined in an RFC. Such RFCs must either be on the 201 standards-track or must define an IESG-approved experimental 202 protocol. The definition must include: 204 (1) the textual name of the SMTP service extension; 206 (2) the EHLO keyword value associated with the extension; 208 (3) the syntax and possible values of parameters associated 209 with the EHLO keyword value; 211 (4) any additional SMTP verbs associated with the extension 212 (additional verbs will usually be, but are not required 213 to be, the same as the EHLO keyword value); 215 (5) any new parameters the extension associates with the 216 MAIL FROM or RCPT TO verbs; and, 218 (6) how support for the extension affects the behavior of a 219 server and client SMTP. 221 In addition, any EHLO keyword value that starts with an upper 222 or lower case "X" refers to a local SMTP service extension, 223 which is used through bilateral, rather than standardized, 224 agreement. Keywords beginning with "X" may not be used in a 225 registered service extension. 227 Any keyword values presented in the EHLO response that do not 228 begin with "X" must correspond to a standard, standards-track, 229 or IESG-approved experimental SMTP service extension 230 registered with IANA. A conforming server must not offer non 231 "X" prefixed keyword values that are not described in a 232 registered extension. 234 Additional verbs are bound by the same rules as EHLO keywords; 235 specifically, verbs begining with "X" are local extensions 236 that may not be registered or standardized and verbs not 237 beginning with "X" must always be registered. 239 4.4. Failure response 241 If for some reason the server SMTP is unable to list the 242 service extensions it supports, it will return code 554. 244 In the case of a failure response, the client SMTP should 245 issue either the HELO or QUIT command. 247 4.5. Error responses from extended servers 249 If the server SMTP recognizes the EHLO command, but the 250 command argument is unacceptable, it will return code 501. 252 If the server SMTP recognizes, but does not implement, the 253 EHLO command, it will return code 502. 255 If the server SMTP determines that the SMTP service is no 256 longer available (e.g., due to imminent system shutdown), it 257 will return code 421. 259 In the case of any error response, the client SMTP should 260 issue either the HELO or QUIT command. 262 4.6. Responses from servers without extensions 264 A server SMTP that conforms to RFC 821 but does not support 265 the extensions specified here will not recognize the EHLO 266 command and will consequently return code 500, as specified in 267 RFC 821. The server SMTP should stay in the same state after 268 returning this code (see section 4.1.1 of RFC 821). The 269 client SMTP may then issue either a HELO or a QUIT command. 271 4.7. Responses from improperly implemented servers 273 Some SMTP servers are known to disconnect the SMTP 274 transmission channel upon receipt of the EHLO command. The 275 disconnect can occur immediately or after sending a response. 276 Such behavior violates section 4.1.1 of RFC 821, which 277 explicitly states that disconnection should only occur after a 278 QUIT command is issued. 280 Nevertheless, in order to achieve maxmimum interoperablity it 281 is suggested that extended SMTP clients using EHLO be coded to 282 check for server connection closure after EHLO is sent, either 283 before or after returning a reply. If this happens the client 284 must decide if the operation can be successfully completed 285 without using any SMTP extensions. If it can a new connection 286 can be opened and the HELO command can be used. 288 Other improperly-implemented servers will not accept a HELO 289 command after EHLO has been sent and rejected. In some cases, 290 this problem can be worked around by sending a RSET after the 291 failure response to EHLO, then sending the HELO. Clients that 292 do this should be aware that many implementations will return 293 a failure code (e.g., 503 Bad sequence of commands) in 294 response to the RSET. This code can be safely ignored. 296 5. Initial IANA Registry 298 The IANA's initial registry of SMTP service extensions 299 consists of these entries: 301 Service Ext EHLO Keyword Parameters Verb Added Behavior 302 ------------- ------------ ---------- ---------- ------------------ 303 Send SEND none SEND defined in RFC 821 304 Send or Mail SOML none SOML defined in RFC 821 305 Send and Mail SAML none SAML defined in RFC 821 306 Expand EXPN none EXPN defined in RFC 821 307 Help HELP none HELP defined in RFC 821 308 Turn TURN none TURN defined in RFC 821 310 which correspond to those SMTP commands which are defined as 311 optional in [5]. (The mandatory SMTP commands, according to 312 [5], are HELO, MAIL, RCPT, DATA, RSET, VRFY, NOOP, and QUIT.) 314 6. MAIL FROM and RCPT TO Parameters 316 It is recognized that several of the extensions planned for 317 SMTP will make use of additional parameters associated with 318 the MAIL FROM and RCPT TO command. The syntax for these 319 commands, again using the ABNF notation of [2] as well as 320 underlying definitions from [1], is: 322 esmtp-cmd ::= inner-esmtp-cmd [SP esmtp-parameters] CR LF 323 esmtp-parameters ::= esmtp-parameter *(SP esmtp-parameter) 324 esmtp-parameter ::= esmtp-keyword ["=" esmtp-value] 325 esmtp-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") 327 ; syntax and values depend on esmtp-keyword 328 esmtp-value ::= 1*") / 335 ("RCPT TO:<" forward-path ">") 337 All esmtp-keyword values must be registered as part of the 338 IANA registration process described above. This definition 339 only provides the framework for future extension; no extended 340 MAIL FROM or RCPT TO parameters are defined by this RFC. 342 6.1. Error responses 344 If the server SMTP does not recognize or cannot implement one 345 or more of the parameters associated with a particular MAIL 346 FROM or RCPT TO command, it will return code 555. 348 If for some reason the server is temporarily unable to 349 accomodate one or more of the parameters associated with a 350 MAIL FROM or RCPT TO command, and if the definition of the 351 specific parameter does not mandate the use of another code, 352 it should return code 455. 354 Errors specific to particular parameters and their values will 355 be specified in the parameter's defining RFC. 357 7. Received: Header Field Annotation 359 SMTP servers are required to add an appropriate Received: 360 field to the headers of all messages they receive. A "with 361 ESMTP" clause should be added to this field when any SMTP 362 service extensions are used. "ESMTP" is hereby added to the 363 list of standard protocol names registered with IANA. 365 8. Usage Examples 367 (1) An interaction of the form: 369 S: 370 C: 371 S: 220 dbc.mtview.ca.us SMTP service ready 372 C: EHLO ymir.claremont.edu 373 S: 250 dbc.mtview.ca.us says hello 374 ... 376 indicates that the server SMTP implements only those 377 SMTP commands which are defined as mandatory in [5]. 379 (2) In contrast, an interaction of the form: 381 S: 382 C: 383 S: 220 dbc.mtview.ca.us SMTP service ready 384 C: EHLO ymir.claremont.edu 385 S: 250-dbc.mtview.ca.us says hello 386 S: 250-EXPN 387 S: 250-HELP 388 S: 250-8BITMIME 389 S: 250-XONE 390 S: 250 XVRB 391 ... 393 indicates that the server SMTP also implements the SMTP 394 EXPN and HELP commands, one standard service extension 395 (8BITMIME), and two nonstandard and unregistered 396 service extensions (XONE and XVRB). 398 (3) Finally, a server that does not support SMTP service 399 extensions would act as follows: 401 S: 402 C: 403 S: 220 dbc.mtview.ca.us SMTP service ready 404 C: EHLO ymir.claremont.edu 405 S: 500 Command not recognized: EHLO 406 ... 408 The 500 response indicates that the server SMTP does 409 not implement the extensions specified here. The 410 client would normally send a HELO command and proceed 411 as specified in RFC 821. See section 4.7 for 412 additional discussion. 414 9. Security Considerations 416 This RFC does not discuss security issues and is not believed 417 to raise any security issues not already endemic in electronic 418 mail and present in fully conforming implementations of RFC- 419 821. It does provide an announcement of server mail 420 capabilities via the response to the EHLO verb. However, all 421 information provided by announcement of any of the initial set 422 of service extensions defined by this RFC can be readily 423 deduced by selective probing of the verbs required to 424 transport and deliver mail. The security implications of 425 service extensions described in other RFCs should be dealt 426 with in those RFCs. 428 10. Acknowledgements 430 This document represents a synthesis of the ideas of many 431 people and reactions to the ideas and proposals of others. 432 Randall Atkinson, Craig Everhart, Risto Kankkunen, and Greg 433 Vaudreuil contributed ideas and text sufficient to be 434 considered co-authors. Other important suggestions, text, or 435 encouragement came from Harald Alvestrand, Jim Conklin, Mark 436 Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per Hedeland, 437 Christian Huitma, Neil Katin, Eliot Lear, Harold A. Miller, 438 Dan Oscarsson, Julian Onions, Rayan Zachariassen, and the 439 contributions of the entire IETF SMTP Working Group. Of 440 course, none of the individuals are necessarily responsible 441 for the combination of ideas represented here. Indeed, in some 442 cases, the response to a particular criticism was to accept 443 the problem identification but to include an entirely 444 different solution from the one originally proposed. 446 11. References 448 [1] J.B. Postel. Simple Mail Transfer Protocol. Request for 449 Comments 821, (August, 1982). 451 [2] D.H. Crocker. Standard for the Format of ARPA Internet 452 Text Messages. Request for Comments 822, (August, 1982). 454 [3] N.S. Borenstein, N. Freed. Multipurpose Internet Mail 455 Extensions. Request for Comments 1521, (September, 456 1993). 458 [4] K. Moore. Representation of Non-ASCII Text in Internet 459 Message Headers. Request for Comments 1522, (September, 460 1993). 462 [5] R.T. Braden. Requirements for Internet Hosts - 463 Application and Support. Request for Comments 1123, 464 (October, 1989). 466 12. Chair, Editor, and Author Addresses 468 John Klensin, WG Chair 469 MCI 470 2100 Reston Parkway 471 Reston, VA 22091 472 tel: +1 703 715-7361 fax: +1 703 715-7436 473 email: klensin@mci.net 475 Ned Freed, Editor 476 Innosoft International, Inc. 477 1050 East Garvey Avenue South 478 West Covina, CA 91790 479 USA 480 tel: +1 818 919 3600 fax: +1 818 919 3614 481 email: ned@innosoft.com 483 Marshall T. Rose 484 Dover Beach Consulting, Inc. 485 420 Whisman Court 486 Moutain View, CA 94043-2186 487 USA 488 tel: +1 415 968 1052 fax: +1 415 968 2510 489 email: mrose@dbc.mtview.ca.us 491 Einar A. Stefferud 492 Network Management Associates, Inc. 493 17301 Drey Lane 494 Huntington Beach, CA, 92647-5615 495 USA 496 tel: +1 714 842 3711 fax: +1 714 848 2091 497 email: stef@nma.com 499 Dave Crocker 500 Brandenburg Consulting 501 675 Spruce Dr. 502 Sunnyvale, CA 94086 USA 503 USA 504 tel: +1 408 246 8253 fax: +1 408 249 6205 505 email: dcrocker@mordor.stanford.edu