comp.mail.mime FAQ, part 3 of 9 (frequently asked questions list)
MIME FAQ maintainer
Archive-Name: mail/mime-faq/part3
Version: $Id: mime3,v 3.23 1997/06/11 23:27:11 jsweet Rel $
Posting-Frequency: monthly
--
==========================================================
comp.mail.mime frequently asked questions list (FAQ) (3/9)
==========================================================
Part 3: Advanced MIME topics
~~~~~~
--
Overview
--------
This is part 3 of a Frequently Asked Questions document about MIME, the
multipurpose and multi-media standard for Internet mail.
The table of contents is in part 1.
--
3) Advanced MIME topics
--
3.1) So, does MIME introduce any new security problems?
Yes. MIME user agents can do previously unheard of things with mail
messages, notably giving them as input to other programs.
PostScript is probably the biggest potential security hole. One
famous example is the "melting screen" PostScript program, which
destroys screens maintained by Display PostScript implementations. For
another example, PostScript can be used to change the password on some
PostScript printers with previously undefined passwords, which denies
the use of the printer until the printer's password can (somehow) be
changed back. Yet other Display PostScript implementations may allow
file operations. (NeXTstep wisely disables file operations. With
GhostScript, they can be disabled by the "-dSAFER" command line option.
Use of this option (in mailcap, etc.) is highly recommended.)
The enumeration of these security holes is not to be interpreted as
encouragement to exploit the holes. They are mentioned only because
they are well known. Refer to books such as "Practical UNIX Security"
and to news groups such as comp.security.misc for general information
about system security.
--
3.2) What about security and privacy issues?
Both users and administrators should be aware that ordinary Internet
and UUCP e-mail is not secure. No authentication, confidentiality, or
data integrity properties are provided in SMTP, RFC 822, or MIME.
Persons desiring any or all of those security properties in their
e-mail should look into the use of Privacy-Enhanced Mail (PEM). Other
forms of e-mail security, such as PGP (Pretty Good Privacy), are also
available.
[ Raph Levien <ra...@kiwi.cs.berkeley.edu> 19-Feb-1996 ]
I just wrote a survey of five proposals for email encryption: MOSS,
MSP, PGP, PGP/MIME, and S/MIME (in alphabetical order). It's
available on the Web at:
http://www.c2.org/~raph/comparison.html
3.2.1) PEM
At least one no-cost implementation of PEM is available in the US and
Canada. There are also a number of implementations being developed in
Europe (hopefully these shall not suffer the same restrictions on
export).
See also the following RFCs:
RFC 1421 through RFC 1424 - PEM
RFC 1847 - Security Multiparts for MIME
RFC 1848 - MIME Object Security Services
3.2.2) MOSS
[ James M Galvin <tismoss...@tis.com> 13-Sep-1995 ]
MOSS is a Privacy Enhanced Mail (PEM) derivative that is a
proposed internet standard for adding security services to MIME.
MOSS uses the cryptographic techniques of digital signature and
encryption to provide origin authentication, integrity, and
confidentiality to MIME objects.
TIS/MOSS is a reference implementation of MIME Object Security
Services (MOSS) [RFC 1848]...a security toolkit that provides
digital signature and encryption services for MIME objects.
3.2.3) PGP
A system providing similar functionality to PEM implementations is PGP.
PGP is an implementation, not a specification, and it does not carry
the blessing of the IETF, or any other body. It is, however,
available at no cost throughout the world (although its status with
respect to certain US patents is dubious). Caveat emptor.
[ "Jeffrey I. Schiller" <j...@mit.edu> 24-Jun-1994 ]
There is now a freeware version of PGP that is not dubious from a
patent standpoint.
Bi...@yrkpa.kias.com notes the existence of the PGP FAQ from
alt.security.pgp. In addition to enumerating various implementations,
the PGP FAQ document indicates that information about how to obtain
the officially blessed version of PGP is available from:
http://web.mit.edu/network/pgp-form.html
There is also an O'Reilly book out on the subject of PGP. It
contains, among other useful information, an unflinching report
on how PGP came to be.
[ Michael Elkins <elk...@aero.org> 18-Dec-1995 ]
If you are interested in joining the discussion of issues on a
standard for use of PGP to encrypt/sign Internet e-mail messages using
MIME, you may be interested in this list. I highly encourage everyone
who is working on incorporating PGP into a mail client to join, even
if you don't participate in the discussion, since it will be the best
source of information about the developing proposed standard.
To join the list, send mail to
pgp-mime...@lists.uchicago.edu
with a subject of "subscribe".
Submissions should be sent to
pgp-...@lists.uchicago.edu
[ Raph Levien <ra...@kiwi.cs.berkeley.edu> 16-Dec-1995 ]
I've got a collection of information about this proposed standard on
my PGP/MIME Web page:
http://www.c2.org/~raph/pgpmime.html
[ Ned Freed <Ned....@innosoft.com> 19-Jul-1996 ]
A document describing how to combine RFC 1847 and PGP was recently
accepted as a proposed standard. [ See RFC 2015. ]
The old "let's do this via an encoding" theme has been discussed
ad nauseum in at least two other forums (pem-dev and pgp-mime),
and the conclusion is and has always been that encryption via encoding
is a total nonstarter.
3.2.4) S/MIME
[ Ned Freed <Ned....@innosoft.com> 18-Oct-96 ]
S/MIME was only recently published as an Internet Draft. If the
handling of security-related matters in the IETF runs true to previous
form for S/MIME, we're at least a year away from it becoming a
standards-track RFC, and probably a whole lot longer.
[ Kee Hinckley <naz...@utopia.com> 18-Oct-96 ]
It is, however, pretty clear from anyone who has read Netscape's
releases, or been to Internet Expo, that standard or not, people will
be using it (and claiming it as a standard) in less than six months.
The good news is that several of the companies I spoke to were talking
to each other to guarantee interoperability.
--
3.3) What's "text/enriched"?
The text/enriched type offers simple text markup, without making the
text unreadable to someone without the software to interpret it.
The text/enriched scheme uses markup commands enclosed in angle
brackets. For example, here is how you would <bold>embolden</bold> a
single word.
The text/enriched type is defined in RFC 1896. It supersedes
text/richtext, which was defined in RFC 1341 (obs.). See part 3 of
this FAQ for information about how to obtain RFCs.
A freely available implementation of a viewer for text/enriched is
part of the metamail 2.7 "richtext" program, via the undocumented
command line option "-e". See appendix B of this FAQ for details
about metamail.
Other markup language proposals have been made. One is simplemail,
which is more like a standardization of certain existing practices in
mail and news articles. For example, here is how you would *emphasize*
a single word.
Simplemail is explained in an Internet Draft by Bill Janssen and Evan
Kirshenbaum. See part 3 of this FAQ for information about how to
obtain Internet Drafts.
--
3.4) What about a group 3 facsimile encoding?
There is an X.400-conformant G3 facsimile type for MIME, "image/g3fax".
The specifications are in the MIME-MHS documents.
{ What current commercial and non-commercial software packages implement
viewers or generators for the image/g3fax content type per se, as opposed
to fax image rendering for other MIME content types? And which of these
interoperate with the remote printing experimental domain "TPC.INT"? }
The early MIME specification did not include a G3 facsimile type, but
there were some efforts along these lines anyway:
[ Stuart Lynne <s...@wimsey.com> 30-Dec-1992 ]
I have prototype scripts operating with metamail to do some of this.
Some of it is in contrib directory.
Currently I have 2 scripts:
mm2fax - convert mail and metamail messages to TIFF/F (uses various
tools to convert different body parts to TIFF/F);
faxmm - send rfc822 and mime e-mail messages via facsimile (uses
mm2fax to convert to TIFF/F).
[ Ned Freed <n...@innosoft.com> 31-Dec-1992 ]
PMDF-FAX is a set of channel programs for PMDF that provide
facilities for converting text, PostScript, and various other
formats into Group 3 FAX, as well as a set of programs that take
these Group 3 FAX files and use them to drive a variety of FAX
modems. MIME is used throughout to provide type information,
multipart facilities, and so forth. PMDF-FAX was developed with MIME
in mind from the outset.
See also: news:comp.mail.misc - "FAQ: How can I send a fax from the Internet?"
--
3.5) Should I always use external body parts to save space?
Not necessarily. In many cases, for example, at the ends of UUCP
connections, your recipients may not be able to retrieve external body
parts easily. It depends on your audience. Making files available via
a mail server is to be encouraged. It is always possible to provide
MIME alternative parts that first offer FTP, then mail server options.
--
3.6) What mail servers can I reference?
There are various mail servers available. Check news.answers for
the FAQ about mail server software. We do not presently have a
recommendation.
--
3.7) Can I interwork between MIME and X.400?
Conversion between RFC 822 and X.400 is defined in RFC 1327 and
RFC 1495.
Recently, the MIME-MHS working group has published RFCs (which are on
the IAB standards track) that extend RFC 1327 to define conversions
between MIME and X.400.
Some MTAs, notably the ISODE Consortium's version of PP (see appendix B)
have MIME gatewaying support.
--
3.8) Where else is MIME used?
Gopher
[ Randall Atkinson <atki...@tengwar.itd.nrl.navy.mil> 2-Jan-1993 ]
There is experimental work underway in the Internet Gopher community
to include MIME as a mechanism for marking the content of files.
The freely distributable Gopher client for NeXTstep 3.0 includes
MIME support. Other gopher clients will probably add it eventually.
World Wide Web
[ Marc VanHeyningen <mvan...@cs.indiana.edu> 26-Jun-1993 ]
There is more-than-experimental work underway in the Internet World
Wide Web (WWW) community to use MIME as the mechanism for marking
the contents of information exchanged via HyperText Transfer
Protocol (HTTP); the specification of HTTP/1.0 dictates that both
the request and the response are more or less MIME-compliant
messages. There are implementations already doing this today.
Support is also included for format negotiation (e.g. a server
might have both a PostScript and a plaintext version of a paper
and decide which to send based on what the client can accept,
presentation preferences, size, and the like.) It's nearly as
complicated as the "badness" mechanisms in TeX, and unrelated to
(and, for its application, probably superior to) the
multipart/alternative MIME type.
There is an FAQ for WWW in comp.infosystems.www
--
3.9) How can I register a new MIME type?
The procedures for registering new content types, character set
values, access types, and conversion parameters with IANA (the
Internet Assigned Numbers Authority) are documented in RFC 2048.
You might also find it useful to review Harald T. Alvestrand's
notes:
[ "Harald T. Alvestrand" <Harald.T....@uninett.no> 27-Oct-94 ]
I put up a few words on how I understand the current MIME body
part registration procedures on
http://domen.uninett.no/~hta/ietf/media-types.html
The Web version includes hyperlinks to the relevant IANA archives
and RFCs.
RFC 2048 makes mention of a discussion list, "ietf-types", to which
proposed MIME type registrations are to be submitted for review. The
current subscription request address for the ietf-types list is this:
In the body of the request message specify this command:
subscribe ietf-types your-address@your_site.your_net
A pointer to the ietf-types list's message archive may be found in
Harald T. Alvestrand's aforementioned web page on MIME body part
registration procedures.
Two deadly mistakes are made over and over again in proposed MIME type
registrations sent to the ietf-types list: incorrect name designation
and lack of attention to security considerations.
Here are some tips to avoid making those same mistakes (mostly thanks
to Keith Moore and Ned Freed):
* Name your type properly.
- You may not register an "x-" type name.
- You may not register a new type at the top level--for example a
type named "application/toe-fungus"--unless the type has gone
through the IESG approval process, a process that may include
publishing supporting material in an RFC.
Unless you want to go through all that, use instead the "vnd" or
"prs" name spaces. For example, the previous example instead
might be named "application/vnd.fooco.toe-fungus", which uses a
fictitiously IANA-approved producer name "fooco".
* Do _not_ say "none" in the security considerations section.
- Are you really willing to testify in public that there are no
security risks associated with using your proposed MIME type,
or with using products that may act on that type?
Consider that there are significant security risks with using
most data formats, including "plain text", Microsoft Word,
PostScript, Java, and anything that can contain activeX controls.
The list keeps growing.
If you haven't examined the security issues for your proposed
type, then say that you have not. If you know that your type
should be used only in trusted environments, then say that.
- You should document the risks that you _have_ considered. If
you've uncovered any threats, describe those threats and document
any known countermeasures for those threats. For example, when
the data are acted upon by or fed to some program on the
recipient's system, can such action cause permanent side-effects
on that system? Can it expose the user's data or actions to the
outside world? Is there any automatic action associated with the
data, such as receipt notification, that might take place without
warning the recipient? Many would consider this a breach of
security.
- If your type contains other media types, do the encapsulated
media types have their own security considerations? Does the
encapsulation format itself add risks? Can the encapsulation
format thwart firewalls or filters?
--
3.10) What's ESMTP, and how does it affect MIME?
ESMTP (Extended Simple Mail Transfer Protocol) is a mechanism by which
extensions to "traditional" (RFC 821) SMTP can be negotiated by client
and server. The mechanism (RFC 1869) is open-ended; so far two
extensions have been defined.
Message size declaration (RFC 1870) offers a graceful way for servers
to limit the size of message they are prepared to accept. (With SMTP,
the only possibility is for the server to discard the message after it
has been sent in its entirety. There is no way for the client to know
that it was the size of the message that caused the problem.)
When a message is returned to the user as being too large to deliver,
one possible approach might be to fragment the message using the MIME
Message/Partial mechanism, and resubmit it.
Depending on the exact reason for the "too large" rejection, this may
or may not be a good idea. For example, the limitation may reflect
the recipient's disk quota, in which case the fragmented message will
not be fully deliverable either.
The possibility of fragmentation should, therefore, be left to the
user's discretion (not performed automatically by the SMTP client).
8bit-MIMEtransport (RFC 1652) opens up the possibility of sending 8bit
data in mail messages, without having to use base64, quoted-printable,
or another encoding, and without the breakage that can result from
sending 8bit data to an unsuspecting RFC 821 SMTP server. RFC 1428
(Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME)
discusses some of the implications of this.
The "just send 8 bits" (via plain, un-extended SMTP) philosophy still
has its adherents. Here are some heavily edited excerpts from an
argument on the subject:
[ Rahul Dhesi <dh...@rahul.net> 16-Sep-1996 ]
Human readers tend to be quite smart about figuring out what to do
with incoming email. Just send them 8 bits, and let them decide what
to do with it. If they don't like it they will delete it or complain
to the sender's postmaster etc.
[ Mark Crispin <m...@CAC.Washington.EDU> 16-Sep-1996 ]
In order to understand why "just send 8-bits" raises such hackles,
it is necessary to look beyond strictly technical issues. It is
trivial with most of today's machines (and even with the old
36-bit machines!) to send and receive undamaged 8-bit email. The
issues are of a wider scope than merely technical issues.
1) Legacy software. This software was compliant with published
standards when it was written. Historically, the Internet
community has avoided declaring standards-compliant legacy
software to be "broken", as opposed to merely "lacking recent
extensions".
2) Data integity and reliability. High-order bit zeroing and
software crashing when characters > 0x7f are encountered (both
have been reported) in *Full Standard compliant* software are
real issues.
3) Lessons of the past. "Just use ISO-646" didn't work because it
did not scale to multi-national email. The proponents of "just
send 8-bits" will have us believe that "zones" that share a
single 8-bit coded character set are large enough that the same
scaling problems won't occur, or that they aren't important
enough to worry about. In effect, they claim that
interoperability problems between France and Germany are
important, but interoperability problems between Germany and
the Czech Republic aren't.
4) Politics. Whether or not it is stated as such, "just send
8-bits" is perceived in certain areas of the world as a
declaration that the "Internet Standard Character Set" is being
changed from US-ASCII to ISO-8859-1. There are *vehement*
objections to this. Some folks even base their objections to
Unicode on the (incorrect) perception that Unicode declares
ISO-8859-1 as a "base level" and thus gives a perceived unfair
advantage to Western Europe.
ESMTP provides a mechanism for cooperating software to interchange
8-bit. Why, if "just send 8-bits and fix all the old systems" is
a viable option, is there such a problem with the option of
"deploy ESMTP and send 8-bits". The answer is that it is much
harder to deploy ESMTP than it is to pretend that "just send
8-bits" is deployed everywhere.
--
3.11) Where can I get some sample MIME messages?
Here are two sources:
ftp://ftp.bellcore.com/pub/nsb/samples/
http://www-dsed.llnl.gov/documents/tests/email.html
Here're more sources:
[ Patrik Faltstrom <p...@bunyip.com> 13-Dec-1994 ]
At 12:55 AM 12/11/94, Richard Willis wrote:
>Could someone tell me what the address of the person in Sweden
>is who kindly provided a set of MIME-conformancy tests via
>listserver...
My address is p...@bunyip.com, and the address of the listserver
is mime...@bunyip.com. Send the command (actually the name of the
file you want) as the subject in the message. Start with the command
"HELP".
[ "Erik Huizer (SURFnet BV)" <Erik....@surfnet.nl> 20-Jan-1995 ]
Test messages can be requested in the following way:
Send mail to <mime...@relay.surfnet.nl> with a subject field
containing [ a type/subtype designation, or one of these: ]
X-local <to test how your UA deals with undefined content-types>
nested <returns a message that contains nested multipart contents>
iso-8859-1 <returns a message with text/plain charset=iso-8859-1>
A message containing the requested content-type will be returned to
the address contained in the from field.
--
3.12) Wouldn't MIME be better if it did <foo>?
This question is asked for various values of <foo>. Perhaps the most
common is "multilevel encodings": see the next question. There are
a couple general points that apply to all <foo>.
1. Please remember that MIME is the result of a lot of work by a lot
of persons, over a long time (look at the Acknowledgements section of
RFC 2049). A great many ideas, probably including yours, were
considered. In many cases, there were conflicting goals, such as
simplicity and interoperability on the one hand, and power and
flexibility on the other.
2. If you really think you've got an original idea which would improve
MIME, the correct place to pursue it is not this newsgroup, but the
working group mailing list (having first read the archives, to check
that it really is new). Yes, this is going to be a lot more work than
posting a news article.
--
3.13) So what about multilevel encodings?
MIME uses a two-level encoding scheme. The original object (for
example, a picture, or a text document) is encoded using a well
defined mechanism appropriate to that object (perhaps GIF for the
picture, and text/enriched for the document). Then a second encoding
is used to ensure that the first encoding can be transmitted intact
(probably base64 for the GIF, and quoted printable for the
text/enriched document).
Note that there is a very small number of the second encodings (five,
but three of these are simply indications of what kind of data an
unencoded body part contains), and it is not expected that there will
be many more in the foreseeable future.
The multilevel encodings idea is for a more generalized MIME-like
encoding mechanism that could indicate many arbitrary transformations
of the original object. For example,
Content-Type: application/tar; conversions="encrypt,compress,uuencode"
might indicate a UNIX tar file that had been encrypted, then
compressed, then uuencoded. (This is a fictitious example of how MIME
might have worked; it's not legal MIME. Don't worry if you've never
heard of some of these transformations.)
This may look like an attractive scheme at first, but it has a number
of problems.
1. If you've been brought up on UNIX and command pipelines, the
implementation of such a scheme seems trivial. Surely any half-decent
machine can do something similar? Unfortunately, this turns out to be
true only for a very restricted definition of "half-decent". In
practice, it would be awfully difficult to implement this on a lot of
systems. Probably even more systems would not allow new
transformations to be just "slotted in", and would require
recompilation or reshipping whenever a new one came along.
2. Each successive transformation reduces the size of the audience who
can successfully decode the message. Every MIME mailer must be able
to decode base64 and quoted-printable, so it's guaranteed that you can
at least get back to the raw data. What if, in the above example, I
have tar, decrypt, uudecode, but no uncompressor?
3. Such a scheme does not increase the scope of the framework defined
by MIME. If uuencoded, compressed, encrypted tar files are useful
things to sling around, it is entirely possible to define a new MIME
type (presumably a subtype of application) to handle them.
--
3.14) Why doesn't MIME include a mechanism for compression?
Compression is a difficult area. It was considered by the working
group, but no consensus was reached. There is still work going on in
this area: there may someday be a compressed-64 encoding.
Most compression algorithms have one of more of these undesirable
properties: they are covered by patent, they require the ability to
treat the input as a stream of bits, they use a large data space. The
chances of finding a truly interoperable compression algorithm are
therefore rather slim.
It is worth noting that most or all of the image and video subtypes
(including GIF, JPEG, TIFF, and MPEG) define their own compression
schemes.
--
3.15) What's this Content-Disposition header?
It's a way to specify what needs to be done with a MIME content, such
as storing it in a file with a particular name, or displaying it.
For information about Content-Disposition, see RFC 1806.
See also RFC 2112 and the following draft document for information
about a complementary content-type, multipart/related.
--
3.16) What character sets can be used with MIME?
There are several character sets registered for use with MIME. The
registered character sets are listed in the media-types document
(see appendix A).
[ Jungshik Shin <jung...@net161-61.student.yale.edu> 20-Jul-1996 ]
Chuck Cairns (chu...@fc.hp.com) wrote:
> Can someone give me a pointer to the MIME charsets used for Japanese
> (shift-jis and euc) and Chinese. I've read thru the faq and looked at
> rfc1700 but it's not clear to me what is usual practice.
See RFC 1468 for Japanese, RFC 1557 for Korean and RFC 1922 for
Chinese, all available at ftp://ftp.internic.net/rfc and other places.
Also, you may wish to read Ken Lunde's CJK.inf at
http://jasper.ora.com/lunde and references therein.
[ Knut S. Vikor <knut....@smi.uib.no> 12-Dec-1996 ]
This just to note an "ABC on using languages other than English on the
Net", which aims at giving an introduction to the uninitiated about
what the problems are for using non-English in email or other network
communications.
http://www.hf.uib.no/smi/ksv/char.html
--
End of Part 3
*************
--