The Batch SMTP Media Type
The information below is for an old version of the document that is already published as an RFC.
This is an older version of an Internet-Draft that was ultimately published as RFC 2442.
|Authors||Ned Freed , Dr. Daniel Newman|
|Last updated||2013-03-02 (Latest revision 1998-09-10)|
|RFC stream||Legacy stream|
|RFC Editor Note||(None)|
|IESG||IESG state||RFC 2442 (Informational)|
|Send notices to||(None)|
Network Working Group Ned Freed, Innosoft Internet Draft Dan Newman, Innosoft <draft-freed-bsmtp-01.txt> Mark Hoy, SunSoft Jacques Belissent, SunSoft The Batch SMTP Media Type August 1998 Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Copyright (C) The Internet Society (1998). All Rights Reserved. 1. Abstract This document defines a MIME content type suitable for tunneling an ESMTP [RFC-821, RFC-1869] transaction through any MIME-capable transport. This type can be used for a variety of purposes, including: Internet Draft Batch SMTP August 1998 (1) Extending end-to-end MIME-based security services (e.g., [RFC-1847]) to cover message envelope information as well as message content. (2) Making it possible to use specific SMTP extensions such as NOTARY [RFC-1891] over unextended SMTP transport infrastructure. (3) Enabling the transfer of multiple separate messages in a single transactional unit. 1.1. Requirements Notation This document occasionally uses terms that appear in capital letters. When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of these terms appears in [RFC- 2119]. 2. The Application/batch-SMTP Content Type The "application/batch-SMTP" MIME content type is a container for the client side of an SMTP or ESMTP transaction. In keeping with traditional SMTP, the contents are line oriented and CRLF line terminators MUST be used. The "application/batch-SMTP" type is defined as follows: Media type name: application Media subtype name: batch-SMTP Required parameters: none Optional parameters: required-extensions Expires February 1999 [Page 2] Internet Draft Batch SMTP August 1998 Encoding considerations: 8bit material may appear, so quoted-printable or base64 encoding may be necessary on transports that do not support 8bit. While the content of this type is line-oriented and uses conventional CR/LF terminators, lines longer than 7bit and 8bit encodings allow (998 octets) may appear, hence quoted-printable or base64 encoding may be necessary even in conjunction with 8bit transports. Security considerations: Discussed in the Security Considerations Section. 3. How application/batch-SMTP is used The following diagram illustrates how the application/batch- SMTP type is intended to be used: application/batch-SMTP object +----------------+ | | +-----------+ v +----------+ v +-----------+ | batch | | MIME- | | batch | => | SMTP | => | capable | => | SMTP | => | generator | |transport | | processor | ^ +-----------+ +----------+ +-----------+ ^ | | +-- conventional SMTP/RFC822 message transaction --+ A conventional SMTP message transaction is converted into an application/batch-SMTP object by the batch SMTP generator. This object is then carried over some type of MIME-capable transport. Once the destination is reached the object is presented to a batch SMTP processor, which converts the application/batch-SMTP object back into a conventional SMTP message transaction. 4. Generation of application/batch-SMTP material Application/batch-SMTP material is generated by a specially modified SMTP client operating without a corresponding SMTP server. The client simply assumes a successful response to all commands it issues. The resulting content then consists of the collected output from the SMTP client. Expires February 1999 [Page 3] Internet Draft Batch SMTP August 1998 4.1. Honoring SMTP restrictions Most batch SMTP processors will be constructed by modifying and extending existing SMTP servers. As such, all of the restrictions on SMTP constructs imposed by RFC 821, RFC 1123, and RFC 1869 MUST be observed. In particular, restrictions on command and data line lengths, number of recipients, and so on still exist and apply to batch SMTP. 4.2. Use of SMTP Extensions Since no SMTP server is present the client must be prepared to make certain assumptions about which SMTP extensions can be used. The generator (1) MAY assume that ESMTP [RFC-1869] facilities are available, that is, it is acceptable to use the EHLO command and additional parameters on MAIL FROM and RCPT TO. (2) If EHLO is used MAY assume that the 8bitMIME [RFC- 1652], SIZE [RFC-1653], and NOTARY [RFC-1891] extensions are available. In particular, NOTARY SHOULD be used. (3) MAY create private bilateral agreements which specify the availability of additional SMTP extensions. Additional SMTP extensions MUST NOT be used in the absence of such an agreement, and, perhaps more importantly, a conformant generation of application/batch-SMTP objects MUST be able to produce objects restricted to use of the extensions listed above. The "required-extensions" content type parameter MAY be used to communicate a list of the extensions actually used, specified as a comma-separated list of EHLO responses. If absent it defaults to the list "8bitMIME,SIZE,NOTARY". Any use by private bilateral agreement of additional or different extensions MUST be noted in the "required-extensions" parameter. Note that many SMTP extensions simply do not make sense in the context of batch SMTP. For example, the pipelining extension Expires February 1999 [Page 4] Internet Draft Batch SMTP August 1998 [RFC-1854] makes no sense in the absence of a network connection. 4.3. Handling Multiple Messages Generators SHOULD attempt to minimize the number of messages placed in a single application/batch-SMTP object. Ideally a single application/batch-SMTP object will be created for each message. Note, however, that some uses of application/batch- SMTP (e.g., mail bagging) may exist solely to take advantage of the multiple messages in a single container capability of batch SMTP, so requiring a one message per container is not possible. DISCUSSION: The SMTP protocol provides for the transfer of a series of messages over a single connection. This extends in a natural way to batch SMTP. However, the issues in batch SMTP are somewhat different. Suppose, for example, that a batch SMTP processor receives an application/batch-SMTP object containing two messages but is unable to process the second message because of a storage allocation failure. But not only does this failure preclude processing of the second message, it also precludes requeuing or otherwise noting that the first message has already been processed. Subsequent reprocessing of the application/batch-SMTP then leads to duplication of the first message. This issue is not materially different from the well-known problems with SMTP synchronization that in practice often lead to duplicated messages. Since this behavior is inherent in SMTP to begin with it is not incumbent on application/batch- SMTP to completely address the issue. Nevertheless, it seems prudent for application/batch-SMTP to try and not make matters even worse. 5. Tranport of application/batch-SMTP objects Application/batch-SMTP objects may be transported by any transport capable of preserving their MIME labelling, e.g., HTTP or SMTP. Transports MUST remain cognizant of the special nature of application/batch-SMTP. An application/batch-SMTP object Expires February 1999 [Page 5] Internet Draft Batch SMTP August 1998 contains one or more "frozen" SMTP message transactions. SMTP message transactions typically carry with them various assumptions about quality of service, e.g., that messages will either be delivered successfully or a nondelivery notification will be returned, that a nondelivery notification will be returned if delivery cannot be accomplished in a timely fashion, and so on. It is vital that the encapsulation of these objects for carriage over other forms of transport not interfere with these capabilities. 6. Processing of application/batch-SMTP material Processing of application/batch-SMTP material is considerably more complex than generating it. As might be expected, a modified SMTP/ESMTP processor is used. However, since it cannot return information to the client, it must handle all error conditions that arise itself. In other words, a batch SMTP processor assumes both the responsibilities of a traditional SMTP server as well as part of the responsibilities of a traditional SMTP client. As such, a conforming processor: (1) MUST check MIME content type information to insure that the material it has been presented with is labelled as application/batch-SMTP and doesn't specify any extensions the processor doesn't support in the "required-extensions" parameter. Application/batch-SMTP objects that employ an unsupported extension SHOULD be forwarded to the local postmaster for manual inspection and handling. (2) MUST accept any syntactically valid EHLO or HELO command. (3) MUST accept any syntactically valid MAIL FROM command. A conforming processor, MAY, if it so desires, note the unacceptability of some part of a given MAIL FROM command and use this information to subsequently generate non-delivery notifications for any or all recipients. (4) MUST accept any syntactically valid RCPT TO command. A conforming processor SHOULD note the unacceptability of Expires February 1999 [Page 6] Internet Draft Batch SMTP August 1998 some part of a given RCPT TO command and subsequently use this information to generate a non-delivery notification for this recipient in lieu of actually delivering the message. (5) MUST accept any of the additional parameters defined by the 8bitMIME, SIZE, and NOTARY SMTP extensions on the MAIL FROM and RCPT TO commands. (6) MUST accept the DATA command even when no valid recipients are present. 8bit MIME messages MUST be accepted. (7) MUST accept the RSET command and handle multiple messages in a single application/batch-SMTP object. Processors MUST process each message in an application/batch-SMTP object once and SHOULD take whatever steps are necessary to avoid processing a message more than once. For example, if processing of an application/batch-SMTP object containing multiple messages is interrupted at an intermediate point it should subsequently be restarted at the end of the last message that was completely processed. (8) SHOULD forward any syntactically invalid application/batch-SMTP message to the local postmaster for manual inspection and handling. 7. Security Considerations Application/batch-SMTP implements a tunneling mechanism. In general tunneling mechanisms are prone to abuse because they may provide a means of bypassing existing security restrictions. For example, an application/batch-SMTP tunnel implemented over an existing SMTP transport may allow someone to bypass relay restrictions imposed to block redistribution of spam. Application/batch-SMTP processors SHOULD implement access restrictions designed to limit access to the processor to authorized generators only. (Note that this facility may be provided automatically if application/batch-SMTP is being used to secure message envelope information.) Expires February 1999 [Page 7] Internet Draft Batch SMTP August 1998 8. Acknowledgements The general concept of batch SMTP has been around for a long time. One particular type of batch SMTP was defined by Alan Crosswell and used on BITNET to overcome BITNET's native 8 character limit on user and host names. However, this form of batch SMTP differed from the current proposal in that it envisioned having the server return the status code responses to the client. In this case the client bore the burden of correlating responses with the original SMTP dialogue after the fact. Unfortunately this approach proved not to work well in practice. BITNET eventually switched to the same basic form of batch SMTP that has been defined here. Unfortunately that definition was, to the best of the present authors' knowledge, never captured in a formal specification. It should also be noted that the definition given here also differs in that it takes SMTP extensions into account. Einar Stefferud had previously considered the problem of carrying extended SMTP messages over unextended SMTP transports. He proposed that some form of "double enveloping" technology be developed to address this problem. The mechanism presented here effectively implements the type of solution he proposed. 9. References [RFC-821] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August, 1982. [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822 August, 1982. Expires February 1999 [Page 8] Internet Draft Batch SMTP August 1998 [RFC-1123] Braden, B., "Requirements for Internet Hosts -- Application and Support", RFC 1123, STD 3, October 1989. [RFC-1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker, D., "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July, 1994. [RFC-1653] Klensin, J., Freed, N., Moore, K., "SMTP Service Extension for Message Size Declaration", RFC 1653, July, 1994. [RFC-1847] Galvin, J., Murphy, S., Crocker, S., Freed, N., " Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October, 1995. [RFC-1854] Freed, N., Cargille, A., "SMTP Service Extension for Command Pipelining", RFC 1854, October, 1995. [RFC-1869] Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker, D., "SMTP Service Extensions", RFC 1869, STD 10, November, 1995. [RFC-2045] Freed, N. and Borenstein, N., "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft, First Virtual Holdings, December, 1996. [RFC-2046] Freed, N. and Borenstein, N., "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft, First Virtual Holdings, December, 1996. Expires February 1999 [Page 9] Internet Draft Batch SMTP August 1998 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March, 1997. 10. Authors' Addresses Ned Freed Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA tel: +1 626 919 3600 fax: +1 626 919 3614 email: firstname.lastname@example.org Dan Newman Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA tel: +1 626 919 3600 fax: +1 626 919 3614 email: email@example.com Mark Hoy SunSoft Jacques Bellisent SunSoft 11. Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose Expires February 1999 [Page 10] Internet Draft Batch SMTP August 1998 of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires February 1999 [Page 11]