The Batch SMTP Media Type
draft-freed-bsmtp-01

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: ned.freed@innosoft.com

Dan Newman
Innosoft International, Inc.
1050 Lakes Drive
West Covina, CA 91790
USA
 tel: +1 626 919 3600           fax: +1 626 919 3614
 email: ned.freed@innosoft.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]