As per Relevance of the word services, we have this rfc below:
Network Working Group N. Borenstein,
Request for Comments: 1344 June 1992
Implications of MIME for Internet Mail
Status of This
This is an informational memo for the Internet community
and requests discussion and suggestions for improvements
This memo does not specify an Internet standard
Distribution of this memo is unlimited
The recent development of MIME (Multipurpose Internet
Extensions) offers a wide range of new opportunities
electronic mail system systems. Most of these
are relevant only to user agents, the programs that
with human users when they send and receive mail. However
some opportunities are also opened up for mail
systems. While MIME was carefully designed so that it
not require any changes to Internet electronic
transport facilities, there are several ways in
message transport systems may want to take advantage
MIME. These opportunities are the subject of this memo
Background -- The MIME
Recently, a new standardized format has been defined
enhanced electronic mail messages on the Internet.
format, known as MIME, permits messages to include, in
standardized manner, non-ASCII text, images, audio, and
variety of other kinds of interesting data
The MIME effort was explicitly focused on
absolutely no changes at the message transport level
Because of this fact, MIME-format mail runs transparently
all known Internet or Internet-style mail systems.
means that those concerned solely with the maintenance
development of message transport services can safely
MIME completely, if they so choose
However, the fact that MIME can be ignored, for the
of message transport, does not necessarily mean that
should be ignored. In particular, MIME offers
features that should be of interest to those responsible
message transport services. By exploiting these features
transport systems can provide certain additional kinds
service that are currently unavailable, and can alleviate
few existing problems
The remainder of this document is an attempt to
point out and summarize some important ways in which
Borenstein [Page 1]
RFC 1344 MIME and Mail Gateways June 1992
may be of use for message transport systems. This
makes no attempt to present a complete technical
of MIME, however. For that, the reader is refered to
MIME document itself [RFC-1341].
Mail Transport and Gateway Services: A Key
Before implementing any of the mechanisms discussed in
memo, one should be familiar with the distinction
mail transport service and mail gateway service. Basically
mail transport software is responsible for moving a
within a homogeneous electronic mail service network.
gateways, on the other hand, exchange mail between
significantly different mail environments, including
non-electronic services, such as postal mail
In general, it is widely considered unacceptable for
transport services to alter the contents of messages.
the case of mail gateways, however, such alteration is
inevitable. Thus, strictly speaking, many of the
described here apply only to gateways, and should not
used in simple mail transport systems. However, it
possible that some very special situations -- e.g., an
relay that transports mail across extremely
intercontinental network links -- might need to
messages, in order to provide appropriate service for
situations, and hence must redefine its role to be that of
gateway
In this memo, it is assumed that transformations which
a message's contents will be performed only by gateways,
it is recognized that some existing mail transport
may choose to reclassify themselves as gateways in order
perform the functions described here
Rejected
An unfortunately frequent duty of message transport
is the rejection of mail to the sender. This may
because the mail was undeliverable, or because it did
conform to the requirements of a gateway (e.g., it was
large).
There has never been a standard format for rejected
in the past. This has been an annoyance, but not a
problem for text messages. For non-text messages, however
the lack of a standard rejection format is more crucial
because rejected messages typically appear to be text,
the user who finds himself viewing images or audio as
they were text is rarely happy with the result
MIME makes it very easy to encapsulate messages in such
way that their semantics are completely preserved.
simplest way to do this is to make each rejection notice
Borenstein [Page 2]
RFC 1344 MIME and Mail Gateways June 1992
MIME "multipart/mixed" message. That multipart
would contain two parts, a text part explaining the
for the rejection, and an encapsulated message part
contained the rejected message itself
It should be stressed that the transport software does
need to understand the structure of the rejected message
all. It merely needs to encapsulate it properly.
following, for example, shows how any MIME message may
encapsulated in a rejection message in such a way that
information will be immediately visible in the correct
if the recipient reads it with a MIME-conformant
reader
From: Mailer-Daemon
Subject: Rejected
Content-type: multipart/mixed; boundary=unique-
--unique-
Content-type: text/plain; charset=us-
A mail message you sent was rejected. The details
the rejected message are as follows
From: Nathainel Borenstein
Message-ID: <12345@bellcore.com
To: bush@whitehouse.
Subject: I know my rights
Rejection-reason: No mail from libertarians
accepted
The original message follows below
--unique-
Content-type: message/rfc822
The ENTIRE REJECTED MESSAGE, starting with the headers
goes here
--unique-boundary--
In the above example, the ONLY thing that is
'boilerplate" is the choice of boundary string. The
"unique-boundary" should be replaced by a string that
not appear (prefixed by two hyphens) in any of the
parts
Encapsulating a message in this manner is very easily done
and will constitute a significant service that
transport services can perform for MIME users
IMPORTANT NOTE: The format given above is simply one
many possible ways to format a rejection message using MIME
Independent IETF efforts are needed in order to
the format of rejections and acknowledgements
Borenstein [Page 3]
RFC 1344 MIME and Mail Gateways June 1992
Fragmenting and Reassembling Large
One problem that occurs with increasing frequency
Internet mail is the rejection of messages because of
limitations. This problem can be expected to
substantially more severe with the acceptance of MIME,
MIME invites the use of very large objects such as
and audio clips. Fortunately, MIME also provides
that can help alleviate the problem
One particularly relevant MIME type is "message/partial",
which can be used for the automatic fragmentation
reassembly of large mail messages. The message/partial
can be handled entirely at the user agent level, but
transport services can also make use of this type to
more intelligent behavior at gateways
In particular, when gatewaying mail to or from a system
network known to enforce size limitations that are more
less stringent than are enforced locally, message
services might choose either to break a large message
fragments, or (perhaps less likely) to reassemble
into a larger message. The combination of these
behaviors can make the overall Internet mail
appear more complete and seamless than it actually is
Details on the message/partial format may be found in
MIME document. What follows is an example of how a
short message might be broken into two message/
messages. In practice, of course, the message/
facility would only be likely to be used for much
messages
The following initial message
From: Nathaniel Borenstein
To: Ned Freed:
Subject: a test
Content-type: image/
Content-Transfer-Encoding: base64
R0lGODdhQAGMAbMAAAAAAP/u7swzIu6ZiLsiEd1EM+5VRGaI3WYAAO67
uwARd6q7/ywAAAAAQAGMAUME/hDISau9OOvNu/9gKI6kRJwoUa5s675wLM90
XW5YKxqPyKRygxv2dr4czwlMCZrQLFTYHBJ2hlyQYFiaz+i0WWBou7fOq1x8
qU1fJ2qEhYaHGjhZQmJ2QT1xBW1ak1xUdV0/VjtsbpUEDaEJCQOIpqeoNV+LXo5
fVN3dZKceAQPvgyhwQ2lqcXGxx5wja59eJIGUNCszF90sYp50CoqFZ4DoqMMo6
can be transformed, invertibly, into the following
message/partial messages
From: Nathaniel Borenstein
Borenstein [Page 4]
RFC 1344 MIME and Mail Gateways June 1992
To: Ned Freed
Subject: a test
Content-type: message/partial; id="xyx@host.com";
number=1; total=2
Content-type: image/
Content-Transfer-Encoding: base64
R0lGODdhQAGMAbMAAAAAAP/u7swzIu6ZiLsiEd1EM+5VRGaI3WYAAO67
From: Nathaniel Borenstein
To: Ned Freed
Subject: a test
Content-type: message/partial; id="xyx@host.com";
number=2; total=2
uwARd6q7/ywAAAAAQAGMAUME/hDISau9OOvNu/9gKI6kRJwoUa5s675wLM90
XW5YKxqPyKRygxv2dr4czwlMCZrQLFTYHBJ2hlyQYFiaz+i0WWBou7fOq1x8
qU1fJ2qEhYaHGjhZQmJ2QT1xBW1ak1xUdV0/VjtsbpUEDaEJCQOIpqeoNV+LXo5
fVN3dZKceAQPvgyhwQ2lqcXGxx5wja59eJIGUNCszF90sYp50CoqFZ4DoqMMo6
Fragmenting such messages rather than rejecting them
be a reasonable option for some gateway services, at
for a certain range of message sizes. Of course, it
often difficult for a gateway to know what size
will be encountered "downstream", but intelligent
are often possible. Moreover, an IETF working group on
extensions has proposed augmenting SMTP with a "SIZE"
that would facilitate this process, thereby
requiring fragmentation on the fly during
transmission
Note also that fragmentation or reassembly might
be performed, in differing circumstances, by either
sending or receiving gateway systems, depending on
system knew more about the capabilities of the other
Using or Removing External-Body
Another MIME type oriented to extremely large messages
the "message/external-body" type. In this type of message
all or part of the body data is not included in the
message itself. Instead, the Content-Type header
includes information that tells how the body data can
retrieved -- either via a file system, via anonymous ftp,
via other mechanisms
The message/external-body type provides a new option
mail transport services that wishes to optimize the
bandwidth resources are used in a given environment.
example, the basic use of message/external-body is to
bandwidth in email traffic. However, when email crosses
Borenstein [Page 5]
RFC 1344 MIME and Mail Gateways June 1992
slow and expensive boundary -- e.g., a satellite link
the Pacific -- it might make sense to retrieve the
itself and transform the external-body reference into
actual data. Alternately, it might make sense to copy
data itself to a new location, closer to the
recipients, and change the location pointed to in
message. Because the external-body specification
include an expiration date, message transport services
trade off storage and bandwidth capabilities to try
optimize the overall use of resources for very
messages
Such behaviors by a gateway require careful analysis
cost/benefit tradeoffs and would be a dramatic
from typical mail transport services. However,
potential benefits are quite significant, so that such
appropriate use of these service options should be explored
For example, the following message includes PostScript
by external reference
From: Nathaniel Borenstein
To: Ned Freed
Subject: The latest MIME
Content-Type: message/external-body
name="BodyFormats.ps";
site="thumper.bellcore.com";
access-type=ANON-FTP
directory="pub";
mode="image";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
Content-type: application/
A gateway to Australia might choose to copy the file to
Australian FTP archive, changing the relevant parameters
the Content-type header field. Alternately, it might
simply to transform the message into one in which all
data were included
From: Nathaniel Borenstein
To: Ned Freed
Subject: The latest MIME
Content-type: application/
%!PS-Adobe-1.0
%%Creator: greenbush:nsb (Nathaniel Borenstein,MRE 2A
274,4270,9938586,21462)
etc...
This is an example which suggests both the benefits and
dangers. There is considerable benefit to having a copy
the data immediately available, but there also may
considerable expense involved in transporting it to all
Borenstein [Page 6]
RFC 1344 MIME and Mail Gateways June 1992
a the members of a list, if only a few will use the
anytime soon
Alternatively, instead of replacing an external-body
with its real contents, it might make sense to transform
into a "multipart/alternative" message containing both
external body reference and the expanded version.
means that only the external body part can be forwarded
desired, and the recipient doesn't lose the information
to where the data was fetched from, if they want to fetch
up-to-date version in the future. Such information could
represented, in MIME, in the following form
From: Nathaniel Borenstein
To: Ned Freed
Subject: The latest MIME
Content-type: multipart/alternative; boundary=
--
Content-Type: message/external-body
name="BodyFormats.ps";
site="thumper.bellcore.com";
access-type=ANON-FTP
directory="pub";
mode="image";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
Content-type: application/
--
Content-type: application/
%!PS-Adobe-1.0
%%Creator: greenbush:nsb (Nathaniel Borenstein,MRE 2A
274,4270,9938586,21462)
etc...
--foo--
Similarly for the case where a message is copied to a
FTP site, one could offer two external body parts as
alternatives, allowing the user agent to choose which
site is preferred
Image and other Format
MIME currently defines two image formats, image/gif
image/jpeg. The former is much more convenient for
users, and can be displayed more quickly on many systems
The latter is a much more compact representation,
therfore places less stress on mail transport facilities
Message transport services can optimize both
bandwidth and user convenience by intelligent
between these formats (and other formats that might be
later). When a message of type image/gif is submitted
Borenstein [Page 7]
RFC 1344 MIME and Mail Gateways June 1992
long-haul delivery, it might reasonably be translated
image/jpeg. Conversely, when image/jpeg data is
for final delivery on a system with adequate
resources, it might be translated to image/gif for
convenience of the recipient. Software to perform
translations is widely available. It should be noted
however, that performance of such conversions
support for the new format by the recipient
Although MIME currently only defines one audio format,
are likely to be defined and registered with IANA in
future. In that case, similar format conversion
might be appropriate for audio
If format conversion is done, it is STRONGLY
that some kind of trace information (probably in the form
a Received header field) should be added to a message
document the conversion that has been performed
Some people have expressed concerns, or even the
that conversions should never be done. To accomodate
desires of those who dislike the idea of automatic
conversion. For this reason, it is suggested that
transformations be generally restricted to gateways
than general message transport services, and that
which perform such conversions should be sensitive to
header field that indicates that the sender does not wish
have any such conversions performed. A suggested value
this header field is
Content-Conversion:
User agents that wish to explicitly indicate a
for such conversions to be performed may use
Content-Conversion:
However, this will be the default assumption of
gateways, so this header field is not strictly necessary
It also should be noted that such control of
would only be available to the sender, rather than to any
the recipients
Borenstein [Page 8]
RFC 1344 MIME and Mail Gateways June 1992
Robust Encoding of
In addition to all the reasons given above for
transformation of body data, it will sometimes be the
that a gateway can tell that the body data, as given,
not robustly survive the next step of transport.
example, mail crossing an ASCII-to-EBCDIC gateway will
information if certain characters are used. In such cases
a gateway can make the data more robust simply by
one of the MIME Content-Transfer-Encoding algorithms (base64
or quoted-printable) to the body or body part. This
generally be a loss-less transformation, but care must
taken to ensure that the resulting message is MIME
conformant if the inital message was not. (For example,
MIME-Version header field may need to be added.)
User-oriented
If a gateway is going to perform major transformations on
mail message, such as translating image formats or
between included data and external-reference data, it
inevitable that there will be situations in which users
object to these transformations. This is, in large part,
implementation issue, but it seems advisable,
possible, to provide a mechanism whereby users can specify
to the transport system, whether or not they want
services performed automatically on their behalf. The use
the "Content-Conversion" header field, as mentioned above
is suggested for this purpose, since it it least
some control by the sender, if not the recipient
[RFC-1341] Borenstein, N., and N. Freed, "
(Multipurpose Internet Mail Extensions): Mechanisms
Specifying and Describing the Format of Internet
Bodies", RFC 1341, Bellcore, June, 1992.
Security
Security issues are not discussed in this memo
Author's
Nathaniel S.
MRE 2D-296,
445 South St
Morristown, NJ 07962-1910
Email: nsb@bellcore.
Phone: +1 201 829 4270
Fax: +1 201 829 7019
Borenstein [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
