Content-Type: text/plain; charset=us-ascii
Content-Description: comp.mail.mime FAQ (frequently asked questions list)
Content-Transfer-Encoding: 7bit
Message-Id: <mime_844756468_1@irvine.com>
MIME-Version: 1.0
Archive-Name: mail/mime-faq/part1
Version: $Id: mime1,v 3.20 1996/09/09 00:50:18 jsweet Rel $
Posting-Frequency: monthly
X-Comment: archive-name information provided redundantly
           because of rules for coalescing message/partials.

Archive-Name: mail/mime-faq/part1
Version: $Id: mime1,v 3.20 1996/09/09 00:50:18 jsweet Rel $
Posting-Frequency: monthly

==========================================================
comp.mail.mime frequently asked questions list (FAQ) (1/3)
==========================================================
Part 1: Answers to Frequently Asked Questions about MIME
--

Overview
--------
This is part 1 of a Frequently Asked Questions document about MIME, the
multipurpose and multi-media standard for Internet mail.

Part 1 covers frequently asked questions.

Part 2 is a listing of MIME products.

Part 3 covers advanced topics.

Sections in the table of contents that have changed since the last
posting are marked with a '!' in the first column.  New sections are
marked with '+'.

Contents
--------
Part 1: Answers to Frequently Asked Questions about MIME (this file)
========================================================
  1.1)     Introduction
  1.1.1)   Authorship
  1.1.2)   Conventions
! 1.1.3)   Where can I get the comp.mail.mime FAQ?

  1.2)     What is MIME?
  1.2.1)   Introduction
  1.2.2)   MIME features that may or may not be present
  1.2.3)   Help!  I got a message in MIME format--how do I decode it?
  1.2.4)   MIME glossary
  
  1.3)     Miscellaneous questions
  1.3.1)   What can I use to display MIME messages?
  1.3.2)   What's "text/enriched"?
  1.3.3)   What about security issues?
  1.3.3.1) PEM
  1.3.3.2) MOSS
! 1.3.3.3) PGP
  1.3.4)   So, does MIME introduce any new security problems?
  1.3.5)   What about a group 3 facsimile encoding?
  1.3.6)   Should I always use external body parts to save space?
  1.3.7)   What mail servers can I reference?
  1.3.8)   Can I interwork between MIME and X.400?
  1.3.9)   Why does MIME define base64 instead of using uuencode?
  1.3.10)  How can I use uuencode with MIME?
! 1.3.11)  Does Microsoft Mail support MIME?
  1.3.12)  What do I do with binhex-ed mail?
  1.3.13)  Can I do MIME on a (pick one) PC/Macintosh/Envoy/Whatever?
  1.3.15)  Where else is MIME used?
  
! 1.4)     Where to find information about MIME
  
  1.5)     MIME support in commercial mail services

Part 2: MIME products (posted separately)
=====================
  2.1)     Freely available MIME packages
! 2.1.1)   Libraries and Patches
! 2.1.2)   Conversion tools and extension packages
  2.1.3)   Mail user agents and transport systems

! 2.2)     Commercial MIME packages

  2.3)     Packages for MIME in USENET
  2.3.1)   Introduction
  2.3.2)   News readers and transports with MIME support

Part 3: Advanced topics (posted separately)
=======================
  3.1)    Information
! 3.1.1)  MIME-relevant RFCs, drafts, and standards
  3.1.2)  MIME types
! 3.1.2.1)  List of registered MIME types
  3.1.2.2)  List of known unregistered MIME types
  3.1.3)  Internet Engineering Task Force (IETF) working groups

  3.2)    Developers' FAQs
  3.2.1)  How can I register a new MIME type?
  3.2.2)  What's ESMTP, and how does it affect MIME?
  3.2.3)  Where can I get some sample MIME messages?
  3.2.4)  Wouldn't MIME be better if it did <foo>?
  3.2.5)  So what about multilevel encodings?
  3.2.6)  Why doesn't MIME include a mechanism for compression?
  3.2.7)  What's this Content-Disposition header?
+ 3.2.8)  What character sets can be used with MIME?

  3.3)    Acknowledgements
  3.4)    Permissions
--

1.1) Introduction
-----------------

1.1.1) Authorship

Current maintainer:
  Jerry Sweet <mime-faq@ics.uci.edu>

    Please note:
  
    Questions about mail systems, how to decode MIME parts on your
    computer, and other such issues, if not already answered in the
    FAQ, should be posted to comp.mail.mime or to the info-mime mailing
    list.

    Correspondence sent to the MIME FAQ maintainer primarily should 
    address information in the MIME FAQ---corrections, additions, or
    suggestions for improvement.  
  
Previous maintainers (thanks, guys!):
  Ed Vielmetti - originator
  Tim Goodwin

Contributions have come from a cast of dozens; see part 3 for the
list of contributors.


--------------------------------

1.1.2) Conventions

 - Direct quotations begin with an attribution in a standard format,
   and are indented by four spaces.
 
 
 - Pointers to resources available via the Internet, such as references
   to FTPable goodies, appear in WWW URL format.  URLs beginning with
   "ftp:" refer to FTP sites.  For example:
 
   ftp://domain.name/path/to/package
 
   Those with FTP access, but without WWW access, may treat such
   references as follows:
 
   1. Log into host domain.name using anonymous FTP
   2. Look for /path/to/package
 
   An FTP reference usually lists only the distribution site; please
   try your nearest FTP archive first.  Archie may be of some help
   here.
 
   URLs beginning with "http:" refer to WWW servers.  URLs beginning
   with "gopher:" refer to gopher servers.
 
   Internet browsing tools, such as Mosaic, know about URLs.
 
 
 - You'll occasionally see text in braces, like this.
 
   { Here is some example meta-text. }
 
   Sometimes, this indicates a place where information is missing, or
   where the information may be unreliable, or where major changes are
   planned in the near future.  You can ignore these if you're just
   looking for information.  But if you can help fill in the gaps, and
   you want to achieve fame, fortune, and your name at the bottom of
   this FAQ, please send e-mail to the maintainer.

--------------------------------

1.1.3) Where can I get the comp.mail.mime FAQ?

 - It is posted approximately monthly to the newsgroups comp.mail.mime,
   comp.answers, and news.answers.  The "Expires:" field is set such
   that---on systems that honor this field---the most recent edition
   shall always be in the news article database.
 
 
 - Many sites archive news.answers postings, including these:
   
   ftp://ftp.uu.net/usenet/news.answers/mail/mime-faq/
   ftp://rtfm.mit.edu/pub/usenet-by-group/news.answers/mail/mime-faq/
   
   If possible, please try to find a closer site; for example, by
   asking archie for "mime-faq".  Alternatively, use WWW search
   engines to look for the MIME FAQ.
   
 
 - An HTML version of the MIME FAQ is available at this URL:
 
   http://www.cs.ruu.nl/wais/html/na-dir/mail/mime-faq/.html
        (Brought to you by the Department of Computer Science, 
         Utrecht University, The Netherlands.)
 
   If you find a non-working hypertext link in the HTML versions,
   you're welcome to bring it to the attention of the MIME FAQ
   maintainer, but unless it's a problem with a URL reference in the
   original document, the MIME FAQ maintainer probably can't fix it
   directly.

 
 - If you are reading this FAQ via some fixed medium such as hardcopy
   or CD-ROM, please try to obtain the latest edition from the net
   instead.


There is also a Part 0, the "Meta-FAQ", posted monthly, that attempts
to help with any special problems that you may have with reading MIME
messages such as the MIME FAQ postings.

--


1.2) What is MIME?
------------------

1.2.1) Introduction
  
MIME, the Multi-purpose Internet Mail Extensions, is a freely available
specification that offers a way to interchange text in languages with
different character sets, and multi-media e-mail among many different
computer systems that use Internet mail standards.

If you were bored with plain text e-mail messages, thanks to MIME you
now can create and read e-mail messages containing these things:

        - character sets other than US-ASCII
        - enriched text
        - images
        - sounds
        - other messages (reliably encapsulated)
        - tar files
        - PostScript
        - pointers to FTPable files
        - other stuff

MIME supports not only several pre-defined types of non-textual
message contents, such as 8-bit 8000Hz-sampled mu-LAW audio, GIF image
files, and PostScript programs, but also permits you to define your
own types of message parts.

Before MIME became widespread, you might have been able to create a
message containing, say, a PostScript document and audio annotations,
but more often then not, the message was encoded in a proprietary,
non-transportable format.  That meant that you couldn't easily handle
the same message on another vendor's workstation.  Now, depending on
the completeness of your MIME-capable mail system, there's a good
chance that it'll "just work" (but see section 1.2.3 for some warnings
on this subject).

One of the best things about MIME is that it's a "four-wheel drive
protocol" (to borrow a description applied originally to PhoneNet by
Einar Stefferud).  MIME was carefully designed to survive many of the
most bizarre variations of SMTP, UUCP, and other Procrustean mail
transport protocols that like to slice, dice, and stretch the headers
and bodies of e-mail messages.

Here are a few examples of how MIME is being used in the real world,
now.

1. Dr. Marshall T. Rose mails out his SNMP-related newsletter, "The
Simple Times" as multi-media e-mail messages in several forms:

        - in a PostScript form, with beautiful typesetting and a
        two-column page layout, suitable for printing on a laser
        printer;

        - in a "text/html" form (RFC 1866), suitable for 
        examination via a WWW browser. (Formerly,
        text/richtext, another SGML-like markup language,
        was used.)

        - in an ordinary, plain text, form.

(SNMP is the Simple Network Management Protocol.)

2. IETF document announcements (RFCs, Internet Drafts, etc.) are
structured as multipart MIME messages.  The first part contains the
document abstract.  The second part is itself a multipart message,
containing external references to the document itself (one via a
mail-server, one via anonymous FTP).  Thus, with a suitable UA (User
Agent, see 2.5 for glossary), you can read the abstract, and then have
the complete document retrieved for you (by the most appropriate method)
at the press of a button.

3. A "pointer" to this FAQ is posted weekly in comp.mail.mime.  The
pointer article contains MIME external contents that MIME-capable mail
user agents can use to obtain the FAQ via WWW, Internet FTP, or mail
server.

--------------------------------

1.2.2) MIME features that may or may not be present

An implementation of multi-media e-mail need not support the full
spec; it's possible to have a useful product that does not explore all
of the nooks and crannies of the standard.

Furthermore, MIME permits a message to contain alternative parts for
consumption by sites that can't necessarily display or listen to all
the good stuff.
 
Here is a list of features that someone with a good, functional
mail user agent might include for MIME support.
 
 - Displays GIF, JPEG, and PBM encoded images, using e.g. 'xv' in the X
   Window System, or (name of windows program here) in Microsoft Windows.
  
 - Displays PostScript parts, using e.g. something that prints to a
   PostScript printer, or that invokes GhostScript on an X Window System
   display, or that uses Display PostScript.
  
 - Obtains external body parts via Internet FTP or via mail server.
   
 - Plays audio parts on workstations that support digital audio.

On the other hand, the minimal requirements for a MIME-conformant MUA
are almost trivial, yet still provide increased functionality.  (The
minimal requirements are mainly concerned with ensuring that users are
not shown raw data from a MIME message inappropriately.)

See also:

 - RFC 1844, the "Multimedia E-mail (MIME) User Agent Checklist",
   by Erik Huizer.

--------------------------------

1.2.3) Help!  I got a message in MIME format--how do I decode it?

If you receive some content type that your mail user agent can't
already handle automatically, then you'll have to modify your global
or personal mail system configuration to deal with it--if you can.
It's not always possible, short of spending a year of your life to
write the required programs.

Some bits of advice:

 - Look in the MIME FAQ (part 1 of which you're reading now) to
   see if someone already has a tool or product that will decode the
   content type that you're attempting to handle.  Part 2 enumerates
   many MIME-capable products and packages, some commercial, some free.

 
 - Check the MIME Meta-FAQ.  It's posted in comp.mail.mime along
   with this FAQ.  The meta-FAQ offers general advice for dealing
   with various MIME problems.  The meta-FAQ also may be found at 
   this URL:
 
   ftp://ftp.ics.uci.edu/pub/mh/contrib/multimedia/mime-meta-FAQ
 
 
 - A common decoding question is about "base64".  Technically,
   base64 is a content transfer encoding, not a MIME type per se.
   It looks like line after line of evil stuff like this:
 
     H52QbdC0aJOmTZkXbcKkYUNGzhs4ACJKnEixosWLGDNq3FgRhEcbNG...
 
   To decode it, you need something that'll unpack base64.  One
   solution, called "munpack", may be found at this URL:
   
   ftp://ftp.andrew.cmu.edu/pub/mpack/
   
   Versions are available for Unix, MS-DOS, Macintosh, and Amiga
   platforms.  See the Meta-FAQ for some hints and tips about how
   to run munpack.

                        *       *       *

Here your faithful MIME FAQ maintainer feels the need to rant a bit on
the subject of poor MIME usage and concomitant MIME decoding problems.

MIME capability doesn't automatically confer interoperability with the
rest of the world.  Any random data can be mapped into MIME one way or
another, but some consideration needs to be given to the target
audiences.

Still, as Einar Stefferud likes to point out, "'Can' implies 'shall.'"
Platform or application-specific MIME data formats inevitably leak out
to the rest of the world, prompting instant FAQs: "Huh?  Now how do I
make my mail reader handle _this_?  And why was it sent to me?"

For creators of MIME messages, here are some preventive suggestions:


  - Know how your attachments are going to be sent.  Bear in mind
    that what's reasonable for another Macintosh/Windows/Envoy/Whatever
    recipient isn't necessarily reasonable for the rest of the world.
    For example, sending that Microsoft Word document as an attachment
    might not work out as well as you think it should.

    If options are available for turning off attachments, do so,
    except perhaps for specific correspondents known to have the
    ability to view the attachments.  This is particularly relevant to
    users of mail systems in Microsoft operating environments.

    Microsoft TNEF data, for example, which has been seen to be 
    leaking out to the wider Internet, is not something that most
    Internet correspondents can presently handle.  In addition to
    attachments, TNEF data may include links to OLE objects, fonts,
    colors, and other information that doesn't have the same form
    or meaning outside a Microsoft operating environment.


  - Be somewhat conservative about content types when sending to
    mailing lists or other public forums, or consider using
    multipart/alternative.


  - Watch character set selections and content transfer encodings.
    For example, some commonly used character sets on Apple Macintosh
    computers use eight bits, not the standard seven bits, and also
    contain a few non-standard glyphs.

    Here is an example of a typical issue for personal computer
    users:

        [ Michael P Urban <urban@cobra.jpl.nasa.gov> 14-Feb-1996 ]
    
        If you want to send non-ASCII text (e.g., if you are a
        Macintosh user and you send text containing a bullet), you
        should realize that the mail system has NO WAY of knowing
        whether the recipient has the same sort of computer you have.
        The non-ASCII binary code for a bullet on a Macintosh is
        different from the one used on Intel machines, which is
        different from LATIN-1 (which has no such character).

--------------------------------

1.2.4) MIME glossary

Every subculture needs its list of buzzwords, here's a start at a
collection for MIME.
  
body            the part of a message after the header (the "meat")
content         a portion of a MIME message
CTE             content transfer encoding (e.g. base64, quoted-printable, etc.)
ESMTP           Extended SMTP - RFC 1869
external part   a "pointer" to a part available via FTP or other means
GIF             graphical interchange format for images
header          the To, From, Subject, etc. at the start of a message
HTML            hypertext markup language; used in WWW documents
JPEG            an image compression standard for still images
mail transport  the "post office", e.g. sendmail, smail, MMDF, etc.
MIME            Multipurpose Internet Mail Extensions - RFC 1521
MPEG            an image compression standard for moving pictures
MTA             Mail Transport Agent, see "mail transport"
MUA             Mail User Agent, see "user agent"
multi-media     nebulous marketroid term meaning audio and visual stuff
part            a piece of a MIME message containing some data type
PBM             an image format
PEM             Privacy Enhanced Mail
PGP             Pretty Good Privacy
PostScript      a popular page description language
RFC             request for comments; proposed or standard Internet protocols
SMTP            Simple Mail Transfer Protocol - RFC 821
text/enriched   simple text markup language for MIME - RFC 1896
text/simplemail another (even simpler?) text markup language
URL             WWW uniform resource locator; access-method://host/path
user agent      the end user's mail program, e.g. MH, ELM, /bin/mail, etc.
WWW             the world-wide web

--

1.3) Miscellaneous questions
----------------------------

1.3.1) What can I use to display MIME messages?
 
You need something that understands MIME-structured messages and also
understands how to display the different kinds of body parts.

Details of many freely available and commercial packages to do just
that can be found in part 2 of this FAQ.

--------------------------------

1.3.2) 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 part 2 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.

--------------------------------

1.3.3) What about security 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 <raph@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


1.3.3.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

1.3.3.2) MOSS

    [ James M Galvin <tismoss-support@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.


1.3.3.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" <jis@mit.edu>  24-Jun-1994 ]

    There is now a freeware version of PGP that is not dubious from a
    patent standpoint.

Billg@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 <elkins@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-request@lists.uchicago.edu
    with a subject of "subscribe".
    
    Submissions should be sent to
            pgp-mime@lists.uchicago.edu

    [ Raph Levien <raph@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.Freed@innosoft.com> 19-Jul-1996 ]

    A document describing how to combine RFC 1847 and PGP was recently
    accepted as a proposed standard. It should be out as an RFC soon.

    { See http://ds.internic.net/internet-drafts/draft-elkins-pem-pgp-04.txt
      in the meantime. }

    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.


--------------------------------

1.3.4) 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.

--------------------------------

1.3.5) 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 <sl@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 <ned@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?"

--------------------------------

1.3.6) 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.

--------------------------------

1.3.7) 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.

--------------------------------

1.3.8) 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 part 2)
have MIME gatewaying support.

--------------------------------

1.3.9) Why does MIME define base64 instead of using uuencode?

    [ Ed Greshko <egreshko@cosmo.twntpe.cdc.com> 15-Apr-1994 ]

    The *major* reason is that there is no standard for uuencode.  While
    it is popular, the many flavors of uuencode in existence make it a
    prime candidate for *non*-interoperability.

    [ John Gardiner Myers <jgm+@CMU.EDU> 1-Jun-1994 ]

    Some gateways damage messages in the more common uuencode formats.
    Gateways that convert between EBCDIC and ASCII, in particular, tend to
    damage some of the characters used in the uuencode format.  The base64
    encoding is designed to be invulnerable to all known gateways.

    [ Ned Freed <NED@innosoft.com> 26-Oct-1994 ]

    Well, once you say UUENCODE you've already bought into a whole bunch
    of different formats. There are lots of different encoders out there
    that produce completely different variants of UUENCODE. (I just ran
    into a new one I had never seen before yesterday, and it happens to be
    one I know won't work with some of the decoders I've used.)  And
    sometimes they interoperate and sometimes they don't.
    
    Because of the lack of a standard version of UUENCODE and the
    resulting interoperability problems, as well as various problems with
    the encoding character set used by some UUENCODE implementations, MIME
    elected to go with an existing encoding originally defined, if memory
    serves, in RFC989 back in 1987, as well as adding a new "lightweight"
    encoding mechanism for material that's mostly text.
    
    I should also point out that most MIME-ware supports UUENCODE as a
    format even if though it is nonstandard and causes interoperability
    problems.

    There are a bunch of other encodings in use, like base85, btoa, and
    hexadecimal.  However, you really don't see these that often in
    practice.

    [ Dave Collier-Brown <davecb@cs.yorku.ca> 1-Feb-1996 ]

    If you have to deal with IBM VM/DOS/VSE/MVS or AS/400 systems, you can
    look forward to having to ``reconsruct'' uuencoded messages... because
    trailing spaces get transformed to nothingness, and occasionally
    printing characters get transformed to the equivalent in a different
    ``print train'' (Yes, Virginia, IBM mainframes still think of
    character sets in terms of printer chains).

    [ Ned Freed <NED@innosoft.com> 2-Feb-1996 ]

    There are plenty of UUDECODE variants that silently drop grave accents
    or do horrible things with them. I've seen UUDECODE variants on PC,
    VMS, and UNIX systems that have problems in this area.
    
    Another closely related problem is failure to treat lines whose
    lengths don't correspond to their length character as being padded out
    with spaces that have presumably been lost in transit. Very few of the
    UUDECODE sources I have seen get this one right.

    Often as not two characters in the UUENCODE repetoire get mapped
    onto one. This, of course, is noninvertible.


{ Additional information, horror stories, etc., welcome. }

--------------------------------

1.3.10) How can I use uuencode with MIME?

The following idea from Nathaniel may be useful.  For some examples of
this in action, see the newsgroup clari.feature.dilbert.

    [ Nathaniel Borenstein <nsb@thumper.bellcore.com> 4-Nov-93 ]

    I recently convinced myself that you can use multipart/alternative
    to get a nice effect for both MIME-smart recipients and
    uuencode-loving recipients, although it is ugly and wasteful:
    
    Content-type: multipart/alternative; boundary=foo
    
    --foo
    Content-type: application/octet-stream; name=foo.uu
    
    ...uuencoded data goes here....
    --foo
    Content-type: real-mime-type
    Content-type: base64
    
    base64-encoded data goes here
    --foo--
    
    A good MIME viewer will only use the second part, the real MIME
    data.  A uuencode-oriented system, however, should ignore everything
    EXCEPT the uuencoded data, because of the way uuencode works
    (everything before the "begin" line and after the "end" line is
    ignored).

    I certainly wouldn't want to recommend the above as standard
    practice, but I imagine that are enclaves or situations where it
    could be useful.

--------------------------------

1.3.11) Does Microsoft Mail support MIME?

The short answer is "no", at least not correctly.  For example, as of
23 June 1996, broken base64-like encodings are being created with
software that identifies itself as Microsoft Internet Mail 4.70.1080.
Earlier versions may or may not identify themselves.  Different
versions apparently have various broken behaviors with respect to
MIME.  Subsequent releases might eventually support MIME correctly.

There are various third-party gateways for MS Mail that claim to
support MIME.

Here are some other comments:

    [ Carl S. Gutekunst <csg@clavinova.eng.sun.com> 27-Aug-1996 ]

    Microsoft has at least five different products that handle Internet
    Mail:
    
    * SMTP Gateway for Microsoft Mail.  (Option for Microsoft Mail
      V3. Does not support MIME.)
    
    * The MSN online service. (Does not support MIME)
    
    * Microsoft Exchange Client.  (Bundled with Windows95.  Supports MIME,
      but puts odd things in text/plain.  Does proper Content-Types through
      the Win95 file types menu.)
    
    * Microsoft Exchange Server Internet Connector.  (Optional Gateway for
      Exchange Server.  Supports MIME, but has its own set of oddities, the
      most notorious of which is the application/ms-tnef attachment that
      graces almost every message. Does not wrap long lines in text/plain,
      either. Has its own private table for mapping content types.)
    
    * Microsoft Internet Mail.  (Bundled with Internet Explorer
      3.0. Supports MIME and HTML, but attaches *everything* as
      octet-stream, even very well known types like image/jpeg.)

    [ Ned Freed <ned@sigurd.innosoft.com> 19-Feb-1996 ]

    You have to be careful when you talk about MS Mail, because it is lots
    of different things. There's the "classic" MS Mail, there's MS
    Exchange, there's MS Mail on Mac (now owned by Star*9, I believe), and
    there may well be others I have not heard about.
    
    All of them use proprietary formats internally. Classic MS Mail uses
    RFC 1154 [obs.] formats rather than MIME when talking to the Internet.
    MS Exchange uses MIME, but its usage of MIME is, shall we say,
    peculiar. And MS Mail on the Mac can do MIME when talking to the
    Internet, and its MIME support is pretty good.

    [ Carl S. Gutekunst <csg@clavinova.eng.sun.com> 20-Feb-1996 ]

    As Ned noted, the MS Mail SMTP Gateway uses a variant of RFC 1154 [obs.],
    a precursor of MIME that had similar intent.
    
    The real rub with all pre-MIME Internet mail attachment models
    [is that] they just didn't interoperate.
    
    All current Microsoft Internet connectivity products are MIME
    compliant, although somewhat eccentric in their behavior.  Oddly
    enough, the eccentric behavior is not because of Microsoft's alleged
    goal to dominate the Internet with quasi-proprietary protocols, nor is
    it out of ignorance.  It's just a matter of finite resources and tight
    delivery schedules.  Surprise.

    [ Steinar Bang <sb@metis.no> 19-Feb-1996 ]

    >>>>> "APS" == "Andre P Stewart" <astewart@hp43326.mdc.com> writes:
    
    APS> Microsoft Exchange is the MUA that Microsoft currently produces
    APS> and supports.  It is shipped with Windows95 an has clients for
    APS> both Windows for Workgroups and Windows NT.  Soon, a Macintosh
    APS> version will be available.
    
    From a MIME point of view it has two major annoying mis-features:
     1. Its composer doesn't do line breaks.  When text/plain message
        parts hit the SMTP gateway, it sees lines longer than 76
        characters, and encodes the message in Q-P [Quoted-Printable].
        When this message is received by a MUA that doesn't understand
        MIME, the message is full of ugly "=" characters.
        When this message is received by a MIME-compliant MUA, the Q-P is
        decoded, and paragraphs show up as very long lines.
        Basically, it's ruined unless the receipient is another MSE user.
     2. It gives all attachments the MIME type application/octet-stream,
        and uses file name extensions to infer the type.
    
    In addition it quotes real name of an email address with ' which is
    illegal in internet email addresses, so that they have to be quoted
    with ".  This means that messages sent to me from MSE has the address:
    "'Steinar Bang'" <sb@metis.no>.

    [ Ned Freed <Ned.Freed@innosoft.com> 23-Jun-1996 ]

    Another problem with Exchange's use of quoted-printable has surfaced
    recently at at least one site -- generation of illegal quoted-
    printable encodings. Specifically, the site reported that Exchange
    generates =0A instead of a proper hard line break per the MIME
    specifications.

    There now seem to be all sorts of different versions of Exchange out
    there doing different things. I have yet, however, to see firsthand
    one that works properly.

--------------------------------

1.3.12) What do I do with binhex-ed mail?

This isn't a MIME-related problem per se, but here are some possible
solutions:

    [ Jim Kramer <kingkern@eclipse.net> 22-Feb-1996 ]
    
    I encode binhex manually on the Macintosh and send to
    MS-Windows users. They decode using Stuffit Extractor
    (freeware).
    

    [ Chris Newman <chrisn+@CMU.EDU> 11-Apr-1996 ]
    
    chaney@ms.uky.edu writes:
    > I need to be able to un-BinHex MIME mail sent from various
    > packages that assume everyone in the worl has an unbinhexer.
    > The most common form is a Mac Binhex (it may be the only
    > kind?) and I see binhexing from Eudora-based mailers.
    
    Binhex is designed to encode Macintosh files.  If someone
    sends you a binhex file and you don't have a Macintosh, tell
    them to use standard MIME/base64 or MacMIME (Eudora's
    nonstandard default configuration can be fixed easily in the
    preferences).  It is possible to write a program which
    extracts the portion of the binhex file which is likely to be
    usable on non-Macintosh computers, and I've got sample source
    if you wish.
    
    A quick look at RFC 1740 & RFC 1741 will show that use of
    binhex in Internet email is generally discouraged.


    [ Tim Simpson <tim@cddc.demon.co.uk> 12-Apr-1996 ]

    Try emil, available from:

        ftp://ftp.uu.se/pub/unix/networking/mail/emil

    { See also part 2 of the MIME FAQ. }


    [ Mark Johnson <markj@msn.ustc.vlsi.com> 11-Apr-1996 ]

    Look for the program mcvert.

    { Use "archie" to locate the various versions of this
    program available via anonymous FTP. }
    


--------------------------------

1.3.13) Can I do MIME on a (pick one) PC/Macintosh/Envoy/Whatever?

See section 1.2.3.

--------------------------------

1.3.14) Where else is MIME used?

Gopher

    [ Randall Atkinson <atkinson@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 <mvanheyn@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
--
    
1.4) Where to find information about MIME
-----------------------------------------

{ Please feel free to contribute references to books, articles,
  web pages, newsgroups, and other sources of information. }


Books:

   The Internet Message: closing the book with electronic mail
  
   Marshall T. Rose
   Prentice-Hall
   ISBN 0-13-092941-7
   
   This book is a complete review of the Internet world of electronic
   mail, including recent developments.  There is considerable detail,
   and it would make the perfect companion to the mail RFCs for any
   budding implementor.
   
   On the other hand, the detail should be quite easy to skip for those
   interested in just an overview.
   
   As usual, Marshall's informed and often vigorous opinions are clearly
   marked off as "soapboxes", to be objectively skipped or delightedly
   sought out, according to preference.
   
   One chapter of the book is devoted to MIME.

 
Articles and Papers:

    [ Daniel Glazman <Daniel.Glazman@der.edf.fr> 27-Oct-94 ]

    (In English):

        N.Borenstein, Bellcore, "Multimedia Mail From the Bottom Up or
                Teaching Dumb Mailers to Sing", ConneXions, pp. 10-16, Nov.91

        G.Vaudreuil, CNRI, "MIME: Multi-Media, Multi-Lingual Extensions for
                RFC 822 Based Electronic Mail", ConneXions, pp. 36-39, Sep.92

    (In French):

        D.Glazman, EDF/DER, "Les Extensions MIME", Tribunix No 57, Oct.94


Information available from the Internet:

   - Via FTP:

   Information about FTPable stuff is scattered throughout this FAQ.
   More specifically, look into the RFCs mentioned in part 3 of this FAQ.
   
   Other goodies can be found in the MH and MetaMail source trees.  
   
   Refer to part 2 of this FAQ for lots of details and URLs beginning
   with "ftp:".

   Refer to part 3 for information about how to retrieve RFCs via FTP.


   A nice overview of the MIME specification by Mark Grand is available
   from these URLs:
   
   http://www.mindspring.com/~mgrand/mime.html

   ftp://ftp.ou.edu/mirrors/networking/mail/mime/mime.ps
   ftp://ftp.ou.edu/mirrors/networking/mail/mime/mime.txt
   
   - Via Mail-based archive servers:

   A few Internet sites whose archives contain MIME-related information
   support retrieval via e-mail servers.  One of these is ics.uci.edu.
   References in URL form to ftp.ics.uci.edu may be used to formulate
   retrieval requests to send to the archive-server address at
   ics.uci.edu.  To find out more about how to use that mail server, send
   a message whose body contains the line "help" to the address
   "archive-server@ics.uci.edu".
   
   RFCs may be requested from a mail-based archive server.  Refer to
   part 3 for information about how to do that.
   
   Several freely available packages, including ServiceMail and metamail,
   contain mail-based archive servers.  Some commercial packages do as
   well.  Refer to part 2 of this FAQ for details.  Installing a
   mail-based archive server at your site makes it possible to send out
   messages containing external body contents that can be used to
   retrieve materials automatically from your site via e-mail.

       [ Arjan van der Meer <arjanvdm@htsa.hva.nl> 30-Jan-1995 ]
   
       Mail for more info: mime-DocServer@docserver.cac.washington.edu
       It sent me a brief and clear E-mailing about how and what MIME is.


   - From USENET newsgroups:

   news:comp.mail.mime

     This is the USENET newsgroup devoted to discussions of MIME.
   
     Comp.mail.mime articles are archived here:
  
          ftp://ftp.ncd.com/pub/usenet/comp.mail.mime 
  
     Articles are stored in three formats: by subject, by article
     number, and by month.  See the README file for more information.
 

   news:comp.mail.multi-media 

     This newsgroup contains general discussions of multi-media e-mail,
     not necessarily MIME.
 
 
   - From Internet mailing lists:

   info-mime

     Info-mime is gatewayed with comp.mail.mime.  This is a
     bidirectional gateway, so every message to the mailing list also
     appears on the newsgroup, and vice versa.  If you are unable or
     unwilling to read USENET news, here is where to send subscription
     requests:
 
         info-mime-request@cs.utk.edu
 

   info-mime-uk

     This is a UK exploder for info-mime.  Here is where to send
     subscription requests:
 
         info-mime-uk-request@mailbase.ac.uk
 
     Mailbase software archives all articles sent to the info-mime-uk
     mailing list.  The articles are accessible via these URLs:
   
     ftp://mailbase.ac.uk
     gopher://mailbase.ac.uk
   
     Archived articles are also available via mailserver; send a message
     to mailbase@mailbase.ac.uk, with a message body containing a
     retrieval command, e.g. "send info-mime-uk 08-1993".


   ietf-types

     RFC 1590 makes mention of a discussion list for MIME type
     registration, "ietf-types".  The current subscription request
     address for the ietf-types list is this:

        ietf-types-request@uninett.no


   other lists

     There are various mailing lists specific to particular
     implementations of MIME.  If we know of such a list, it is
     mentioned in the section of this document about that
     implementation.


   - From the world-wide web:

   There are many web URLs scattered throughout this document.
   Various sources of information about mail systems that support
   MIME may also be found at these URLs (list contributed by
   Brad Knowles <brad@azathoth.ops.aol.com>):

   Internet Mail Consortium
     http://www.imc.org/

   Brad Knowles's comp.mail.sendmail FAQ
     http://www.his.com/~brad/sendmail/

   SMTP Resources Directory
     http://www.dns.net/smtprd/

   SunWorld Online Email Connectivity overview
     http://www.sun.com/sunworldonline/swol-08-1995/swol-08-connectivity.html

   Matt Wall's E-mail Web Resources
     http://andrew2.andrew.cmu.edu/cyrus/email/email.html

   Bill Wohler's Email References
     http://www.worldtalk.com/html/msg_resources/email_ref.html

--

1.5) MIME support in commercial mail services
---------------------------------------------

{ There's lots missing here, and some of this information is aging. If
  anyone has updated information about any of the various mail service
  providers listed here, or any others, then send 'em to the MIME FAQ
  Maintainer address <mime-faq@ics.uci.edu>. }

America Online

    [ Brad Knowles <brad@azathoth.ops.aol.com> 3-Apr-1996 ]

    We support MIME with a single bodypart (we think of bodyparts as
    attachments).
    
    Handling multiple bodyparts still requires user intervention, however.
    We have some utilities online that we provide instructions to folks
    for downloading, should they get a message with more than one MIME
    bodypart.
    
    We also support reading uuencode and Macintosh BinHex format, although
    we only send MIME format.
    
    We plan to provide better support for MIME in the future, but that's
    about all I know (or could say, even if I did know more) on that
    subject.


AT&T MAIL

    [ Tony Hansen <tony@attmail.com> 6-Jan-1996 ]

    The AT&T Mail SMTP gateway to the Internet fully converts between its
    internal format and MIME. That is, all mail going out the SMTP gateway
    should be fully MIME compliant. All mail coming in through the SMTP
    gateway into AT&T Mail is converted into its internal format. Research
    and development is continually improving the interaction between AT&T
    Mail and the Internet standards. This includes improving the MIME-MHS
    interaction. Thus, all X.400 mail that goes to the internet will
    increasingly follow the internet standards on X.400 connectivity.

    Send inquiries to atthelp@attmail.com.


CompuServe

    [ Pat Farrell <pfarrell@netcom.com> 31-Dec-1993 ]

    CompuServe's main mail service is ASCII text based, and is not MIME
    compliant. CompuServe provides robust, reliable mail transport of
    binary files. CompuServe invented and copyrighted the GIF format
    which is supported by MIME. There are commercial and freeware client
    programs for Macs and PCs that can provide "user friendly" access to
    CompuServe's text and binary mail services, display GIF files, and
    interact with CompuServe's forums. (CompuServe forums are roughly
    equivalent to USENET newsfeeds.)


RadioMail

    [ Jerry Sweet <jsweet@irvine.com> 21-Mar-1994 ]

    RadioMail Corp. (formerly Anterior Technology) operates two types
    of e-mail services having these statuses with respect to MIME:

    1. cc:Mail/Internet gatewaying.  cc:Mail does permit binary
    attachments of various types, and these attachments are encoded by
    the gateway for transfer via SMTP, but the encoding is not presently
    MIME-compliant.  This may change.

    2. Wireless e-mail gatewaying.  Because the RadioMail gateway passes
    a limited set of headers, MIME messages per se do not traverse
    the gateway intact.  7-bit-encoded MIME messages may traverse the
    gateway if encapsulated, e.g. using RFC 934.  However, RadioMail
    does not presently supply MIME-compliant user agents for use on
    radio modem equipped MS-DOS and Macintosh computers.  This will
    change.

    [ Mark Lovell <mlovell@radiomail.net> 4-Jan-1995 ]

    The clients for both the Marco and the Envoy support a subset of MIME.
    They only support body-part types that they understand, since there is
    not a traditional OS on either unit. RadioMail has established a full
    set of MIME interface specifications, and future clients will be built
    to support them.


--
End of Part 1
*************
--
