rfc2442.txt

RFC 的详细文档！

   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: [phone]
   Fax:   [phone]
   EMail: [e-mail]


   Dan Newman
   Innosoft International, Inc.
   1050 Lakes Drive
   West Covina, CA 91790
   USA

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]









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: [phone]
   fax: [phone]
   email: [e-mail]


   Jacques Bellisent
   SunSoft

   Phone: [phone]
   EMail: [e-mail]




































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]