idnits 2.17.1 draft-ietf-smtpext-8bittransport-06.txt: 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-25) 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. ** 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. ** Expected the document's filename to be given on the first page, but didn't find any ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1510 lines 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 are 14 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 332: '...aditional sense. An implemention MUST...' RFC 2119 keyword, line 351: '...indicate that the sender MUST NOT send...' RFC 2119 keyword, line 447: '... it. EVFY without an argument MUST be...' RFC 2119 keyword, line 563: '... supporting EHLO MUST NOT return "502 ...' RFC 2119 keyword, line 567: '...s not apear in RFC-821 MUST NOT return...' (24 more instances...) == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (July 15, 1992) is 11607 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) == Missing Reference: 'RFC1341' is mentioned on line 66, but not defined ** Obsolete undefined reference: RFC 1341 (Obsoleted by RFC 1521) == Missing Reference: 'US' is mentioned on line 67, but not defined == Missing Reference: 'Temporary' is mentioned on line 1548, but not defined == Unused Reference: 'Gianone' is defined on line 1385, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Gianone' ** Obsolete normative reference: RFC 821 (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1341 (ref. 'RFC1342') (Obsoleted by RFC 1521) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO646' Summary: 16 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. C. Klensin 2 INTERNET DRAFT July 15, 1992 3 Updates: RFC-821 Expires: January 27, 1993 5 SMTP Extensions for Transport of Enhanced Messages 7 Abstract 9 A series of extensions and clarifications are provided for the 10 Simple Mail Transfer Protocol specified by RFC-821. In combination, 11 they provide for the transport of "8 bit mail", i.e., data 12 characters with all bits of the octets used for information, for 13 more robust and efficient handling of large messages, and for an 14 improved foundation for any future extensions to SMTP. 16 Status of this Memo 17 This document is an Internet Draft. Internet Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its Areas, 19 and its Working Groups. Note that other groups may also distribute 20 working documents as Internet Drafts). 22 Internet Drafts are draft documents valid for a maximum of six 23 months. Internet Drafts may be updated, replaced, or obsoleted 24 by other documents at any time. It is not appropriate to use 25 Internet Drafts as reference material or to cite them other than 26 as a "working draft" or "work in progress." 28 Please check the I-D abstract listing contained in each Internet Draft 29 directory to learn the current status of this or any other Internet 30 Draft. 32 This document is a working draft as part of the development of an 33 extension to the SMTP protocol. A subsequent version will be 34 submitted to the RFC editor as a proposed standard. Distribution 35 is unlimited. Comments are solicited and should be sent to the 36 editor at Klensin@MIT.EDU or, preferably, by joining in discussions 37 on the ietf-smtp mailing list (subscription requests to 38 ietf-smtp-request@dimacs.rutgers.edu, postings to 39 ietf-smtp@dimacs.rutgers.edu). 41 1. Introduction and Background 43 1.1 Introduction 45 RFC-821 [RFC821] defines a protocol, SMTP, to transfer mail reliably 46 and efficiently. It is largely independent of the transmission 47 subsystem used. It requires only a reliable ordered data stream, of at 48 least 7-bit units, that consists of "lines" and "characters". It also 49 makes some implied assumptions about end-to-end virtual circuit 50 connections as the primary model for transporting and delivering mail. 52 SMTP, as described in RFC-821, is restricted to the transport of data in 53 7-bit ASCII [ANSI-X3.4] encoding. The term "ASCII", as used in this 54 document, refers to ANSI X3.4, and not to any national language 55 variations on ISO 646; the use of "US" with "ASCII" is merely to add 56 additional emphasis when that appears useful. Strictly speaking, 57 incorporation of any non-ASCII character encoding, whether 7 or 8 bits, 58 or the assumption of a special interpretation for any control character 59 other than ASCII, CR, and LF is an extension from RFC-821 that may not 60 be compatible in subtle ways with existing conforming implementations. 61 Such extensions require either changes to RFC-821 itself, or prior 62 agreement among all parties and hosts which will transport or handle the 63 mail. A strict reading of RFC-821 would permit the receiver of a 64 message to assume that it contained only ASCII characters. 66 MIME [RFC1341], Multimedia Internet Mail Extensions, provides for 67 identifying the use and encoding of character sets other than [US] 68 ASCII within a structured message body, using extended headers. Because 69 MIME does not require an 8-bit transport mechanism, its use 70 with 7-bit transport is likely to provide better interoperability than 71 the use of an 8-bit transport mechanism in situations where mail must 72 be passed through one or more unknown mail relays, gateways, or 73 exploders between the sender and the receiver. 75 At the same time, most electronic mail messages do not pass through such 76 mechanisms, but are simple textual messages sent within a small, "local" 77 community of users. Within such local communities, sending characters 78 represented using other than 7-bit coding with a transport mechanism 79 that logically reflects the length of the character codes, without 80 additional encoding, provides considerable simplification. Such a 81 system has been much in demand for 8-bit characters. The consequences, 82 within a community that has decided to use this protocol extension, of 83 discovering that a receiving host will not accept transport of 84 extended-length characters, are also not severe, since that problem will 85 presumably rarely arise. Nonetheless, this document provides a 86 framework for conversion of enhanced transport forms into the line- and 87 character-oriented 7-bit form permitted by the original SMTP and 88 outlines mechanisms by which the acceptability of 8-bit transport to a 89 given server can be inferred without first opening a mail connection. 91 In addition to the issues of 8-bit transport and general extensibility, 92 a number of trends, not least of which is the introduction of the 93 extended "multipart/multimedia" design of MIME, have contributed to 94 steady increases in the average and maximum sizes of messages that 95 people wish to transport over electronic mail facilities. When hosts 96 imposed limits on mail message sizes in the early days of the ARPANET, 97 limits in the ranges of four, or even one, kilocharacters, were 98 considered reasonable. The applications-level host requirements RFC 99 [RFC1123] specified 64K characters as the minimum size at which it was 100 reasonable to reject mail messages for excessive length. 102 Under RFC-821, there is no mechanism for rejecting a message as being 103 too long without actually having that message transmitted. There is 104 also no provision for checkpointing or otherwise salvaging the portion 105 of the message transmitted before the size limit of the server is 106 encountered. If all hosts accept messages of at least 64Kb, 107 experimenting with longer limits may waste considerable bandwidth. 108 This may be a major consideration on slow or expensive links. This 109 document provides a model for determining whether a large message will 110 be accepted without actually transmitting most of it. 112 1.2. Background, History, and Context of this Draft 114 The strongest evidence for the importance of 8-bit transport is that 115 many vendors and implementors already support it over the usual SMTP 116 channels and many report that they have done so in response to intense 117 customer pressure. Since the mechanisms that have been chosen have not 118 been standardized, messages containing octets with the high bit set may 119 "escape" the local environment. Difficulties of varying degrees of 120 severity may arise when they do so, including information loss as 121 characters are "bit stripped", which may be considered a severe 122 violation of user expectations about reliable mail transport and 123 delivery. 125 This document has two primary purposes. One is to specify a clear 126 extension model for SMTP, so potential problems with further extensions 127 can be avoided. The second, and the original goal of the working 128 group, was to provide for 8-bit character-oriented transport via SMTP 129 when that is deemed necessary. A critical secondary purpose is to 130 standardize mechanisms and clarify procedures in ways that prevent 131 destructive "escape" of improperly-identified 8-bit characters and 132 potentially even more severe problems which could otherwise result from 133 the transport of characters that comprise multiple octets or of data 134 not organized into character form. 136 In other words, transport of 8-bit characters is occurring, will 137 continue to occur, and is perceived of as desirable under many 138 circumstances. For it to coexist with older, more restricted, 139 implementations, requires that it be used in a coordinated way and only 140 when both parties are able and willing to use it. That, in turn, 141 requires a clear mechanism as to how coordination will occur and 142 agreement be verified. This protocol extension provides that 143 mechanism. 145 2. Notation and terminology 147 There are several situations in this document in which the bit pattern 148 associated with the code for a character is, in the event of possible 149 ambiguity, more significant than the character itself. In those 150 situations, the bit pattern is cited (in hexadecimal notation) as the 151 value of the octet, and the referenced ASCII characters are then 152 indicated in parentheses. When characters, or character names, are 153 mentioned, they are to be construed strictly in accord with ASCII, that 154 is, from American National Standard ANSI X3.4-1986. However, for the 155 purposes of this specification, the "international reference version" 156 table in ISO 646 [ISO646] and that in ASCII are identical. 158 <> Discussion: ISO 646 has traditionally contained two character 159 tables. One is called the "International Reference Version" 160 (often referred to as ISO646/IRV) and has been identical to 161 ASCII except for the substitution of "universal currency 162 symbol" for "dollar sign". The other is called the "Basic 163 Version" (often referred to as ISO646/BV). National Language 164 Variants on ISO 646 (often referred to as ISO646/NLV-language) 165 are derived from ISO646/BV by the substitution of national 166 characters into positions that ISO646/BV designates as reserved 167 for this purpose. So-called "invariant ISO 646" is a large 168 subset of the non-reserved characters in ISO646/BV. 170 Except in a few situations where the distinction is important, the 171 terms "8-bit characters", "8-bit text", and "8-bit transport" are used 172 interchangably to refer to messages that might contain octets with the 173 high bit set to 1. As above, when the distinction is important, the 174 term "octet" is used rather than "character" or "byte". While it 175 provides a framework that could be extended to the logical transport of 176 characters longer than 8 bits, this document does not specify or permit 177 such transport. 179 <> Discussion: Character codings in which individual characters occupy 180 more than one octet (e.g., 16- or 32-bit character codes), may pose 181 special problems for SMTP-style transport that 8-bit characters do 182 not. In particular, with some possible codings, some of the octets 183 of some characters might have the same bit patterns as, e.g., CR 184 LF. Such character sets can always be handled by an encoding above 185 the mail transport level, so that only conventional 7-bit or 8-bit 186 characters are actually seen by the mail transport mechanisms. 187 However, if they are to be transported in "native" form, transport 188 extensions beyond those specified here will be required to insure 189 the unambiguous recognizability of CR, LF, and "." or to avoid the 190 necessity of recognizing those characters. 192 For many years, we have used the term "gateway" in discussions of mail 193 to refer to something that operates at the applications level, 194 translating between different mail protocols or environments. Such 195 gateways are quite distinct from gateways at the IP and routing level. 196 The term "mail gateway" should perhaps be used consistently to avoid any 197 possible confusion, but that confusion rarely occurs. A similar 198 situation applies when we discuss "transport" in a mail context, 199 referring to "mail transport" and not the underlying transport layer. 200 With RFC-821, we have had a "mail transport" mechanism that logically 201 deals only with 7 bit characters, even though most of the underlying 202 transport layers deal in octets. This document extends the logical mail 203 transport environment to full octet width, again largely independent of 204 the underlying mechanisms. "Transport" in this document should always 205 be read as "mail transport" and not in terms of how the network carries 206 octets or packets. 208 This document uses the terms "byte" and "kilobytes" in several contexts. 209 "Byte", as used here, is taken to be an 8-bit quantity, not one of 210 variable size. In particular, "kilobyte" is intended to be construed as 211 1024 octets, not as 1024 "characters". Similarly, uses of "length" 212 terminology in this document is always associated with bit and octet 213 storage units and not with the lengths of strings in character units. 215 The terms "client" and "sender" are used together or interchangably to 216 indicate the source of a particular mail transaction and "server" is 217 used to describe the target. This usage is consistent with that in 218 RFC-821. 220 This document uses the term "mail transaction" to indicate a use of 221 SMTP, with or without the extensions specified here, with the intent of 222 sending mail. Mail transactions always start with a HELO or EHLO 223 command with the intent of following it with a FROM command and one or 224 more RCPT verbs. Use of VRFY, EXPN, or the new EHLO, SIZE, or EVFY 225 commands without prior FROM commands in the SMTP session does not 226 constitute a mail transaction. A mail transaction ends when a QUIT or 227 RSET is sent. It may also be considered to end when the CRLF.CRLF that 228 terminates the DATA command is received but, in that case, a second mail 229 transaction in the same [connection] session will normally start with a 230 FROM command rather than HELO or EHLO. 232 <> Discussion: From the standpoint of the sender/client, a mail 233 transaction is a matter of intent. From the standpoint of the 234 server, the state is "not a mail transaction" until a FROM 235 command is received. 237 This protocol provides the framework for several features that require 238 specification in additional RFCs before they can be validly used. For 239 those features, which are clearly identified, this document provides 240 only syntax and, in most cases, an overview of the characteristics that 241 must be defined in feature-specific supplemental RFCs. The major 242 feature for which neither this document nor RFC-821 provide is a 243 specification for the transport of information that is not structured 244 into "characters" and "lines". However, this document provides a 245 framework around which such a definition might be developed in the 246 future if that were desired. Language in this document that implies 247 forms of enhanced transport other than that specified with the EMAL verb 248 has been retained to allow for compatible extension for additional 249 features. 251 Finally, this document contains many subsections that are identified 252 with the terms "discussion", "implementation note", or "example". 253 While not strictly part of the specification, these subsections 254 provide context for the features, guidance for implementors, and other 255 "folklore" about the intent of the working group that produced the 256 specification to aid understanding and the generation of interoperable 257 implementations. 259 3. Organization and summary 261 This document consequently contains ten major components, which 262 follow: 264 (i) Definition of a new SMTP verb, EMAL FROM, as an alternative to 265 MAIL FROM where 8 bit transport is desired. 267 (ii) Provision of a framework for additional transport type extensions 268 via the addition of additional "FROM" verbs. 270 (iii) Definition of a new SMTP verb, EVFY, which can be used to 271 determine whether an enhanced transport request is likely to be 272 accepted for a particular address. 274 (iv) Definition of a new SMTP verb, EHLO, which can be used by 275 a client as an alternative to HELO. Either HELO or EHLO may be 276 used when the client intends to use enhanced mail facilities, but 277 the server response to EHLO provides the client with a structured 278 listing of the mail features supported by the server. 280 (v) Definition of a new SMTP verb, SIZE, which can be used by the 281 client to inform the server of the approximate size of the data 282 to be transferred. The semantics of this verb and its 283 interaction with maximum message size limitations are also 284 specified. 286 (vi) A discussion of the interaction of enhanced transport with message 287 formats (i.e., RFC-822 material) 289 (vii) A description of enhancements to "trace" header fields to permit 290 more efficient isolation of problems in today's more complex 291 world. 293 (viii) Clarification, and additional specification, of the RFC-821 294 description of the application and semantics of the RSET command. 296 (ix) A discussion of failure and error conditions when server and 297 client conform to this protocol. 299 (x) A discussion of the handling of failure conditions in general with 300 specific discussion of the alternatives in the "unverified eight 301 bit encountered" error. This problem might be encountered when 302 the server conforms to this specification but the client does not. 304 Most of these sections impose requirements which are mandatory if the 305 protocol specified here is implemented. 307 Under some circumstances, such as the management of large mailing lists 308 or relays with large aggregate message traffic, the costs of opening a 309 mail connection and determining whether the destination host will accept 310 the enhanced features specified here may be considered excessive. 311 Additional specifications will be needed to provide methods for making 312 that determination using the domain name system or other tables or 313 caching methods. This protocol does not require that those facilities 314 be used, nor does the use of those facilities change the actual mail 315 transport command sequence specified here. Advice as to when 316 supplemental facilities are permitted or required to be used may appear 317 in future applicability statements. 319 4. The EMAL FROM verb 321 The SMTP protocol, as specified in RFC-821, is extended to permit the 322 use of a new verb that supplements the "handling" components of what we 323 shall refer to as the "FROM" verbs. In other words, this specification 324 adds "EMAL FROM", as defined below, to the "MAIL FROM", "SEND FROM", 325 "SOML FROM", and "SAML FROM" forms specified in RFC-821. This addition 326 also provides an explicit extension model for future transport 327 variations as needed. 329 If this new verb is to be taken as an acronym, "E" should be read as 330 "enhanced" or as "eight". 332 This is an extension in the traditional sense. An implemention MUST 333 NOT be so constructed that it is possible for it to accept EMAL FROM in 334 a context in which it would not accept MAIL FROM. 336 <> Discussion: Mailing list discussion seems to indicate that this 337 should be explicitly stated. It is a statement for which 338 conformance is easily tested "on the wire". 340 As specified in RFC-821, DATA is treated as introducing a stream of 341 ASCII (and therefore 7-bit) characters, divided into lines that are 342 delimited by the ASCII control characters CR followed by LF, with 343 potential restrictions on line lengths, and terminated with the 344 sequence "CR LF . CR LF". 346 If 8 bit transport is desired, the MAIL FROM verb is replaced by EMAL 347 FROM. If the receiver does not recognize that verb (which will be the 348 case with all SMTP servers that conform to RFC-821 alone), or will not 349 accept enhanced mail features, it gives a fatal negative reply (500 if 350 the verb is not recognized, 556 if the verb is recognized but not 351 accepted). Such a reply would indicate that the sender MUST NOT send 352 octets with the high bit turned on. Otherwise the receiver sends the 353 positive 250 reply identical to that normally returned in response to 354 MAIL FROM. The sender can then proceed with the rest of the mail 355 transaction, sending a message containing 8-bit text after the DATA 356 verb. 358 All SMTP command verbs, including the enhanced FROM verbs, are written 359 in ASCII characters. Nothing in this specification provides for any 360 character or coding other than those of ASCII to be used in SMTP 361 transactions ("the envelope"). It does provide for such characters in 362 the message body initiated by the DATA verb and terminated with CR LF . 363 CR LF. The format of such messages are as specified in other RFCs, 364 e.g., RFC-822 [RFC822] and MIME [RFC1342]. 366 5. Further extensions to SMTP 368 5.1 Provisions for adding additional FROM forms. 370 Specifications may be written to add additional FROM forms which 371 should then be registered with the Internet Assigned Number Authority 372 (IANA) in accord with the provisions of section 5.3. 374 5.2 Provisions for other new verbs 376 The general approach used in this specification assumes that further 377 extensions to support different forms of transport that preserve a 378 character-and-line-oriented model (e.g., direct transport of character 379 sets that must be handled in special ways due to multiple-octet 380 encodings or transport-level data compression) will be handled by 381 adding additional forms of the FROM command, as discussed above. 382 Other transport arrangments (such as data "streaming" or transport of 383 true binary data), if introduced, may require additional or variant 384 commands and verbs. Such new verbs may be registered with IANA, as 385 described below. In addition, those that are intended for general use 386 should be documented in RFCs and submitted for standardization. 388 In order to permit experimentation, verbs starting with the character 389 "X" are reserved for use between consenting systems by mutual 390 agreement. Any command without a rigorous and public definition must 391 be given a name starting in "X", and public (registered) values shall 392 never begin with "X". 394 <> Discussion: All commands defined by RFC-821 and by this 395 specification have precisely four characters in their first (or 396 only) token. It is likely that some mail systems depend on this 397 property, which should be preserved unless there is reason for 398 doing otherwise. 400 5.3 Specifications and Registration Procedures 402 Even when new features or verbs are not intended for general use, it 403 is undesireable that two different sets of systems use the same verb 404 in different ways. The introduction of the EHLO functionality (see 405 section 7), which permits a client to interrogate a server about the 406 features supported by the latter, may exacerbate the potential 407 problems of identical verbs being used for different purposes, since a 408 client may discover a server-supported feature when no prior agreement 409 exists between the two hosts. To avoid these problems, and to keep 410 the specification of EHLO useful, unambiguous, and meaningful, any 411 verbs used in SMTP processing must either be registered or must be 412 explicitly private. 414 Registration must be with the Internet Assigned Numbers Authority 415 (IANA) and may occur in either of the following forms: 417 (i) Commands intended for general use: These commands should be 418 developed and documented using IETF standards-track procedures. The 419 RFCs or working drafts leading to them are expected to specify any and 420 all special treatment that these new verbs imply for transport. Such 421 documents must also specify any deviations or exceptions to the rules 422 of section 9.1. If the transport extensions being proposed have 423 implications for conversions at gateways, those conversions must be 424 discussed and, preferably, completely specified. The verbs should be 425 registered when serious testing begins, but not later than approval of 426 the extension as a proposed standard. 428 (ii) Commands intended for use in special communities: the names of 429 these commands should be registered, along with a short description of 430 applicability, before the commands are placed into use. 432 In either case, verbs must be registered before any server announces 433 them in the response to an EHLO inquiry. 435 Completely private verbs -- those starting in "X" as discussed above 436 -- do not require registration and will not be registered. Except 437 for short-term experimentation, use of such verbs is discouraged. 439 6. EVFY command 441 A new command verb, EVFY is defined, corresponding to VRFY (as defined 442 in RFC-821) and with the same argument, but requesting information as to 443 whether the address is acceptable for 8 bit transport. EVFY has the 444 same reply codes as VRFY, but the successful 250 or 251 codes are 445 returned only if enhanced transport will be accepted for that address. 446 Code 556 must be returned if the address is acceptable, but enhanced 447 transport will not be accepted for it. EVFY without an argument MUST be 448 treated as a syntax error. 450 Circumstances in which the address appears to be valid but is remote 451 or cannot be exactly verified for other reasons, should be treated as 452 specified for VRFY in RFC-1123 [RFC1123]. 454 7. EHLO command 456 Clients may be able to act more intelligently if they can determine the 457 characteristics and capabilities of servers to which they expect to send 458 messages. It is desirable for a client to be able to determine which of 459 the SMTP extensions defined herein are supported on a particular host. 460 Similarly, a client might wish to be able to determine whether other 461 optional features of RFC-821 such as SEND, SOML, or SAML are provided by 462 a given server. 464 <> Discussion: Under some circumstances, it may be desirable to 465 make some of these determinations in an out-of-band way. This 466 protocol does not prohibit such mechanisms and anticipates at 467 least one of them. See the discussion at the end of section 3 468 above. 470 A new command verb, EHLO, is defined. In order to minimize the number 471 of commands issued, if the special capabilities of EHLO are needed, it 472 is used as an alternative to "HELO", not as a separate command. If a 473 server implementation provides support for any of the features 474 specified in this document or subsequently defined as specified in 475 section 5, it must accept and process EHLO. The argument syntax for 476 EHLO is identical to that for HELO, i.e., the primary fully-qualified 477 domain name of the sender-SMTP. 479 Except for verbs starting in "X" (see the discussion in section 5), 480 all verbs supported in a particular server must be listed. In 481 addition, LIMIT information must be provided as specified in section 482 7.3. Other than verbs starting in "X", no verb may be listed that is 483 not specified in RFC-821 or this document, or registered as provided 484 for in section 5. Verbs starting in "X" may be listed or not 485 depending on the particular needs of the server or private agreements 486 between server and client. 488 The term "supported", as used above, implies that the server provides 489 meaningful support for the capability implied by the command, rather 490 than just recognizing the verb. For example, SEND FROM is not 491 "supported" if the command would be refused with all possible 492 predicates or if there are no possible addresses (in RCPT TO) that 493 will be accepted. The response is also expected to reflect actual 494 system configuration and operation, e.g., if a server implementation 495 provides support for VRFY, but the command is disabled for security 496 reasons as provided for in RFC-1123, EHLO should not list that verb. 498 <> Discussion: If VRFY is meaningfully supported--i.e., the server 499 expects to actually confirm accessibility of addresses--then it 500 should be listed even if some (or under some circumstances most or 501 all) addresses that the server supports cannot be confirmed in 502 real time. 504 The information provided by EHLO will usually be static for most 505 servers (at least once they are configured for a particular site). 506 However, since it might change from session to session in some cases, 507 clients should, in general, not cache the information between mail 508 connections. 510 <> Discussion: There are several SMTP servers in use on the Internet 511 that support and use verbs that are not specified in this document 512 or in RFC-821. Since RFC-821 takes no position on command 513 extensions, these may be conforming implementations. This 514 specification does take such a position (above and in section 5) 515 and therefore has much stronger conformance implications than 516 RFC-821. The intent with the EHLO verb and other enhanced 517 capabilities is not to invalidate any existing RFC-821 518 implementations that are valid in the absence of this 519 specification. It is, however, intended to provide an "all or 520 nothing" approach: if enhanced capabilities are supported (e.g., 521 EHLO is accepted at all) then all of the stricter requirements of 522 this specification apply. In particular, if these enhanced 523 capabilities are supported, then any (non "X") verbs that do not 524 appear either here or in RFC-821 must be registered with IANA and 525 reported by EHLO. 527 7.1 Server considerations 529 If a EHLO command is received the server must return a formatted 530 message that consists of a multiple-line 255 reply, using the 531 continuation convention specified in RFC-821. The first line of this 532 response will be the the primary fully-qualified domain name of the 533 receiver-SMTP. Subsequent lines will consist of a verb supported by 534 the server and a special LIMIT indicator with two values (see section 535 7.3, below). All verbs supported by the server must be included in 536 the reply, including those specified in RFC-821, in this document, and 537 in extensions provided for in section 5. 539 For example, a typical receiving server supporting this protocol might 540 respond to a EHLO command with: 541 255-foo.domain 542 255-HELO 543 255-MAIL FROM 544 255-VRFY 545 255-EXPN 546 255-RCPT TO 547 255-EHLO 548 255-EMAL FROM 549 255-EVFY 550 255-SIZE 551 255-RSET 552 255-QUIT 553 255-DATA 554 255 LIMIT 64 3000 556 <> Discussion: 255 was chosen using the "positive completion" and 557 "mail system" model of RFC-821. This is really a system response 558 in context, rather than a purely informational (x1z) one. The 559 terminal "5" is arbitrary, motivated by a desire to leave a 560 little space after 251. Note that the normal response to HELO is 561 250, not 255. 563 Servers supporting EHLO MUST NOT return "502 Command not implemented" 564 for any verb that they list in their response to EHLO. 566 Servers that support any enhanced verb (i.e., a verb that appears in 567 this specification) that does not apear in RFC-821 MUST NOT return 568 "500 Syntax error" in response to EHLO. 570 <> Discussion: The statements above are part of the process of 571 binding all of the enhanced commands specified here together on a 572 basis in which implementations are expected to support all of 573 them together, rather than picking and choosing. At least one 574 example of these rules could be stated as "EMAL support does not 575 conform to this specification if the server that proports to 576 support EMAL does not support EHLO; EHLO support does not conform 577 if it does not return all of the "supported" verbs (as defined 578 above); and an EHLO implementation does not conform if it returns 579 any (non-"X") verb strings that are not in this specification, in 580 RFC-821, or registered with IANA. 582 7.2 Sender (client) considerations 584 A client that chooses to send a EHLO command to a server will receive 585 either host identification and a capability list or a "500 Syntax error" 586 indication (if the EHLO verb is not supported). If a capability list is 587 received, the client MUST NOT send verbs not listed. If a 500 reply is 588 received, the client MUST NOT attempt to send EMAL or other verbs that 589 do not appear in RFC-821. 591 A client that chooses to not send a EHLO command may, in parallel with 592 the RFC-821 model, attempt to use any desired facility and determine 593 its availability based on the response codes. 595 <> Discussion: EHLO Response Caching. 596 A client is permitted to send whatever commands it likes if it does 597 not send EHLO. The worst that can happen is that it will get a 598 rejection reply, and that can happen regardless. With the 599 exception of the size limits, the other capabilities can be 600 thought of as optimizations--if you can use them in a particular 601 situation, then things will work a little better, or smoother, or 602 faster, or... And it will be a rare case indeed that a host will 603 start supporting a given enhanced feature and then stop supporting 604 it. 606 So caching and consequently making a "wrong" inference is not, 607 unlike picking up a bad address from a DNS cache, a threat to much 608 of anything. It would be sensible (although not necessarily 609 ideal) to operate on a basis that, if you don't like the answer 610 you get, you don't cache it for very long at all; if you do like 611 the answer, you keep it cached until such time as you get a 612 rejection message. 614 <> Discussion: In practical terms, if a client sends "EHLO" to a 615 server and receives a response starting in 5, if is explicitly 616 justified in assuming that the server does not support 8-bit 617 transport according to this specification. If it gets a sequence 618 of 255 responses, it is explicitly justified in assuming that the 619 server does support 8-bit transport as specified here, as well as 620 the additional features (such as SIZE verification) that this 621 specification requires be supported if EHLO is specified. 623 7.3 The LIMIT Reply of EHLO 625 As message sizes grow it becomes progressively more useful for 626 connecting clients to know whether or not a server will be able to 627 accept a message of a given size. The LIMIT reply of EHLO returns two 628 values that are set by the administrator of the server to guide the 629 client in the handling of large messsages. The format of the reply is 630 as follows: 632 255 LIMIT 634 Both and are positive integer counts referring to message 635 sizes (length during transport) in kilo-octets. is the size for 636 a message below which the server will accept under normal conditions. 637 is the size for a message above which the server will not 638 accept. must be greater than or equal to which must, in 639 turn, be greater than or equal to zero. Messages between sizes 640 and may be accepted by the server, depending on available 641 resources. 643 <> Implementation note: Servers may, for various administrative 644 reasons, not want to give out exact limits. In practice, limits may 645 also depend on the designated recipient, with some users able to 646 receive larger messages than others even on a given host. For these 647 and other reasons, the values and should be taken as 648 general guidance, but not as absolute figures. Note that existing 649 provisions of RFC1123 imply minimum values of 650 LIMIT 64 64 651 for Internet hosts. 653 <> Discussion: A client can follow up this information by using the 654 SIZE verb (see below) to determine if the server is willing to 655 accept messages between and . 657 | | 658 |---------------------<================>---------------------| 659 Server will accept Ask Server Server will reject 661 8. SIZE verb 663 A new command verb, SIZE, is defined. Server implementations that 664 provide support for the enhanced mail verbs must accept and process 665 SIZE. Size does not specify an exact message length, but an upper bound 666 in kilobytes, on what will be transmitted as the "message", i.e., the 667 number of octets to be placed on the wire after the DATA verb and up to 668 the terminating ".CRLF" string. It is intended for server capability 669 verification purposes and not as an alternative for delimiting the end 670 of the message body. 672 <> Discussion: This type of estimated size has two characteristics 673 that exact sizes (byte or bit lengths) do not. First, it may be 674 convenient to estimate this type of size from crude file system 675 measures (e.g., "number of records" or "number of pages"), while a 676 specific length may require careful examination of the data stream 677 for, e.g. "." characters appearing at the beginning of the line. 678 Second, it is not unusual to change internal end of line conventions 679 to SMTP CRLF, to remap character sets, or to perform encodings to 680 different transport conventions dynamically, rather than storing the 681 transport-encoded mail file prior to transport (see "client 682 considerations", below, for additional discussion of this estimating 683 process). Various widely-practiced transport behaviors (e.g., 684 deletion of trailing blanks), while undesirable, also can distort 685 exact sizes. It is possible with a crude upper-bound size to 686 statistically estimate the effects of these transformations, while 687 exact sizes require creation (or careful simulation) of the file to 688 be transported and possibly simulation of the transport mechanism. 690 The argument to SIZE is a numeral specifying the predicted maximum 691 message length in kilobytes of the message that is part of the current 692 mail transaction. A SIZE agreement (i.e., sending of the command by 693 the client and positive reply by the server) extends only through the 694 end of the next DATA statement. 696 <> Discussion: Kilobytes, rather than bytes, were chosen to stress 697 the fact that this is an estimate, rather than a precise 698 value, and to prevent anyone from trying to infer end-of-message 699 from it. The use of a maximum-kilobyte estimate is also intended 700 to smooth over most of the differences among file systems in terms 701 of representation of end of line, widths of characters, and so on. 702 However, the intent is to have this estimate be of the only length 703 that has a canonical meaning, that is, the number of octets 704 actually being transported, rather than the length in either the 705 sending or receiving file system. 707 SIZE should be sent, if at all, after the FROM command and prior to 708 any RCPT commands. SIZE is not meaningful outside a mail transaction; 709 EHLO should be used to obtain similar information. 711 8.1 Server considerations 713 If a SIZE command is received as part of a mail transaction, the server 714 SHOULD make any of three types of replies: 716 (1) An acceptance reply, normally "250 OK", indicating that a message of 717 up to that size may be accepted. A server MUST NOT make this reply and 718 then reject, for reasons under its control, a message whose transport 719 size is less than the limit specified. 721 (2) A temporary rejection reply, normally "452 insufficient system 722 storage", indicating that a message of the specified size cannot be 723 accepted at present, but that this is a temporary restriction. This 724 response means that the requested size is acceptable to the server 725 system at some times. 727 (3) A fatal error reply, normally "552 message size too large", 728 indicating that a message of the specified size is not acceptable to 729 this host. 731 <> Discussion: This distinction is made for those cases where the 732 size limitation may be quite transient and consistent with the 733 sender's requeuing the message for retry and delivery later. 734 Examples of such limitations would be such traditional problems 735 as "system disk full", but not "we expect a new system release 736 next week that has higher limits". Of course, if it is feasible, 737 it would be better for systems in these transient situations to 738 accept the message and queue or store it locally, but these could 739 be very large messages, at least in principle. 741 <> Implementations of support for SIZE should use caution to insure 742 that it does not become a conduit for denial-of-service attacks. 744 Support for SIZE is discouraged outside mail transactions and no 745 semantics are defined for it. Enhanced servers should reject it as a 746 syntax error, or, preferably, with "503 SIZE not accepted without a 747 FROM verb". 749 8.2 Sender (client) considerations 751 As part of a mail transaction, a sender MAY send the SIZE command for 752 messages whose expected length is below 64 kilobytes. Senders are 753 encouraged to send the SIZE command or use EHLO or out-of-band 754 information to verify normal capacities for messages whose expected 755 length is larger than 64 kilobytes. Server rejection of the SIZE 756 command as a syntax error (not permitted from enhanced servers) SHOULD 757 be construed by the sender as "no information" and the sender should 758 behave as it would have behaved had the SIZE verb not been sent. 760 If the server accepts the SIZE command but rejects the particular size 761 requested with a temporary or fatal reply code, the sender may either 762 abandon the mail transaction (sending QUIT or RSET) or may continue 763 with it. However, it is not intended that SIZE become a subject for 764 iterative negotiation between sender and receiver; senders MUST NOT 765 send a second SIZE command within the same mail transaction. 767 <> Discussion: Nothing other than good sense prevents a client from 768 wildly overestimating a SIZE and, for obvious reasons, 769 overestimating is better than underestimating. Overestimated 770 sizes may, of course, result in unnecessary rejections. It seems 771 unreasonable to require that servers enforce the limits to which 772 they earlier agreed, although most will presumably enforce some 773 limit at or above the accepted size. This is consistent with 774 the general model of SIZE as specifying a sloppy value. 776 <> Discussion and implementation note: One of the difficulties in 777 estimating the amount of data to be transmitted, and hence the 778 value to be sent with SIZE, arises when the internal storage 779 conventions of the originating host use a single character end of 780 line convention, or some other marking or counting convention, 781 rather than CR LF. In this situation, some implementations have 782 historically created a file in Internet canonical mail transfer 783 form, i.e., with doubled leading periods and CR LF line delimiters, 784 while others have converted to the Internet form as lines are read 785 in and actually transmitted. In the latter case, while the file 786 size on the local host may be readily determined from the file 787 system, the actual number of octets to be transmitted is not known 788 until after all of them have been sent. If such an implementation 789 does not wish to scan the file and count line delimiters for 790 performance reasons, the worst-case estimate of SIZE for systems 791 using single-character line delimiters is twice the number of 792 characters in the file (expressed in kilo-octets). This worst case 793 would be reached if either the file consists only of line delimiters 794 or if it consists of alternating periods and line delimiters. 796 Since the optimal value to be sent with SIZE for files with no 797 line-starting periods is the internal length of the file plus the 798 number of lines it contains (that is, adding one extra character per 799 line), a considerably better estimate than one for the the worst 800 case may be obtained by knowing the average or typical line length 801 in the file and dividing it into the file size to obtain the 802 number of lines. In some cases, such as those in which a message 803 composing agent performs line wrapping and filling functions, 804 typical line length information might be obtained from that agent. 805 In others, a much better-than-worst-case estimate may be obtained 806 statistically by sampling the lengths of lines in the file, 807 preferably by probing at random or by examining lines at several 808 different points in the file, or, if that is not feasible, by 809 examining the first several lines. Similar logic applies when 810 "lines" in the internal file system are denoted in some fashion 811 that does not involve and end-of-line character sequence, e.g., by 812 carrying character counts for each line. 814 8.3 Server replies to RCPT in an implementation supporting SIZE. 816 A relay (or post office host) that can not accept a message of some 817 specified size may provide the client with the next hop information, in 818 the hope that the next hop is either the final destination or can relay 819 message of this size. If this information is to be supplied, it should 820 be provided via the message 821 "559 Too big, deliver to user at ... 822 which parallels the RFC-821 message code 551. 824 <> Example: Many sites implement (typically via DNS MX records) a 825 single host as the normal receiver of all mail for the site or 826 organization. This host may, however, have limited resources 827 relative to overall demands on mail flow into the organization. On 828 the other hand, particular users may have powerful workstations 829 which do not have the same resource constraints such that having 830 large messages sent directly to them might permit larger messages to 831 be delivered. 833 <> Discussion: Server designers contemplating this strategy should be 834 aware that few sending systems have the capability of dealing with 835 551 codes automatically; these codes typically cause messages to be 836 rejected and "bounced" to the user. Presumably the new 559 code in 837 this case will get much the same treatment. 839 Even if a SIZE command is set and accepted, a server is permitted to 840 reject messages based on size for individual addresses (i.e., after receipt 841 of RCPT TO) by responding to the delivery address with code 552. 843 Since a client may send large messages without first sending SIZE, or 844 may, in principle, send sizes larger than those specified, a server may 845 reject a message as being too long if it exceeds a specified size (or if 846 size is unspecified) as provided for in RFC-821, i.e., by returning a 847 552 (preferred) or 554 code after the data are received. 849 9. Interaction with the message format and headers. 851 Both RFC-821 and 822 explicitly reference "ASCII" as the character code 852 in which all text is written and with which it is interpreted. The 853 introduction of an enhanced transport mechanism introduces a potential 854 ambiguity, since, while there is only one ASCII, there are many 855 character sets and mechanisms using 8-bit and longer coding. This has 856 two implications: 858 9.1 Message format. 860 When sending a message using EMAL FROM, the message format MUST conform 861 to MIME and, in particular, with its provisions for specifying message 862 body types and character sets. Hence, message body-parts which contain 863 8-bit data may do so only in a fashion consistent with MIME. 865 9.2 Header character set. 867 With the exception of the "trace" or "time stamp" fields specified in 868 RFC-821 and 822 and elaborated upon below, this specification imposes 869 no requirements on mail header fields other than those in 9.1 above. 870 Trace fields must be entirely in ASCII, using the leading zero form 871 specified in RFC-821 if 8 bit underlying transport is in use. 873 <> Discussion: Additional requirements about other header fields 874 do appear in RFC-822 and RFCs that supplement it. This 875 specification neither relaxes nor increases those requirements. 877 10. Trace fields 879 RFC-821 specifies that mail transport agents add time stamps as trace 880 information to messages they are processing. RFC-822 specifies, in 881 section 4.3 (especially 4.3.2), the format of these ("Received") 882 fields for relayed messages. RFC-822 indicates that additional "via" 883 and "with" values should be registered but none have been as of the 884 date of this document. 886 While the tracing information specified in these earlier documents has 887 proven useful, the Internet and its mail handling has evolved so that 888 an audit trail that only documents relay and delivery activities has 889 become inadequate. In particular, messages may be converted from one 890 character set to another, formats may be altered, and address strings 891 may be changed at gateways. These transformations, and information 892 about where and how they were performed, should be included in the 893 audit trail. The extensions to the transport mechanism contemplated 894 here involve further complications, since gateways may be called upon 895 to convert between one transport format and another, an activity that 896 may require significant analysis and transformation of the message 897 itself. 899 The principle of providing and maintaining trace and audit trail 900 information is reaffirmed and extended. Any mail transport facility, 901 including gateways within the Internet and gateways from other mail 902 systems, that relays, converts, translates, or otherwise modifies an 903 enhanced mail message MUST add one or more "Received" fields to the 904 message to document these changes. Mail transport facilities that 905 relay, convert, or translate traditional SMTP mail are encouraged to 906 do so. The intent here is to insist that any change to a message as 907 it passes through a transport, other than adding the Received line, be 908 documented, and documented fairly explicitly. 910 The list of "Received" parameters in RFC-822 is extended to include 912 ["convert" atom "to" atom ["to" atom]...] 914 These represent, respectively, the character set and/or transport form 915 received by the relay or gateway and the character set and/or 916 transport form produced by the relay or gateway. "ASCII" and 917 "EBCDIC", the keyword "8-bit", all of the transport encodings 918 permitted in MIME, the keywords "7-bit-MIME" and "8-bit-MIME" 919 (designating MIME over 7 and 8 bit paths respectively), and the 920 keyword "unknown" (discussed below) are explicitly permitted for use 921 with "convert" and "to". 923 <> Discussion: "MIME7" and "MIME8", while obvious and more attractive 924 alternatives, almost guarantee future confusion with, e.g., "version 925 seven of MIME". 927 Servers providing "Received" lines of this sort are explicitly 928 encouraged to supplement the atoms associated with "convert" and "to" 929 with parenthesized comments that provide prose descriptions of 930 decisions made and actions performed when those might be helpful in 931 subsequent understanding or debugging. 933 When structured messages are converted from one MIME format to another, 934 or from another format to structured MIME messages, the conversion will 935 typically occur on individual body parts, not homogeneously for the 936 entire message. These cases should be documented using body part 937 conversion trace fields embedded in the message according to MIME 938 conventions. "to 7-bit-MIME" is to be used in conjunction with such 939 per-body-part conversion trace fields, to indicate that such fields 940 appear and that the specific conversion information appears in them. 942 <> Discussion: It is assumed that "convert 8-bit to 7-bit-MIME" 943 will appear only if the message entering the gateway was 944 determined to be in 8-bit form, but was not compliant with this 945 specification in terms of verification of capabilities or use of 946 MIME formats. See section 13 below. "Convert 8-bit-MIME to 947 7-bit-MIME" or "convert 7-bit-MIME to 7-bit-MIME" would both 948 indicate that conversion trace information appears on a 949 per-body-part basis in the message body and implies the presence 950 of such information. 952 As is the case for "with", multiple "to" parameters may be specified in 953 a single "Received" header to denote multiple transformations. 955 <> Discussion: If the relevant atoms were registered, this permits, 956 e.g., "convert ASCII to PostScript to G3Fax..." although, under 957 most circumstances, the starting and ending conversions within a 958 given host are really all that is required. In practice, a 959 specification that detailed would normally appear as "convert 960 7-bit-MIME to 7-bit-MIME", with additional information specified 961 on a per-body-part basis within the message. 963 As provided elsewhere in this specification, servers may choose to 964 accept messages or protocol negotiations that are invalid in one or 965 more respects and transform them into an acceptable form (presumably 966 using external information) rather than returning them. In these 967 situations, at least some of the information about the format of the 968 incoming message cannot be known with certainty or specified with 969 registered keywords. "Convert unknown to..." should be used to denote 970 this situation, and the clause should be supplemented with a comment 971 that indicates what was assumed about the incoming message, what 972 actions were applied to it, or both. 974 <> While there may be other cases, it is explicitly intended that 975 "convert unknown" be used when the incoming message is invalid in 976 the opinion of the server and the server attempts to "fix" the 977 message before relaying it or passing it through a gateway. A 978 parenthesised comment should be used to describe the fix applied. 980 For the purposes of the "with" parameter, the original protocol 981 specified by RFC-821 should be designated by "smtp", as indicated 982 there. If the extensions of this protocol are used, "esmtp" should be 983 used. 985 11. RSET and related RFC-821 issues 987 RFC-821 is not specific about exactly what the RSET verb resets. This 988 has apparently not been a problem in the past because of the simplicity 989 of the protocol. This enhanced protocol includes additional commands 990 and state information, making a more precise definition desirable. The 991 definition provided should not constrain any existing RFC-821 992 implementation since it is consistent with both the current practice 993 and the only two plausible interpretations. 995 RSET is to be interpreted by SMTP servers as clearing state information 996 present in a session. In particular, it eliminates the effect of any 997 prior FROM commands, any DATA, and any delivery addresses. It resets 998 the server's state to "not a mail transaction" (see section 2). 1000 RSET has been interpreted by some SMTP servers as requiring that a new 1001 HELO command be sent after RSET is acknowledged. Other servers assume 1002 that the previous HELO is not reset. Servers SHOULD accept a HELO 1003 command subsequent to RSET without special comment, overriding a 1004 previous one if necessary. Servers MUST NOT require a HELO command 1005 after a RSET. 1007 <> Discussion: The description above summarizes the current situation 1008 with SMTP implementations based on a series of experiments. No 1009 implementations have been identified that reject a second HELO, but 1010 it would not be surprising to find one. 1012 While the SMTP protocol provides for multiple destination (RCPT) 1013 commands, other state-inducing commands (e.g., the choice of MAIL, 1014 EMAL, or SEND with FROM) provide exclusive information that it is not 1015 meaningful to specify more than once in a given mail transaction. If a 1016 second instance of a state-inducing command appears in a given mail 1017 transaction, the server MAY either accept it, overriding earlier 1018 information, or may reject it as an out-of-sequence command with a "503 1019 bad sequence of commands" code. A client sending multiple of these 1020 commands within a mail transaction MUST be prepared to send a RSET and 1021 start over, or to send QUIT and abandon the session, if 503 is received 1022 in this case. Clients SHOULD, if possible, behave in a way that avoids 1023 this situation. 1025 <> Discussion: The issues above do not arise in the normal case of 1026 multiple successful message transmissions in the same session, 1027 since each successful message completion (i.e., server receipt of 1028 DATA, the message, CR LF . CR LF, and then sending a positive 1029 completion reply) results in terminating a mail transaction. 1030 Clients SHOULD NOT send RSET after receipt of a 250 response after 1031 DATA and the message; servers MUST reset their states after sending 1032 that 250 response and MUST NOT require clients to send RSET before 1033 the next xxxx FROM command, where "xxxx" is "MAIL", "SEND", 1034 "SOML", "SAML", "EMAL" or some future extension as specified in 1035 section 5.1. 1037 <> Discussion: This involves another nasty and intrusive bit of 1038 reality about which RFC-821 is vague. Where something as 1039 meaning-laden as an enhanced FROM verb is involved, we 1040 can't leave this to chance. The discussion above prohibits the 1041 "use the first and ignore all the rest" and the "pick one to 1042 believe at random" cases. Some SMTP servers have been observed 1043 experimentally to work in the "accept the last one" model 1044 outlined. 1046 12. Failure and error conditions 1048 12.1 RFC-821 behavior with unrecognized verbs. 1050 While it is not quite explicit, RFC-821 appears to expect that, if a 1051 verb is not recognized by the receiver, it will reject the command with 1052 a "permanent error", 5yz, code, presumably 500 (Syntax error). 1053 Similarly, it appears to specify that, if the sender receives such a 1054 code, it must either abandon the mail message (sending QUIT or RSET, 1055 presumably) or do something else involving the same or a different verb; 1056 it may not simply ignore the 5yz error code and pretend it was a 2yz (or 1057 354) code. This specification depends on that behavioral model. 1059 Consistent with RFC-821, we specify that existing SMTP servers are to 1060 reply with a return code of 500 (Syntax error) when any unfamiliar verb 1061 is received. 1063 <> Discussion: The material above should probably have made it into 1064 RFC-1123, but some of the issues--particularly the fact that 1065 anyone could ever have believed that anything else (such as 1066 simply ignoring 5yz codes) was permitted--have emerged only in 1067 the process of the investigation leading to this specification. 1068 Nonetheless, this clarification is believed to be consistent 1069 with existing usage and implementations of SMTP. 1071 <> That belief has been reinforced by fairly extensive testing-by- 1072 probing of existing implementations. No implementations 1073 exhibited catastrophic failure upon receipt of an unknown verb 1074 and all of those probed responded to such verbs by returning a 1075 "500 Syntax error" response. At the same time, it is impossible 1076 to verify that unknown commands will not cause subtle state 1077 changes in servers. Consequently, SMTP clients SHOULD respond 1078 to a "syntax error" reply by sending RSET and starting over, 1079 rather than assuming the state of the remote machine. 1081 12.2 Responses when EMAL is recognized. 1083 An SMTP server which does implement this specification may nonetheless 1084 respond to the EMAL verb or its variations with an error message. The 1085 new code 556 is assigned to this purpose, to be construed as "enhanced 1086 transport not accepted" if it appears in response to EMAL FROM. 1087 Presumably this would occur only if the originator address (the 1088 parameter to EMAL FROM) was unacceptable for enhanced transport for 1089 some reason. 1091 556 may also be returned in response to one or more of the RCPT commands 1092 if the refusal is destination-specific. More specifically, a receiving 1093 implementation that conforms to this specification MUST return 556 1094 rather than 550 (or some other code) if it would accept 7-bit mail for a 1095 particular address but would not accept enhanced transport for it. 1096 Conversely, 550 must be returned when the recipient would be rejected in 1097 either case. 1099 <> Discussion: Ideally, a server that can accept a particular 1100 enhanced transport option at all should be able to 1101 accept it for any destination for which it accepts mail. In 1102 practice, that may sometimes not be the case. In addition, the 1103 general design of RFC-821 permits a server to decline to accept a 1104 particular piece of mail for any particular destination for any 1105 reason. Consequently, it is not possible to prohibit a server 1106 from accepting enhanced mail and subsequently rejecting a 1107 delivery address. Our design choices in the matter are limited 1108 to whether to permit RCPT TO to deliver 556 (indicating that the 1109 particular transport type is not acceptable) or whether it 1110 should be restricted to one of existing (RFC-821) non-delivery 1111 codes. 1113 From the sender's point of view, one could appropriately deduce that a 556 1114 error in response to EMAL or some future enhanced FROM verb indicates 1115 that enhanced transport is not accepted from the sending host. A 556 in 1116 response to a RCPT verb would indicate that enhanced transport is not 1117 accepted for that particular address. 1119 <> Discussion: Server designers should be aware that accepting 1120 enhanced transport (e.g., 8-bit EMAL FROM) for mail to a given 1121 destination and then bouncing it is likely to be disruptive to the 1122 general mail environment, especially if the originating system was 1123 prepared to send mail in 7-bit form if necessary. Consequently, it 1124 is desirable for servers to not accept such mail unless they can 1125 guarantee delivery if the address is otherwise acceptable. This 1126 implies that it is desirable for servers to be prepared to either 1127 cause conversion of the message to an acceptable 7-bit MIME form 1128 (e.g., send it to an appropriate gateway), or that they should have 1129 out-of-band information available to permit them to determine the 1130 feasibility of enhanced delivery to a final destination without 1131 first accepting the mail. Conversely, it implies that mail client 1132 systems and those setting up, e.g., DNS records for particular 1133 hosts, should endeavor to prevent rejections from arising. 1135 If enhanced transport is accepted, and there is a subsequent delivery 1136 failure that necessitates the generation of a notification message (see 1137 RFC-1123, section 5.3.3), the error message text itself should be 1138 prepared using only ASCII graphic characters. 1140 <> Discussion: If the notification message contains the original 1141 content text, that message will normally have to be returned using 1142 enhanced transport if it was received using enhanced transport. 1143 Other provisions of this specification imply that if this is not 1144 feasible (e.g., the notification message must be returned over a 1145 path that does not support enhanced transport, the server 1146 generating the notification must either be prepared to convert the 1147 message content in a loss-less way to a 7-bit form, or that it 1148 should not attempt to return the content. 1150 If the specified enhanced transport verb is acceptable for the context 1151 specified in the mail transaction, then, when the DATA command is 1152 received, the server should return the same "354 Go ahead, terminating 1153 with CR LF . CR LF" message normally produced in response to that 1154 command. Any of the other codes returned by DATA may be returned also. 1156 12.3 Sender action in response to fatal errors. 1158 The action to be taken by the sender if 500, 556, or any other 1159 500-series code is returned is not specified by this specification 1160 other than in terms of the limitation imposed above that "something 1161 else" must be done. In other words, these codes MUST NOT be ignored, 1162 and octets with the high bit turned on (or extended-length characters) 1163 MUST NOT be transmitted unless an enhanced FROM command has been sent 1164 and acknowledged with a 250 code, AND a 250 or 251 reply has been 1165 received in response to at least one of the RCPT commands. 1167 The sender may, however, send a RSET and renegotiate the transfer after 1168 preparing to send data in a different form. The transformations 1169 permitted by the rules under "Interaction with message formats and 1170 headers" above are available to hosts providing intra-Internet gateway 1171 services between transport types. Of course the originating or 1172 destination system environments may make other transformations in 1173 messages appropriate to their knowledge of their own environments. 1175 <> Discussion and pointer: That paragraph contains the new version 1176 of the conversion weasel-words. With the understanding that 1177 alternate text would be gratefully welcomed, what it intends to 1178 do is to incorporate the Freed compromise. Restated very crudely 1179 into the authority model, the originating UA can do whatever it 1180 wants, and can delegate that authority to anything within its 1181 local system environment. The definition of "local system 1182 environment", the mechanism for delegation, and whether that 1183 delegation can be assumed within a local system environment are 1184 administrative questions beyond the scope of this (or any other) 1185 specification. Similarly, the ultimate destination UA can do 1186 whatever it wants, and can delegate that authority to anything 1187 within its local system environment (same definitions and 1188 qualifications). 1190 <> Nothing is said about gateways into non-Internet environments: 1191 While this further points out the importance of a "mail gateway 1192 requirements and guidelines" RFC, we have agreed that is a 1193 separate problem and one that we must avoid trying to solve here 1194 if we ever want to converge. 1196 The only conversions that are explicitly conformant to this 1197 specification involve gateways providing loss-less conversions between 1198 valid MIME formats, presumably by conversion to appropriate 7 bit 1199 transport formats and adding content-tranport-encoding fields to 1200 reflect the result of the transformations. In particular, an enhanced 1201 mail gateway MUST NOT attempt to convert between character sets or 1202 transport encodings by discarding high-order bits or octets. 1203 Similarly, conversion from one character set to another requires 1204 knowledge of both character sets and, as such, is not a transport 1205 activity. 1207 12.4 Mail relays, mail gateways, and this protocol. 1209 While it is not explicit in RFC-821, there is a general principle that 1210 mail transport facilities should not alter, or even inspect, the 1211 message itself. There is already a small exception to this in the 1212 requirement for receivers to add trace information and "time stamp" 1213 ("Received") lines (RFC-821, page 21; RFC-1123, section 5.2.8). 1214 Although this document respecifies the trace information, it is 1215 intended to avoid making further exceptions unless necessary and to be 1216 specific about those that are necessary. 1218 If a mail gateway is used to transform the message from an enhanced 1219 transport form to a 7-bit transport form, the resulting message MUST 1220 conform to the formats specified by MIME for 7-bit transport. This may 1221 require that it understand the content and structure of messages 1222 written in that format, since mechanical translation (e.g., character 1223 set encoding) of a message that uses extended-length characters in 1224 conjunction with MIME may not produce a resulting message that is 1225 compliant with that specification. 1227 <> Discussion/Translation into plain English: Nothing in this 1228 document permits nested encodings if MIME does not permit them. 1230 The responsibility for insuring that a message transmitted with EMAL 1231 FROM is in MIME format falls largely on the originator. Section 13.2 1232 discusses violations of this principle. 1234 12.4.1 Review of present RFC-821 status and requirements. 1236 Under a number of circumstances, an RFC-821 SMTP sender implementation 1237 may be called upon to deliver mail, not to a final destination, but to 1238 an intermediary (relay or gateway site) or to the address of a mailing 1239 list exploder. The sender may have no way to know that it is dealing 1240 with an intermediary. An intermediate mail system may not be able to 1241 verify, e.g., addresses during the SMTP negotiation. RFC-1123 1242 explicitly provides (section 5.2.7) for intermediate systems to return 1243 "ok" 250 codes for addresses that cannot be verified, only to send mail 1244 messages with error indications back when addresses fail after the SMTP 1245 connection is closed. Such failure could occur on the local host 1246 (e.g., local list expansion) or remotely (e.g., in a relay's SMTP 1247 processing with the next host in sequence). Consequently, a mechanism 1248 that we might describe as "whoops, that isn't really something that can 1249 be delivered as specified" alreadys exist in many SMTP server 1250 implementations, especially those that operate as relays or mail 1251 gateways. To the degree their implementation models require, clients 1252 must be prepared to deal with such delayed responses as well as 1253 immediate ones. And, as discussed above, returning messages to users 1254 as undeliverable is an acceptable (and normal) response to a receiver's 1255 rejection of enhanced forms of transport. 1257 At the same time, mail gateways are permitted to accept one address 1258 from a sender for delivery and then carry out significant 1259 transformations of that address (and even the message) before passing 1260 it along to the actual delivery host, or the next host in sequence. 1261 While RFC-821 provides for altering host names (section 3.6) and RFC-1123 1262 provides for header, address, and protocol modifications (section 1263 5.3.7), nothing in any Internet standard protocol to date attempts to 1264 completely specify this behavior in the general case. 1266 12.4.2 Relay behavior. 1268 The basic model described above for RFC-821 is not changed by this 1269 protocol. While hosts that accept 8 bit messages for relaying may 1270 be prepared to "downgrade" such messages to seven bit transport, they 1271 cannot be required to do so. A receiver may reject a request for 1272 enhanced transport or for any specific transport type, regardless of 1273 whether the request comes directly from the originating host or some 1274 intermediary. A relay host that accepts enhanced transport of a 1275 particular type must be prepared for a host to which it attempts to 1276 pass the message to reject that option. Hosts may agree to enhanced 1277 transport and specific types and then "bounce" messages by mailing 1278 error indications as specified in RFC-1123 and above, just as they may 1279 accept mailbox designations and then bounce those messages. 1281 13. Treatment of other important protocol violations 1283 13.1 Receipt of 8 bit characters without prior verification 1285 Since it is known that some Internet hosts now send 8-bit characters 1286 without performing the verification specified in this document (i.e., 1287 sending EMAL and getting a positive response), servers should be robust 1288 enough to avoid self-destruction if non-compliant behavior of this type 1289 is encountered. 1291 As mentioned above, sending SMTPs MUST NOT transmit octets with the 1292 high bit non-zero without first successfully negotiating 8-bit 1293 transport with the receiver. Receivers are not required to enforce 1294 this requirement beyond the degree needed to prevent their destruction 1295 if this rule is violated. If a receiver encounters octets with the 1296 high bit set after a DATA command, it MUST select one of the following 1297 three alternatives to be conforming to this specification: 1299 (i) It may reject the message with a 520 error code, indicating an 1300 attempt to send invalid data over the transmission channel. This 1301 message SHOULD NOT be sent until the terminating CR LF . CR LF is 1302 received. 1304 (ii) It may deliver the message in 8 bit form if it knows that such 1305 delivery can be made reliably and without loss of information (if it is 1306 the destination MTA) and may transparently relay the message (using MAIL 1307 FROM) as received (if it is a relay MTA). 1309 <> Discussion: This option has the effect of [almost] encouraging and 1310 permitting a strategy that is otherwise taken as explicitly 1311 non-conforming: the sending of 8 bit data over a conventional 821 1312 connection with MAIL FROM. The context for this option should be 1313 carefully understood. To be in this situation, the delivery or 1314 relay host has received a non-conforming message from a 1315 non-conforming sender. This rule exists to permit the relay to 1316 forward the message "without making things any worse", i.e., to 1317 cause the same non-conforming message to be delivered to the 1318 destination as would have been delivered had the relay not been 1319 involved. And it permits the final delivery SMTP server to do 1320 whatever it decides to do for (or to) its users, a situation that 1321 is impossible to restrict anyway. 1323 (iii) If sufficient information is available to make the conversion 1324 and it has gateway capabilities, it may convert the message to a valid 1325 MIME form consistent with seven bit transport and forward or deliver 1326 the message in that form. This requires that the received 8 bit 1327 message be in MIME form in order that, e.g., character sets can be 1328 reliably determined or that the MTA has access to reliable out of band 1329 information about the character set(s) present in the message. MTAs 1330 MUST NOT attempt to guess at information not explicitly supplied in 1331 incoming messages in order to perform conversions of this type. 1333 <> Discussion: The options above deliberately and explicitly prohibit 1334 the practice of relays "bit stripping" messages (i.e., zeroing the 1335 high-order bit) as a conversion method to 7 bit transport. This 1336 technique loses information; the severity of the information loss is 1337 a function of the actual message content and the perceptions of the 1338 user, but can be quite significant. 1340 13.2. Receipt of non-MIME message bodies after receipt and acceptance 1341 of EMAL. 1343 This protocol requires that a message transmitted after EMAL is used in 1344 a mail transaction conform to the MIME format (see section 9.1). A 1345 receiving SMTP server or relay is not required to detect failure to 1346 conform to this requirement. However, if the server does do so, it may 1347 reject the message and should use a 558 error code in the rejection. A 1348 gateway which is otherwise inspecting or modifying the message body 1349 assumes responsibility for the messages it forwards and, consequently, 1350 must either reject invalid messages or transform them into valid form 1351 without loss of information (paralleling the discussion in section 1352 13.1). 1354 14. Compliance summary 1356 A server implementation supporting any of these verbs other than SIZE, 1357 must support all of them. SIZE might plausibly be supported in 1358 implementations that do not support the other verbs (which does not 1359 make that implementation fully conform to this specification), but must 1360 be supported in implementations that support the others. A server must 1361 not require that EHLO preceed the use of other verbs specified here. 1363 A client may attempt to use any of these verbs, but must observe 1364 responses to insure that the server verifies its willingness to accept 1365 them. Some of those responses constrain further action on the part of 1366 the client, as discussed above. For example, if the client asks for a 1367 capabilities list (via EHLO), it must not send commands that are not 1368 represented on the list received. Similarly, if a receiving SMTP 1369 rejects the EMAL FROM command, the client must not attempt to transport 1370 8-bit information with the DATA command. 1372 Nothing in this specification imposes any requirements that clients wait 1373 for responses to particular commands before issuing the next one(s) that 1374 are not imposed by RFC-821 or the logic of the commands themselves. 1375 However, several of the provisions above imply that a client must 1376 synchronize with verifications (affirmative responses) from the server 1377 before actually sending the message body. 1379 15. References 1381 [ANSI-X3.4] American National Standards Institute, "Coded Character 1382 Set--7-Bit American Standard Code for Information Interchange", 1383 ANSI X3.4-1986. 1385 [Gianone] Gianone, Christine M., "A Kermit Protocol Extension for 1386 International Character Sets", Columbia University, 1990 1387 (unpublished paper). Available via anonymous FTP from 1388 watsun.cc.columbia.edu:kermit/e/isok5.txt. 1390 [RFC821] Postel, J. "Simple Mail Transfer Protocol", RFC-821, 1391 August 1982. 1393 [RFC822] Crocker, D. "Standard for the Format of ARPA Internet Text 1394 Messages", RFC 822, August 1982. 1396 [RFC1123] Braden, R. "Requirements for Internet Hosts -- Application 1397 and Support", RFC-1123, October 1989. 1399 [RFC1342] Borenstein, N. and N. Freed. "MIME (Multipurpose Internet 1400 Mail Extensions): Mechanisms for specifying and describing the 1401 format of internet message bodies", RFC-1341, June 1992. 1403 [ISO646] International Organization for Standardization. 1404 "International Standard--Information Processing--ISO 7-bit coded 1405 character set for information interchange", ISO 646:1983. 1407 16. Acknowledgements 1409 This document represents a synthesis of the ideas of many people and 1410 reactions to the ideas and proposals of others. Randall Atkinson, 1411 Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed ideas 1412 and text sufficient to be considered co-authors. Other important 1413 suggestions, text, or encouragement came from Harald Alvestrand, Jim 1414 Conklin, Mark Crispin, Frank da Cruz, Dave Crocker, Ned Freed, 'Olafur 1415 Gudmundsson, Per Hedeland, Christian Huitma, Neil Katin, Eliot Lear, 1416 Harold A. Miller, Dan Oscarsson, Einar Stefferud, Rayan Zachariassen, 1417 and probably several others. Of course, none of these people are 1418 necessarily responsible for the combination of ideas represented here. 1419 Indeed, in some cases, the response to a particular criticism was to 1420 accept the problem identification but to include an entirely different 1421 solution from the one originally proposed. 1423 17. Security considerations. 1425 This RFC does not discuss security issues and is not believed to 1426 raise any security issues not endemic in electronic mail and present 1427 in fully conforming implementations of RFC-821. It does provide, via 1428 the EHLO verb and response, an announcement of system mail 1429 capabilities, but all of the information provided can be readily 1430 deduced by selective probing of the verbs required to transport and 1431 deliver mail. Similarly, as discussed above, capabilities such as those 1432 provided by the SIZE verb might be used for crude attempts at denial of 1433 service attacks, but, unless implementations are very weak, there is no 1434 problem here that has not always existed with SMTP. 1436 18. Editor's Address 1438 John C. Klensin 1439 Department of Architecture 1440 Room N52-457 1441 Massachusetts Institute of Technology 1442 Cambridge, MA 02139 1443 USA 1444 tel: 617 253 1355 (international: +1 617 253 1355) 1445 fax: 617 491 6266 (international: +1 617 491 6266) 1446 email: Klensin@MIT.EDU 1448 ------------------------------ 1449 Appendix A 1451 New response codes (or response codes used in new ways) introduced in 1452 this document. 1454 255 EHLO: Normal informational response 1455 452 SIZE: insufficient system storage 1456 503 SIZE: not accepted without a FROM verb 1457 503 Redundant use of any state-inducing command: Use of, e.g., MAIL 1458 FROM twice in the same mail transaction, or both MAIL FROM and 1459 EMAL FROM. 1460 520 DATA: Invalid data on transmission channel (8-bit data 1461 encountered after MAIL FROM command or non-MIME data after EMAL 1462 FROM. 1463 552 SIZE: message size too large 1464 552 RCPT: message size too large for this specific address. 1465 556 EVFY: Address ok, enhanced transport not accepted. 1466 556 EMAL: Enhanced transport not accepted. 1467 556 RCPT: Enhanced transport not accepted (destination specific) 1468 558 DATA: Invalid message format (i.e., not MIME) encountered 1469 after EMAL FROM command. 1470 559 RCPT: user not local, please try... (if message can be delivered 1471 directly, but not to the originally-specified address) 1473 Expires: January 27, 1993 1474 ********** 1475 [Temporary] Appendix B: 1477 Changes for the 15 July version arising from the Boston IETF and 1478 subsequent fine-tuning discussions. 1479 (Changes to draft-ietf-smtpext-8bittransport-05.txt) 1480 -- Additional language for the expanded trace fields, including a 1481 discussion of bogus messages. 1482 -- More specific language about what should be returned when EHLO is 1483 sent and how the response should be construed. 1484 -- Change of title to remove "text-based". 1485 -- Clarification of the role of "discussion" sections. 1486 -- Several more typos and small clarifications. 1488 Changes for the 24 June version arising from on-list discussion of the 1489 draft produced after the San Diego IETF. 1490 (Changes to draft-ietf-smtpext-8bittransport-04.txt) 1491 -- Reinstated general extension mechanism in section 5. 1492 -- Cleaned up some section numbering and make several small editorial 1493 changes. 1494 -- Tightened definition of EHLO with regard to features and future 1495 extensions. 1497 Changes from the 12 March version arising from discussion at the March 1498 1992 (San Diego) IETF and discussion subsequent to that meeting: 1499 (Changes to draft-ietf-smtpext-8bittransport-03.txt) 1500 -- Consolidate of the "capabilities" notion (former CPBL verb) with an 1501 enhanced "hello" command (EHLO). 1502 -- Added discussion of a possible 551 response to RCPT TO in the 1503 context of a "too large" message announced by SIZE (section 8.3). 1504 -- Added some new text to the complicance summary (section 14). 1505 -- Replacement of "negotiate" with the more precise "verify" 1506 -- Removed several remaining textual artifacts of incomplete or 1507 rejected design ideas. 1508 -- Removed open issue in EVFY and replaced all placeholders with 1509 text. 1510 -- Removed explicit disclaimer that these features are not asserted 1511 to be necessary. 1512 -- Changed language about failure/reporting of inability to deliver 1513 in 8-bit format to a Discussion and made explicit provision for 1514 non-return of content. 1515 -- Replaced the "conformance summary" placeholder with text. 1516 -- Defined the reply syntax from EHLO/CPBL and the associated size 1517 model. 1518 -- Defined and clarified the use of SIZE. 1519 -- Added new subsection to discuss the error handling when non-MIME 1520 message bodies are received with EMAL. 1521 -- Fixed text to be less tedious about "ANSI X3.4". 1522 -- Addition of brief discussion/explanation about the issues 1523 associated with "long" (multiple octet) characters. 1525 Changes from the 22 November version 1526 (draft-ietf-smtpex-8bittransport-02.txt) 1527 -- Fixed several small typographical errors 1528 -- Removed a few residual vestiges of very wide transport and 1529 envelope character set specifications. 1530 -- Replaced several different types of references to what is now MIME 1531 with that designation. 1532 -- Removed several server requirements for the 8->7 boundary, 1533 adopting the "conformance on the wire" and "separate requirements 1534 doc" approach agreed to on the mailing list. In particular, the 1535 "wretched solution" has been removed or, more exactly, downgraded 1536 to a discussion note as agreed upon on the mailing list. 1537 -- Improved rules for server when unnegotiated 8-bit is encountered, 1538 per mailing list. These are a change in tone, but not a real 1539 change in requirements. 1540 -- Removed "tentative decision" identifiers in all areas in which no 1541 disagreement has been expressed on the list, since these tentative 1542 agreements were discussed in Santa Fe. 1543 -- Made the rule requiring all hosts that support EMAL to also 1544 support MAIL explicit as the result of mailing list discussion. 1545 -- Provided a thinly-disguised forward pointer to the MXE proposal. 1547 ********** 1548 [Temporary] Appendix C. 1550 Outstanding issues, RFC-ZZZZ-03. 12 March 1992. 1551 ** Items marked ** have been fixed or eliminated as problems in the 1552 first or second drafts of version 4. ** 1554 **(1) Should the remaining discussion paragraphs be retained somewhat longer 1555 or removed at this time? (general) 1557 **(2) Is the extension mechanism for alternate "FROM" forms adequate 1558 specified, and, if how, how should it be specified (Section 5, IESG/IANA 1559 issue). 1561 **(3) Does EVFY need to distinguish between "cannot verify remote address" 1562 and "cannot verify remote address and whether 8-bit mail can be delivered 1563 to it"? (Section 6). 1565 **(4) Syntax model for CPBL (Section 7.1) 1567 **(5) (placeholder) Syntax for SIZE replies (Section 7.1) 1569 **(6) (placeholder) Improved wording needed for the trace field requirement 1570 (Section 10) 1572 **(7) Need a pair of Received keywords to replace 7/8-bit-MIME. (section 10) 1574 **(8) Granularity of "Received: ...convert...to" (Section 10) 1576 **(9) Errors returned by different paths than messages were sent over and 1577 non-return of content. (Section 12.2) 1579 **(10) (placeholder) The compliance summary is still a placeholder 1580 (section 14). 1582 --------------------- 1584 The following additional items, left over from November, will go away as 1585 indicated unless serious proposals appear early in the San Diego meeting 1586 or sooner. 1588 (11) Open issue: The CPBL functionality gives us a way to explicitly 1589 specify how further extensions beyond those of this document (including 1590 "private" ones) might be tested. In addition to possibly the usual words 1591 about "X"s, we could *require* that the attempted use of any verb not 1592 specified in a standard or near-standard RFC must be preceeded by the use 1593 of CPBL to verify that the server supports it. My bias that being 1594 explicit reduces later problems makes a small argument for including some 1595 text to this effect. Anyone who feels strongly one way or the other 1596 should speak up. 1597 Default decision: Defer (punt) 1599 **(12) Extensions/ mechanisms for formatted error messages when such 1600 messages are mailed back. There are really two separate problems here: 1601 an encapsulation model (MIME extension) for returning the content of 1602 8-bit messages over 7-bit channels and a canonical representation and 1603 taxonomy for mailed error responses. Note that these are primarily 1604 MIME problems; RFC-ZZZZ mostly just needs to point to the solution. 1605 Also note that not solving the encapsulation problem implies non-return 1606 of content in some cases. 1607 Default decision: if agreement cannot be reached, the language in 1608 RFC-ZZZZ that permits non-return of content in some cases will be 1609 strengthened. The canonical mesage form problem is one we have been 1610 living with since before RFC-821 and is not on the critical path for 1611 RFC-ZZZZ. 1613 ********** 1614 Expires: January 27, 1993