As per Relevance of the word extension, we have this rfc below:
Network Working Group N.
Request for Comments: 2442 D.
Category: Informational
J.
Sun
M.
November 1998
Batch
Media
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document defines a MIME content type suitable for tunneling
ESMTP [RFC-821, RFC-1869] transaction through any MIME-
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
content. Making it possible to use specific SMTP extensions such
NOTARY [RFC-1891] over unextended SMTP transport infrastructure
Enabling the transfer of multiple separate messages in a
transactional unit
Requirements
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
requirements of this specification. A discussion of the meanings
the terms "MUST", "SHOULD", and "MAY" appears in [RFC-1123];
terms "MUST NOT" and "SHOULD NOT" are logical extensions of
usage
Freed, et. al. Informational [Page 1]
RFC 2442 Batch SMTP Media Type November 1998
The Application/batch-SMTP Content
The "application/batch-SMTP" MIME content type is a container for
client side of an SMTP or ESMTP transaction. In keeping
traditional SMTP, the contents are line oriented and CRLF
terminators MUST be used
The "application/batch-SMTP" type is defined as follows
Media type name:
Media subtype name: batch-
Required parameters:
Optional parameters: required-
Encoding considerations
8bit material may appear, so quoted-printable or base64
encoding may be necessary on transports that do
support 8bit. While the content of this type
line-oriented and uses conventional CR/LF terminators
lines longer than 7bit and 8bit encodings allow (998
octets) may appear, hence quoted-printable
base64 encoding may be necessary even in
with 8bit transports
Security considerations
Discussed in the Security Considerations Section
How application/batch-SMTP is
The following diagram illustrates how the application/batch-SMTP
is intended to be used
application/batch-SMTP
+----------------+
| |
+-----------+ v +----------+ v +-----------+
| batch | | MIME- | | batch |
=> | SMTP | => | capable | => | SMTP | =>
| generator | |transport | | processor |
^ +-----------+ +----------+ +-----------+ ^
| |
+-- conventional SMTP/RFC822 message transaction --+
A conventional SMTP message transaction is converted into
application/batch-SMTP object by the batch SMTP generator.
object is then carried over some type of MIME-capable transport.
the destination is reached the object is presented to a batch
processor, which converts the application/batch-SMTP object back
a conventional SMTP message transaction
Freed, et. al. Informational [Page 2]
RFC 2442 Batch SMTP Media Type November 1998
Generation of application/batch-SMTP
Application/batch-SMTP material is generated by a specially
SMTP client operating without a corresponding SMTP server. The
simply assumes a successful response to all commands it issues.
resulting content then consists of the collected output from the
client
Honoring SMTP
Most batch SMTP processors will be constructed by modifying
extending existing SMTP servers. As such, all of the restrictions
SMTP constructs imposed by RFC 821, RFC 1123, and RFC 1869 MUST
observed. In particular, restrictions on command and data
lengths, number of recipients, and so on still exist and apply
batch SMTP
Use of SMTP
Since no SMTP server is present the client must be prepared to
certain assumptions about which SMTP extensions can be used.
generator MAY assume that ESMTP [RFC-1869] facilities are available
that is, it is acceptable to use the EHLO command and
parameters on MAIL FROM and RCPT TO. If EHLO is used MAY assume
the 8bitMIME [RFC-1652], SIZE [RFC-1870], and NOTARY [RFC-1891]
extensions are available. In particular, NOTARY SHOULD be used.
create private bilateral agreements which specify the availability
additional SMTP extensions. Additional SMTP extensions MUST NOT
used in the absence of such an agreement, and, perhaps
importantly, a conformant generation of application/batch-
objects MUST be able to produce objects restricted to use of
extensions listed above
The "required-extensions" content type parameter MAY be used
communicate a list of the extensions actually used, specified as
comma-separated list of EHLO responses. If absent it defaults to
list "8bitMIME,SIZE,NOTARY". Any use by private bilateral
of additional or different extensions MUST be noted in
"required-extensions" parameter
Note that many SMTP extensions simply do not make sense in
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
Generators SHOULD attempt to minimize the number of messages
in a single application/batch-SMTP object. Ideally a
application/batch-SMTP object will be created for each message. Note
however, that some uses of application/batch-SMTP (e.g.,
bagging) may exist solely to take advantage of the multiple
in a single container capability of batch SMTP, so requiring
message per container is not possible
DISCUSSION: The SMTP protocol provides for the transfer of a
of messages over a single connection. This extends in a natural
to batch SMTP. However, the issues in batch SMTP are
different. Suppose, for example, that a batch SMTP processor
an application/batch-SMTP object containing two messages but
unable to process the second message because of a storage
failure. But suppose that not only does this failure
processing of the second message, it also precludes recording
the first message has already been processed. Subsequent
of the application/batch-SMTP could then lead to duplication of
first message
This issue is not materially different from the well-known
with SMTP synchronization that in practice often lead to
messages. Since this behavior is inherent in SMTP to begin with it
not incumbent on application/batch-SMTP to completely address
issue. Nevertheless, it seems prudent for application/batch-SMTP
try and not make matters even worse
Transport of application/batch-SMTP
Application/batch-SMTP objects may be transported by any
capable of preserving their MIME labelling, e.g., HTTP or SMTP
Transports MUST remain cognizant of the special nature
application/batch-SMTP. An application/batch-SMTP object contains
or more "frozen" SMTP message transactions. SMTP message
typically carry with them various assumptions about quality
service, e.g., that messages will either be delivered successfully
a nondelivery notification will be returned, that a
notification will be returned if delivery cannot be accomplished in
timely fashion, and so on. It is vital that the encapsulation
these objects for carriage over other forms of transport
interfere with these capabilities
Freed, et. al. Informational [Page 4]
RFC 2442 Batch SMTP Media Type November 1998
Processing of application/batch-SMTP
Processing of application/batch-SMTP material is considerably
complex than generating it. As might be expected, a
SMTP/ESMTP processor is used. However, since it cannot
information to the client, it must handle all error conditions
arise itself. In other words, a batch SMTP processor assumes both
responsibilities of a traditional SMTP server as well as part of
responsibilities of a traditional SMTP client
As such, a conforming processor: MUST check MIME content
information to insure that the material it has been presented with
labelled as application/batch-SMTP and doesn't specify any
the processor doesn't support in the "required-extensions" parameter
Application/batch-SMTP objects that employ an unsupported
SHOULD be forwarded to the local postmaster for manual inspection
handling. MUST accept any syntactically valid EHLO or HELO command
MUST accept any syntactically valid MAIL FROM command. A
processor, MAY, if it so desires, note the unacceptability of
part of a given MAIL FROM command and use this information
subsequently generate non-delivery notifications for any or
recipients. MUST accept any syntactically valid RCPT TO command.
conforming processor SHOULD note the unacceptability of some part
a given RCPT TO command and subsequently use this information
generate a non-delivery notification for this recipient in lieu
actually delivering the message. MUST accept any of the
parameters defined by the 8bitMIME, SIZE, and NOTARY SMTP
on the MAIL FROM and RCPT TO commands. MUST accept the DATA
even when no valid recipients are present. 8bit MIME messages MUST
accepted. MUST accept the RSET command and handle multiple
in a single application/batch-SMTP object. Processors MUST
each message in an application/batch-SMTP object once and SHOULD
whatever steps are necessary to avoid processing a message more
once. For example, if processing of an application/batch-SMTP
containing multiple messages is interrupted at an intermediate
it should subsequently be restarted at the end of the last
that was completely processed. SHOULD forward any
invalid application/batch-SMTP message to the local postmaster
manual inspection and handling
Security
Application/batch-SMTP implements a tunneling mechanism. In
tunneling mechanisms are prone to abuse because they may provide
means of bypassing existing security restrictions. For example,
application/batch-SMTP tunnel implemented over an existing
transport may allow someone to bypass relay restrictions imposed
block redistribution of spam
Freed, et. al. Informational [Page 5]
RFC 2442 Batch SMTP Media Type November 1998
Application/batch-SMTP processors SHOULD implement
restrictions designed to limit access to the processor to
generators only. (Note that this facility may be
automatically if application/batch-SMTP is being used to
message envelope information.)
The general concept of batch SMTP has been around for a long time
One particular type of batch SMTP was defined by Alan Crosswell
used on BITNET to overcome BITNET's native 8 character limit on
and host names. However, this form of batch SMTP differed from
current proposal in that it envisioned having the server return
status code responses to the client. In this case the client bore
burden of correlating responses with the original SMTP dialogue
the fact
Unfortunately this approach proved not to work well in practice
BITNET eventually switched to the same basic form of batch SMTP
has been defined here. Unfortunately that definition was, to the
of the present authors' knowledge, never captured in a
specification. It should also be noted that the definition given
also differs in that it takes SMTP extensions into account
Einar Stefferud had previously considered the problem of
extended SMTP messages over unextended SMTP transports. He
that some form of "double enveloping" technology be developed
address this problem. The mechanism presented here
implements the type of solution he proposed
[RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10,
RFC 821, August 1982.
[RFC-822] Crocker, D., "Standard for the Format of ARPA
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
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
for Message Size Declaration", STD 10, RFC 1870, November
1995.
[RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Extensions (MIME) Part One: Format of Internet
Bodies", RFC 2045, December 1996.
[RFC-2046] Freed, N. and N. Borenstein, "Multipurpose Internet
Extensions (MIME) Part Two: Media Types", RFC 2046,
December 1996.
[RFC-2197] Freed, N. and A. Cargille, "SMTP Service Extension
Command Pipelining", RFC 2197, September 1997.
Authors'
Ned
Innosoft International, Inc
1050 Lakes
West Covina, CA 91790
Phone: +1 626 919 3600
Fax: +1 626 919 3614
EMail: ned.freed@innosoft.
Dan
Innosoft International, Inc
1050 Lakes
West Covina, CA 91790
Phone: +1 626 919 3600
Fax: +1 626 919 3614
EMail: dan.newman@innosoft.
Freed, et. al. Informational [Page 7]
RFC 2442 Batch SMTP Media Type November 1998
Mark
Mainbrace
1136 West Evelyn
Sunnyvale, CA 94086
tel: +1 408 774 5265
fax: +1 408 774 5290
email: mark.hoy@mainbrace.
Jacques
Phone: +1 650 786 3630
EMail: jacques.belissent@eng.sun.
Freed, et. al. Informational [Page 8]
RFC 2442 Batch SMTP Media Type November 1998
Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this
are included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Freed, et. al. Informational [Page 9]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
