idnits 2.17.1 draft-ietf-smtpext-extensions-04.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-24) 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 (May 6, 1995) is 10581 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 May 6, 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 This specification is intended to extend RFC 821 without 125 impacting existing services in any way. The minor changes 126 needed are enumerated below. 128 4.1.1. First command 130 RFC 821 states that the first command in an SMTP session must 131 be the HELO command. This requirement is hereby amended to 132 allow a session to start with either EHLO or HELO. 134 4.1.2. Maximum command line length 136 This specification extends the SMTP MAIL FROM and RCPT TO to 137 allow additional parameters and parameter values. It is 138 possible that the MAIL FROM and RCPT TO lines that result will 139 exceed the 512 character limit on command line length imposed 140 by RFC 821. This limit is hereby amended to only apply to 141 command lines without any parameters. Each specification that 142 defines new MAIL FROM or RCPT TO parameters must also specify 143 maximum parameter value lengths for each parameter so that 144 implementors of some set of extensions know how much buffer 145 space must be allocated. The maximum command length that must 146 be supported by an SMTP implementation with extensions is 512 147 plus the sum of all the maximum parameter lengths for all the 148 extensions supported. 150 4.2. Command syntax 152 The syntax for this command, using the ABNF notation of [2], 153 is: 155 ehlo-cmd ::= "EHLO" SP domain CR LF 157 If successful, the server SMTP responds with code 250. On 158 failure, the server SMTP responds with code 550. On error, the 159 server SMTP responds with one of codes 500, 501, 502, 504, or 160 421. 162 This command is issued instead of the HELO command, and may be 163 issued at any time that a HELO command would be appropriate. 164 That is, if the EHLO command is issued, and a successful 165 response is returned, then a subsequent HELO or EHLO command 166 will result in the server SMTP replying with code 503. A 167 client SMTP must not cache any information returned if the 168 EHLO command succeeds. That is, a client SMTP must issue the 169 EHLO command at the start of each SMTP session if information 170 about extended facilities is needed. 172 4.3. Successful response 174 If the server SMTP implements and is able to perform the EHLO 175 command, it will return code 250. This indicates that both 176 the server and client SMTP are in the initial state, that is, 177 there is no transaction in progress and all state tables and 178 buffers are cleared. 180 Normally, this response will be a multiline reply. Each line 181 of the response contains a keyword and, optionally, one or 182 more parameters. The syntax for a positive response, using the 183 ABNF notation of [2], is: 185 ehlo-ok-rsp ::= "250" domain [ SP greeting ] CR LF 186 / ( "250-" domain [ SP greeting ] CR LF 187 *( "250-" ehlo-line CR LF ) 188 "250" SP ehlo-line CR LF ) 190 ; the usual HELO chit-chat 191 greeting ::= 1* 193 ehlo-line ::= ehlo-keyword *( SP ehlo-param ) 195 ehlo-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") 197 ; syntax and values depend on ehlo-keyword 198 ehlo-param ::= 1* 202 ALPHA ::= 205 DIGIT ::= 208 CR ::= 210 LF ::= 212 SP ::= 215 Although EHLO keywords may be specified in upper, lower, or 216 mixed case, they must always be recognized and processed in a 217 case-insensitive manner. This is simply an extension of 218 practices begun in RFC 821. 220 The IANA maintains a registry of SMTP service extensions. 221 Associated with each such extension is a corresponding EHLO 222 keyword value. Each service extension registered with the IANA 223 must be defined in an RFC. Such RFCs must either be on the 224 standards-track or must define an IESG-approved experimental 225 protocol. The definition must include: 227 (1) the textual name of the SMTP service extension; 229 (2) the EHLO keyword value associated with the extension; 231 (3) the syntax and possible values of parameters associated 232 with the EHLO keyword value; 234 (4) any additional SMTP verbs associated with the extension 235 (additional verbs will usually be, but are not required 236 to be, the same as the EHLO keyword value); 238 (5) any new parameters the extension associates with the 239 MAIL FROM or RCPT TO verbs; 241 (6) how support for the extension affects the behavior of a 242 server and client SMTP; and, 244 (7) the increment by which the extension is increasing the 245 maximum length of the commands MAIL FROM, RCPT TO, or 246 both, over that specified in RFC 821. 248 In addition, any EHLO keyword value that starts with an upper 249 or lower case "X" refers to a local SMTP service extension, 250 which is used through bilateral, rather than standardized, 251 agreement. Keywords beginning with "X" may not be used in a 252 registered service extension. 254 Any keyword values presented in the EHLO response that do not 255 begin with "X" must correspond to a standard, standards-track, 256 or IESG-approved experimental SMTP service extension 257 registered with IANA. A conforming server must not offer non 258 "X" prefixed keyword values that are not described in a 259 registered extension. 261 Additional verbs are bound by the same rules as EHLO keywords; 262 specifically, verbs begining with "X" are local extensions 263 that may not be registered or standardized and verbs not 264 beginning with "X" must always be registered. 266 4.4. Failure response 268 If for some reason the server SMTP is unable to list the 269 service extensions it supports, it will return code 554. 271 In the case of a failure response, the client SMTP should 272 issue either the HELO or QUIT command. 274 4.5. Error responses from extended servers 276 If the server SMTP recognizes the EHLO command, but the 277 command argument is unacceptable, it will return code 501. 279 If the server SMTP recognizes, but does not implement, the 280 EHLO command, it will return code 502. 282 If the server SMTP determines that the SMTP service is no 283 longer available (e.g., due to imminent system shutdown), it 284 will return code 421. 286 In the case of any error response, the client SMTP should 287 issue either the HELO or QUIT command. 289 4.6. Responses from servers without extensions 291 A server SMTP that conforms to RFC 821 but does not support 292 the extensions specified here will not recognize the EHLO 293 command and will consequently return code 500, as specified in 294 RFC 821. The server SMTP should stay in the same state after 295 returning this code (see section 4.1.1 of RFC 821). The 296 client SMTP may then issue either a HELO or a QUIT command. 298 4.7. Responses from improperly implemented servers 300 Some SMTP servers are known to disconnect the SMTP 301 transmission channel upon receipt of the EHLO command. The 302 disconnect can occur immediately or after sending a response. 303 Such behavior violates section 4.1.1 of RFC 821, which 304 explicitly states that disconnection should only occur after a 305 QUIT command is issued. 307 Nevertheless, in order to achieve maxmimum interoperablity it 308 is suggested that extended SMTP clients using EHLO be coded to 309 check for server connection closure after EHLO is sent, either 310 before or after returning a reply. If this happens the client 311 must decide if the operation can be successfully completed 312 without using any SMTP extensions. If it can a new connection 313 can be opened and the HELO command can be used. 315 Other improperly-implemented servers will not accept a HELO 316 command after EHLO has been sent and rejected. In some cases, 317 this problem can be worked around by sending a RSET after the 318 failure response to EHLO, then sending the HELO. Clients that 319 do this should be aware that many implementations will return 320 a failure code (e.g., 503 Bad sequence of commands) in 321 response to the RSET. This code can be safely ignored. 323 5. Initial IANA Registry 325 The IANA's initial registry of SMTP service extensions 326 consists of these entries: 328 Service Ext EHLO Keyword Parameters Verb Added Behavior 329 ------------- ------------ ---------- ---------- ------------------ 330 Send SEND none SEND defined in RFC 821 331 Send or Mail SOML none SOML defined in RFC 821 332 Send and Mail SAML none SAML defined in RFC 821 333 Expand EXPN none EXPN defined in RFC 821 334 Help HELP none HELP defined in RFC 821 335 Turn TURN none TURN defined in RFC 821 337 which correspond to those SMTP commands which are defined as 338 optional in [5]. (The mandatory SMTP commands, according to 339 [5], are HELO, MAIL, RCPT, DATA, RSET, VRFY, NOOP, and QUIT.) 340 6. MAIL FROM and RCPT TO Parameters 342 It is recognized that several of the extensions planned for 343 SMTP will make use of additional parameters associated with 344 the MAIL FROM and RCPT TO command. The syntax for these 345 commands, again using the ABNF notation of [2] as well as 346 underlying definitions from [1], is: 348 esmtp-cmd ::= inner-esmtp-cmd [SP esmtp-parameters] CR LF 349 esmtp-parameters ::= esmtp-parameter *(SP esmtp-parameter) 350 esmtp-parameter ::= esmtp-keyword ["=" esmtp-value] 351 esmtp-keyword ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") 353 ; syntax and values depend on esmtp-keyword 354 esmtp-value ::= 1* 396 C: 397 S: 220 dbc.mtview.ca.us SMTP service ready 398 C: EHLO ymir.claremont.edu 399 S: 250 dbc.mtview.ca.us says hello 400 ... 402 indicates that the server SMTP implements only those 403 SMTP commands which are defined as mandatory in [5]. 405 (2) In contrast, an interaction of the form: 407 S: 408 C: 409 S: 220 dbc.mtview.ca.us SMTP service ready 410 C: EHLO ymir.claremont.edu 411 S: 250-dbc.mtview.ca.us says hello 412 S: 250-EXPN 413 S: 250-HELP 414 S: 250-8BITMIME 415 S: 250-XONE 416 S: 250 XVRB 417 ... 419 indicates that the server SMTP also implements the SMTP 420 EXPN and HELP commands, one standard service extension 421 (8BITMIME), and two nonstandard and unregistered 422 service extensions (XONE and XVRB). 424 (3) Finally, a server that does not support SMTP service 425 extensions would act as follows: 427 S: 428 C: 429 S: 220 dbc.mtview.ca.us SMTP service ready 430 C: EHLO ymir.claremont.edu 431 S: 500 Command not recognized: EHLO 432 ... 434 The 500 response indicates that the server SMTP does 435 not implement the extensions specified here. The 436 client would normally send a HELO command and proceed 437 as specified in RFC 821. See section 4.7 for 438 additional discussion. 440 9. Security Considerations 442 This RFC does not discuss security issues and is not believed 443 to raise any security issues not already endemic in electronic 444 mail and present in fully conforming implementations of RFC- 445 821. It does provide an announcement of server mail 446 capabilities via the response to the EHLO verb. However, all 447 information provided by announcement of any of the initial set 448 of service extensions defined by this RFC can be readily 449 deduced by selective probing of the verbs required to 450 transport and deliver mail. The security implications of 451 service extensions described in other RFCs should be dealt 452 with in those RFCs. 454 10. Acknowledgements 456 This document represents a synthesis of the ideas of many 457 people and reactions to the ideas and proposals of others. 458 Randall Atkinson, Craig Everhart, Risto Kankkunen, and Greg 459 Vaudreuil contributed ideas and text sufficient to be 460 considered co-authors. Other important suggestions, text, or 461 encouragement came from Harald Alvestrand, Jim Conklin, Mark 462 Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per Hedeland, 463 Christian Huitma, Neil Katin, Eliot Lear, Harold A. Miller, 464 Keith Moore, John Myers, Dan Oscarsson, Julian Onions, Rayan 465 Zachariassen, and the contributions of the entire IETF SMTP 466 Working Group. Of course, none of the individuals are 467 necessarily responsible for the combination of ideas 468 represented here. Indeed, in some cases, the response to a 469 particular criticism was to accept the problem identification 470 but to include an entirely different solution from the one 471 originally proposed. 473 11. References 475 [1] J.B. Postel. Simple Mail Transfer Protocol. Request for 476 Comments 821, (August, 1982). 478 [2] D.H. Crocker. Standard for the Format of ARPA Internet 479 Text Messages. Request for Comments 822, (August, 1982). 481 [3] N.S. Borenstein, N. Freed. Multipurpose Internet Mail 482 Extensions. Request for Comments 1521, (September, 483 1993). 485 [4] K. Moore. Representation of Non-ASCII Text in Internet 486 Message Headers. Request for Comments 1522, (September, 487 1993). 489 [5] R.T. Braden. Requirements for Internet Hosts - 490 Application and Support. Request for Comments 1123, 491 (October, 1989). 493 12. Chair, Editor, and Author Addresses 495 John Klensin, WG Chair 496 MCI 497 2100 Reston Parkway 498 Reston, VA 22091 499 tel: +1 703 715-7361 fax: +1 703 715-7436 500 email: klensin@mci.net 502 Ned Freed, Editor 503 Innosoft International, Inc. 504 1050 East Garvey Avenue South 505 West Covina, CA 91790 506 USA 507 tel: +1 818 919 3600 fax: +1 818 919 3614 508 email: ned@innosoft.com 510 Marshall T. Rose 511 Dover Beach Consulting, Inc. 512 420 Whisman Court 513 Moutain View, CA 94043-2186 514 USA 515 tel: +1 415 968 1052 fax: +1 415 968 2510 516 email: mrose@dbc.mtview.ca.us 518 Einar A. Stefferud 519 Network Management Associates, Inc. 520 17301 Drey Lane 521 Huntington Beach, CA, 92647-5615 522 USA 523 tel: +1 714 842 3711 fax: +1 714 848 2091 524 email: stef@nma.com 526 Dave Crocker 527 Brandenburg Consulting 528 675 Spruce Dr. 529 Sunnyvale, CA 94086 USA 530 USA 531 tel: +1 408 246 8253 fax: +1 408 249 6205 532 email: dcrocker@mordor.stanford.edu