idnits 2.17.1 draft-freed-bsmtp-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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. ** The abstract seems to contain references ([RFC-821,RFC-1869], [RFC-1891], [RFC-1847]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 405 has weird spacing: '...rnished to ot...' == Line 406 has weird spacing: '...herwise expla...' == Line 408 has weird spacing: '...without restr...' == Line 409 has weird spacing: '... notice and t...' == Line 410 has weird spacing: '...ivative works...' == (4 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1998) is 9385 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: 'RFC-1891' is mentioned on line 141, but not defined ** Obsolete undefined reference: RFC 1891 (Obsoleted by RFC 3461) == Unused Reference: 'RFC-822' is defined on line 328, but no explicit reference was found in the text == Unused Reference: 'RFC-1123' is defined on line 332, but no explicit reference was found in the text == Unused Reference: 'RFC-2045' is defined on line 360, but no explicit reference was found in the text == Unused Reference: 'RFC-2046' is defined on line 366, but no explicit reference was found in the text ** Obsolete normative reference: RFC 821 (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1652 (Obsoleted by RFC 6152) ** Obsolete normative reference: RFC 1653 (Obsoleted by RFC 1870) ** Obsolete normative reference: RFC 1854 (Obsoleted by RFC 2197) ** Obsolete normative reference: RFC 1869 (Obsoleted by RFC 2821) Summary: 18 errors (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Ned Freed, Innosoft 3 Internet Draft Dan Newman, Innosoft 4 Mark Hoy, SunSoft 5 Jacques Belissent, SunSoft 7 The 8 Batch SMTP 9 Media Type 11 August 1998 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are 16 working documents of the Internet Engineering Task Force 17 (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months. Internet-Drafts may be updated, replaced, or obsoleted 23 by other documents at any time. It is not appropriate to use 24 Internet-Drafts as reference material or to cite them other 25 than as a "working draft" or "work in progress". 27 To view the entire list of current Internet-Drafts, please check 28 the "1id-abstracts.txt" listing contained in the Internet-Drafts 29 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 30 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 31 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 32 (US West Coast). 34 Copyright (C) The Internet Society (1998). All Rights 35 Reserved. 37 1. Abstract 39 This document defines a MIME content type suitable for 40 tunneling an ESMTP [RFC-821, RFC-1869] transaction through any 41 MIME-capable transport. This type can be used for a variety 42 of purposes, including: 44 (1) Extending end-to-end MIME-based security services 45 (e.g., [RFC-1847]) to cover message envelope 46 information as well as message content. 48 (2) Making it possible to use specific SMTP extensions such 49 as NOTARY [RFC-1891] over unextended SMTP transport 50 infrastructure. 52 (3) Enabling the transfer of multiple separate messages in 53 a single transactional unit. 55 1.1. Requirements Notation 57 This document occasionally uses terms that appear in capital 58 letters. When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD 59 NOT", and "MAY" appear capitalized, they are being used to 60 indicate particular requirements of this specification. A 61 discussion of the meanings of these terms appears in [RFC- 62 2119]. 64 2. The Application/batch-SMTP Content Type 66 The "application/batch-SMTP" MIME content type is a container 67 for the client side of an SMTP or ESMTP transaction. In 68 keeping with traditional SMTP, the contents are line oriented 69 and CRLF line terminators MUST be used. 71 The "application/batch-SMTP" type is defined as follows: 73 Media type name: application 74 Media subtype name: batch-SMTP 75 Required parameters: none 76 Optional parameters: required-extensions 77 Encoding considerations: 78 8bit material may appear, so quoted-printable or base64 79 encoding may be necessary on transports that do not 80 support 8bit. While the content of this type is 81 line-oriented and uses conventional CR/LF terminators, 82 lines longer than 7bit and 8bit encodings allow (998 83 octets) may appear, hence quoted-printable or 84 base64 encoding may be necessary even in conjunction 85 with 8bit transports. 86 Security considerations: 87 Discussed in the Security Considerations Section. 89 3. How application/batch-SMTP is used 91 The following diagram illustrates how the application/batch- 92 SMTP type is intended to be used: 94 application/batch-SMTP object 95 +----------------+ 96 | | 97 +-----------+ v +----------+ v +-----------+ 98 | batch | | MIME- | | batch | 99 => | SMTP | => | capable | => | SMTP | => 100 | generator | |transport | | processor | 101 ^ +-----------+ +----------+ +-----------+ ^ 102 | | 103 +-- conventional SMTP/RFC822 message transaction --+ 105 A conventional SMTP message transaction is converted into an 106 application/batch-SMTP object by the batch SMTP generator. 107 This object is then carried over some type of MIME-capable 108 transport. Once the destination is reached the object is 109 presented to a batch SMTP processor, which converts the 110 application/batch-SMTP object back into a conventional SMTP 111 message transaction. 113 4. Generation of application/batch-SMTP material 115 Application/batch-SMTP material is generated by a specially 116 modified SMTP client operating without a corresponding SMTP 117 server. The client simply assumes a successful response to all 118 commands it issues. The resulting content then consists of the 119 collected output from the SMTP client. 121 4.1. Honoring SMTP restrictions 123 Most batch SMTP processors will be constructed by modifying 124 and extending existing SMTP servers. As such, all of the 125 restrictions on SMTP constructs imposed by RFC 821, RFC 1123, 126 and RFC 1869 MUST be observed. In particular, restrictions on 127 command and data line lengths, number of recipients, and so on 128 still exist and apply to batch SMTP. 130 4.2. Use of SMTP Extensions 132 Since no SMTP server is present the client must be prepared to 133 make certain assumptions about which SMTP extensions can be 134 used. The generator 136 (1) MAY assume that ESMTP [RFC-1869] facilities are 137 available, that is, it is acceptable to use the EHLO 138 command and additional parameters on MAIL FROM and RCPT 139 TO. 141 (2) If EHLO is used MAY assume that the 8bitMIME [RFC- 142 1652], SIZE [RFC-1653], and NOTARY [RFC-1891] 143 extensions are available. In particular, NOTARY SHOULD 144 be used. 146 (3) MAY create private bilateral agreements which specify 147 the availability of additional SMTP extensions. 148 Additional SMTP extensions MUST NOT be used in the 149 absence of such an agreement, and, perhaps more 150 importantly, a conformant generation of 151 application/batch-SMTP objects MUST be able to produce 152 objects restricted to use of the extensions listed 153 above. 155 The "required-extensions" content type parameter MAY be used 156 to communicate a list of the extensions actually used, 157 specified as a comma-separated list of EHLO responses. If 158 absent it defaults to the list "8bitMIME,SIZE,NOTARY". Any 159 use by private bilateral agreement of additional or different 160 extensions MUST be noted in the "required-extensions" 161 parameter. 163 Note that many SMTP extensions simply do not make sense in the 164 context of batch SMTP. For example, the pipelining extension 165 [RFC-1854] makes no sense in the absence of a network 166 connection. 168 4.3. Handling Multiple Messages 170 Generators SHOULD attempt to minimize the number of messages 171 placed in a single application/batch-SMTP object. Ideally a 172 single application/batch-SMTP object will be created for each 173 message. Note, however, that some uses of application/batch- 174 SMTP (e.g., mail bagging) may exist solely to take advantage 175 of the multiple messages in a single container capability of 176 batch SMTP, so requiring a one message per container is not 177 possible. 179 DISCUSSION: The SMTP protocol provides for the transfer of a 180 series of messages over a single connection. This extends in a 181 natural way to batch SMTP. However, the issues in batch SMTP 182 are somewhat different. Suppose, for example, that a batch 183 SMTP processor receives an application/batch-SMTP object 184 containing two messages but is unable to process the second 185 message because of a storage allocation failure. But not only 186 does this failure preclude processing of the second message, 187 it also precludes requeuing or otherwise noting that the first 188 message has already been processed. Subsequent reprocessing of 189 the application/batch-SMTP then leads to duplication of the 190 first message. 192 This issue is not materially different from the well-known 193 problems with SMTP synchronization that in practice often lead 194 to duplicated messages. Since this behavior is inherent in 195 SMTP to begin with it is not incumbent on application/batch- 196 SMTP to completely address the issue. Nevertheless, it seems 197 prudent for application/batch-SMTP to try and not make matters 198 even worse. 200 5. Tranport of application/batch-SMTP objects 202 Application/batch-SMTP objects may be transported by any 203 transport capable of preserving their MIME labelling, e.g., 204 HTTP or SMTP. 206 Transports MUST remain cognizant of the special nature of 207 application/batch-SMTP. An application/batch-SMTP object 208 contains one or more "frozen" SMTP message transactions. SMTP 209 message transactions typically carry with them various 210 assumptions about quality of service, e.g., that messages will 211 either be delivered successfully or a nondelivery notification 212 will be returned, that a nondelivery notification will be 213 returned if delivery cannot be accomplished in a timely 214 fashion, and so on. It is vital that the encapsulation of 215 these objects for carriage over other forms of transport not 216 interfere with these capabilities. 218 6. Processing of application/batch-SMTP material 220 Processing of application/batch-SMTP material is considerably 221 more complex than generating it. As might be expected, a 222 modified SMTP/ESMTP processor is used. However, since it 223 cannot return information to the client, it must handle all 224 error conditions that arise itself. In other words, a batch 225 SMTP processor assumes both the responsibilities of a 226 traditional SMTP server as well as part of the 227 responsibilities of a traditional SMTP client. 229 As such, a conforming processor: 231 (1) MUST check MIME content type information to insure that 232 the material it has been presented with is labelled as 233 application/batch-SMTP and doesn't specify any 234 extensions the processor doesn't support in the 235 "required-extensions" parameter. Application/batch-SMTP 236 objects that employ an unsupported extension SHOULD be 237 forwarded to the local postmaster for manual inspection 238 and handling. 240 (2) MUST accept any syntactically valid EHLO or HELO 241 command. 243 (3) MUST accept any syntactically valid MAIL FROM command. 244 A conforming processor, MAY, if it so desires, note the 245 unacceptability of some part of a given MAIL FROM 246 command and use this information to subsequently 247 generate non-delivery notifications for any or all 248 recipients. 250 (4) MUST accept any syntactically valid RCPT TO command. A 251 conforming processor SHOULD note the unacceptability of 252 some part of a given RCPT TO command and subsequently 253 use this information to generate a non-delivery 254 notification for this recipient in lieu of actually 255 delivering the message. 257 (5) MUST accept any of the additional parameters defined by 258 the 8bitMIME, SIZE, and NOTARY SMTP extensions on the 259 MAIL FROM and RCPT TO commands. 261 (6) MUST accept the DATA command even when no valid 262 recipients are present. 8bit MIME messages MUST be 263 accepted. 265 (7) MUST accept the RSET command and handle multiple 266 messages in a single application/batch-SMTP object. 267 Processors MUST process each message in an 268 application/batch-SMTP object once and SHOULD take 269 whatever steps are necessary to avoid processing a 270 message more than once. For example, if processing of 271 an application/batch-SMTP object containing multiple 272 messages is interrupted at an intermediate point it 273 should subsequently be restarted at the end of the last 274 message that was completely processed. 276 (8) SHOULD forward any syntactically invalid 277 application/batch-SMTP message to the local postmaster 278 for manual inspection and handling. 280 7. Security Considerations 282 Application/batch-SMTP implements a tunneling mechanism. In 283 general tunneling mechanisms are prone to abuse because they 284 may provide a means of bypassing existing security 285 restrictions. For example, an application/batch-SMTP tunnel 286 implemented over an existing SMTP transport may allow someone 287 to bypass relay restrictions imposed to block redistribution 288 of spam. 290 Application/batch-SMTP processors SHOULD implement access 291 restrictions designed to limit access to the processor to 292 authorized generators only. (Note that this facility may be 293 provided automatically if application/batch-SMTP is being used 294 to secure message envelope information.) 295 8. Acknowledgements 297 The general concept of batch SMTP has been around for a long 298 time. One particular type of batch SMTP was defined by Alan 299 Crosswell and used on BITNET to overcome BITNET's native 8 300 character limit on user and host names. However, this form of 301 batch SMTP differed from the current proposal in that it 302 envisioned having the server return the status code responses 303 to the client. In this case the client bore the burden of 304 correlating responses with the original SMTP dialogue after 305 the fact. 307 Unfortunately this approach proved not to work well in 308 practice. BITNET eventually switched to the same basic form of 309 batch SMTP that has been defined here. Unfortunately that 310 definition was, to the best of the present authors' knowledge, 311 never captured in a formal specification. It should also be 312 noted that the definition given here also differs in that it 313 takes SMTP extensions into account. 315 Einar Stefferud had previously considered the problem of 316 carrying extended SMTP messages over unextended SMTP 317 transports. He proposed that some form of "double enveloping" 318 technology be developed to address this problem. The mechanism 319 presented here effectively implements the type of solution he 320 proposed. 322 9. References 324 [RFC-821] 325 Postel, J., "Simple Mail Transfer Protocol", RFC 821, 326 August, 1982. 328 [RFC-822] 329 Crocker, D., "Standard for the Format of ARPA Internet 330 Text Messages", RFC 822 August, 1982. 332 [RFC-1123] 333 Braden, B., "Requirements for Internet Hosts -- 334 Application and Support", RFC 1123, STD 3, October 1989. 336 [RFC-1652] 337 Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker, 338 D., "SMTP Service Extension for 8bit-MIMEtransport", RFC 339 1652, July, 1994. 341 [RFC-1653] 342 Klensin, J., Freed, N., Moore, K., "SMTP Service 343 Extension for Message Size Declaration", RFC 1653, July, 344 1994. 346 [RFC-1847] 347 Galvin, J., Murphy, S., Crocker, S., Freed, N., " 348 Security Multiparts for MIME: Multipart/Signed and 349 Multipart/Encrypted", RFC 1847, October, 1995. 351 [RFC-1854] 352 Freed, N., Cargille, A., "SMTP Service Extension for 353 Command Pipelining", RFC 1854, October, 1995. 355 [RFC-1869] 356 Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker, 357 D., "SMTP Service Extensions", RFC 1869, STD 10, 358 November, 1995. 360 [RFC-2045] 361 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 362 Extensions (MIME) Part One: Format of Internet Message 363 Bodies", RFC 2045, Innosoft, First Virtual Holdings, 364 December, 1996. 366 [RFC-2046] 367 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 368 Extensions (MIME) Part Two: Media Types", RFC 2046, 369 Innosoft, First Virtual Holdings, December, 1996. 371 [RFC-2119] 372 Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", RFC 2119, March, 1997. 375 10. Authors' Addresses 377 Ned Freed 378 Innosoft International, Inc. 379 1050 Lakes Drive 380 West Covina, CA 91790 381 USA 382 tel: +1 626 919 3600 fax: +1 626 919 3614 383 email: ned.freed@innosoft.com 385 Dan Newman 386 Innosoft International, Inc. 387 1050 Lakes Drive 388 West Covina, CA 91790 389 USA 390 tel: +1 626 919 3600 fax: +1 626 919 3614 391 email: ned.freed@innosoft.com 393 Mark Hoy 394 SunSoft 396 Jacques Bellisent 397 SunSoft 399 11. Full Copyright Statement 401 Copyright (C) The Internet Society (1998). All Rights 402 Reserved. 404 This document and translations of it may be copied and 405 furnished to others, and derivative works that comment on or 406 otherwise explain it or assist in its implementation may be 407 prepared, copied, published and distributed, in whole or in 408 part, without restriction of any kind, provided that the 409 above copyright notice and this paragraph are included on all 410 such copies and derivative works. However, this document 411 itself may not be modified in any way, such as by removing 412 the copyright notice or references to the Internet Society or 413 other Internet organizations, except as needed for the purpose 414 of developing Internet standards in which case the procedures 415 for copyrights defined in the Internet Standards process must 416 be followed, or as required to translate it into languages 417 other than English. 419 The limited permissions granted above are perpetual and will 420 not be revoked by the Internet Society or its successors or 421 assigns. 423 This document and the information contained herein is provided 424 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 425 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 426 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 427 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 428 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 429 PARTICULAR PURPOSE.