summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2442.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2442.txt')
-rw-r--r--doc/rfc/rfc2442.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc2442.txt b/doc/rfc/rfc2442.txt
new file mode 100644
index 0000000..b0e7154
--- /dev/null
+++ b/doc/rfc/rfc2442.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group N. Freed
+Request for Comments: 2442 D. Newman
+Category: Informational Innosoft
+ J. Belissent
+ Sun Microsystems
+ M. Hoy
+ Mainbrace
+ November 1998
+
+
+ The
+ Batch SMTP
+ Media Type
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+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: Extending end-to-end MIME-based security services (e.g.,
+ [RFC-1847]) to cover message envelope information as well as message
+ content. Making it possible to use specific SMTP extensions such as
+ NOTARY [RFC-1891] over unextended SMTP transport infrastructure.
+ Enabling the transfer of multiple separate messages in a single
+ transactional unit.
+
+Requirements Notation
+
+ This document occasionally uses terms that appear in capital letters.
+ When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+ appear capitalized, they are being used to indicate particular
+ requirements of this specification. A discussion of the meanings of
+ the terms "MUST", "SHOULD", and "MAY" appears in [RFC-1123]; the
+ terms "MUST NOT" and "SHOULD NOT" are logical extensions of this
+ usage.
+
+
+
+
+
+
+Freed, et. al. Informational [Page 1]
+
+RFC 2442 Batch SMTP Media Type November 1998
+
+
+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
+ 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.
+
+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.
+
+
+
+
+Freed, et. al. Informational [Page 2]
+
+RFC 2442 Batch SMTP Media Type November 1998
+
+
+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.
+
+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.
+
+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 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. If EHLO is used MAY assume that
+ the 8bitMIME [RFC-1652], SIZE [RFC-1870], and NOTARY [RFC-1891]
+ extensions are available. In particular, NOTARY SHOULD be used. 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 [RFC-
+ 2197] makes no sense in the absence of a network connection.
+
+
+
+
+
+
+
+
+Freed, et. al. Informational [Page 3]
+
+RFC 2442 Batch SMTP Media Type November 1998
+
+
+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 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 suppose that not only does this failure preclude
+ processing of the second message, it also precludes recording that
+ the first message has already been processed. Subsequent reprocessing
+ of the application/batch-SMTP could then lead 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.
+
+Transport 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 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.
+
+
+
+
+
+
+
+Freed, et. al. Informational [Page 4]
+
+RFC 2442 Batch SMTP Media Type November 1998
+
+
+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: 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. MUST accept any syntactically valid EHLO or HELO command.
+ 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. MUST accept any syntactically valid RCPT TO command. A
+ conforming processor SHOULD note the unacceptability of 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. MUST accept any of the additional
+ parameters defined by the 8bitMIME, SIZE, and NOTARY SMTP extensions
+ on the MAIL FROM and RCPT TO commands. MUST accept the DATA command
+ even when no valid recipients are present. 8bit MIME messages MUST be
+ accepted. 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. SHOULD forward any syntactically
+ invalid application/batch-SMTP message to the local postmaster for
+ manual inspection and handling.
+
+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.
+
+
+
+Freed, et. al. Informational [Page 5]
+
+RFC 2442 Batch SMTP Media Type November 1998
+
+
+ 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.)
+
+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.
+
+References
+
+ [RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10,
+ RFC 821, August 1982.
+
+ [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
+ Text Messages", STD 11, RFC 822 August 1982.
+
+ [RFC-1123] Braden, B., "Requirements for Internet Hosts --
+ Application and Support", STD 3, RFC 1123, October 1989.
+
+ [RFC-1652] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
+ Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
+ RFC 1652, July 1994.
+
+ [RFC-1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed,
+ "Security Multiparts for MIME: Multipart/Signed and
+ Multipart/Encrypted", RFC 1847, October 1995.
+
+
+
+Freed, et. al. Informational [Page 6]
+
+RFC 2442 Batch SMTP Media Type November 1998
+
+
+ [RFC-1869] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
+ Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
+ November 1995.
+
+ [RFC-1870] Klensin, J., Freed, N., Moore, K., "SMTP Service Extension
+ for Message Size Declaration", STD 10, RFC 1870, November,
+ 1995.
+
+ [RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, December 1996.
+
+ [RFC-2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part Two: Media Types", RFC 2046,
+ December 1996.
+
+ [RFC-2197] Freed, N. and A. Cargille, "SMTP Service Extension for
+ Command Pipelining", RFC 2197, September 1997.
+
+
+Authors' Addresses
+
+ Ned Freed
+ Innosoft International, Inc.
+ 1050 Lakes Drive
+ West Covina, CA 91790
+ USA
+
+ Phone: +1 626 919 3600
+ Fax: +1 626 919 3614
+ EMail: ned.freed@innosoft.com
+
+
+ Dan Newman
+ Innosoft International, Inc.
+ 1050 Lakes Drive
+ West Covina, CA 91790
+ USA
+
+ Phone: +1 626 919 3600
+ Fax: +1 626 919 3614
+ EMail: dan.newman@innosoft.com
+
+
+
+
+
+
+
+
+
+Freed, et. al. Informational [Page 7]
+
+RFC 2442 Batch SMTP Media Type November 1998
+
+
+ Mark Hoy
+ Mainbrace Corporation
+ 1136 West Evelyn Avenue
+ Sunnyvale, CA 94086
+
+ tel: +1 408 774 5265
+ fax: +1 408 774 5290
+ email: mark.hoy@mainbrace.com
+
+
+ Jacques Bellisent
+ SunSoft
+
+ Phone: +1 650 786 3630
+ EMail: jacques.belissent@eng.sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed, et. al. Informational [Page 8]
+
+RFC 2442 Batch SMTP Media Type November 1998
+
+
+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 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed, et. al. Informational [Page 9]
+