🚀 go-pugleaf

Archive-Name: mail/mime-faq/part1
Version: $Id: mime1,v 3.9 1994/10/09 21:35:40 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)     Introduction
  1.1)   Authorship
! 1.2)   Conventions
  1.3)   Where can I get the comp.mail.mime FAQ?

  2)     What is MIME?
  2.0)   Help!  I got a message in MIME format--how do I decode it?
  2.1)   Introduction
  2.2)   MIME features that may or may not be present
  2.3)   Further information
  2.4)   MIME glossary
  2.5)   Newsgroups and mailing lists
  
  3)     Miscellaneous questions
  3.1)   What can I use to display MIME messages?
  3.2)   What's "text/enriched"?  "text/simplemail"?
  3.3)   What about security issues?
  3.4)   So, does MIME introduce any new security problems?
  3.5)   What about a group 3 facsimile encoding?
  3.6)   Should I always use external body parts to save space?
  3.7)   What mail servers can I reference?
  3.8)   Can I interwork between MIME and X.400?
  3.9)   Why does MIME define base64 instead of using uuencode?
  3.10)  How can I use uuencode with MIME?

  4)     MIME information available from the Internet
  4.1)   Anonymous FTP
  4.2)   Mail based archive servers
  4.2.1) Eitech "ServiceMail"
  4.2.2) Metamail "mailserver"
  4.3)   Gopher
  4.4)   World Wide Web
  
  5)     Published books and articles
  
  6)     MIME based relays for commercial mail services
  6.1)   Large national or international providers
  6.1.1) ATTMAIL
  6.1.2) CompuServe
  6.1.3) RadioMail
  6.2)   Local and regional providers

Part 2: MIME products (posted separately)
=====================
  7)     Freely available MIME packages
  7.1)   Libraries
  7.2)   Conversion tools and extension packages
  7.3)   Mail user agents and transport systems

  8)     Commercial MIME packages

  9)     Packages for MIME in USENET
  9.1)   Introduction
  9.2)   News readers and transports with MIME support

Part 3: Advanced topics (posted separately)
=======================
  10)    Information
  10.1)  MIME-relevant RFCs and other standards
  10.2)  List of registered MIME types
  10.2.1)  List of registered MIME types
  10.2.2)  List of known unregistered MIME types
  10.3)  Internet Engineering Task Force (IETF) working groups

  11)    Developers' FAQs
  11.1)  How can I register a new MIME type?
  11.2)  What's ESMTP, and how does it affect MIME?
  11.3)  Where can I get some sample MIME messages?
  11.4)  Wouldn't MIME be better if it did <foo>?
  11.5)  So what about multilevel encodings?
  11.6)  Why doesn't MIME include a mechanism for compression?

  12)    Acknowledgements
--

1) Introduction
---------------

1.1) Authorship

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

Previous maintainers (thanks, guys!):
  Ed Vielmetti - originator
  Tim Goodwin

Contributions have come from a cast of dozens; see section 12 for the
list of contributors.

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

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. }
 
   Generally, these indicate places 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.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 which honor this field---the most recent edition
   will always be in the news spool.
 
 
 - 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".
   
 
 - An automatically generated HTML version of the MIME FAQ is available
   at this URL:
 
   http://www.cis.ohio-state.edu/text/faq/usenet/mail/mime-faq/top.html
 
   It's brought to you courtesy of Ohio State University.  

   The reason that this MIME FAQ document is marked up the way it is,
   with dividers and score marks and so on, is that these marks
   facilitate automatic conversion of the document to HTML format by
   the Ohio State server.
 
 
 - 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.
--


2) What is MIME?
----------------

Well, let's answer a frequently asked question first, then get to an
introduction.

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

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

If you have problems reading a message in MIME format, it might be for
any of the following reasons:

Scenario 1:
  Your mail system outsmarted itself--it can handle some MIME stuff,
  but not whatever it is you received.  For this, you'll either need a
  smarter mail system, or you'll need to tell the mail system how
  to handle whatever's in the message, or you'll need to defeat the
  mail system entirely, and look at the message in its "raw" state.
  Precisely how to do any of these things depends on the type of
  mail system that you have.  The next scenario presents information
  about how to handle a similar situation.
   
Scenario 2:
  Your mail system doesn't understand MIME stuff at all.  For this,
  you must either content yourself with the "raw" message, or you
  can try to track down some tools to help you.  From John Gardiner 
  Myers <jgm+@CMU.EDU>, we have this advice:

    A minimalist MIME-reading program, munpack, is available via
    anonymous FTP to ftp.andrew.cmu.edu in the directory pub/mpack/.
    The program reads MIME messages and writes the decode parts out to
    files.  Versions are available for Unix, MS-DOS, Macintosh, and
    Amiga platforms.  [ See part 2 of this FAQ for information about
    the mpack tool suite. ]

Scenario 3:
  You don't have all the necessary equipment to listen to an audio
  part, or to view a graphical part, or to read text written
  in a foreign character set.  You're out of luck here; you can 
  handle a lot of MIME stuff on a plain old 24x80 ASCII terminal,
  but let's face it: if you're stuck with something like that, YOU 
  LOSE.  If someone asks you how to listen to an audio message on
  a 24x80 ASCII terminal, call in the Noogie Patrol.  (Yes, this
  kind of question gets asked all the time.  Consult the glossary
  in section 2.4 if you don't know what a noogie is.)

Scenario 4:
  Your mail system doesn't want to show a "message/partial" (like this 
  one).  For this, you may need to assemble all the parts of the
  message together.  

  - With MH, you can assemble the message together using the command
    "mhn -store cur:3".  Alternatively, you can view the "raw" message
    by using the MH command "show -noshowproc".  

  - For mailcap-based mail user agents, the mailcap file needs an
    entry for message/partial.  One entry, contributed by Tim Goodwin,
    is this:

        message/partial; showpartial %s %{id} %{number} %{total}

    The showpartial command is part of the metamail distribution.
    See section 7 for a description of metamail.

  { Brief advice for specific mail systems welcome. }

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

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 ASCII
        - enriched text
        - images
        - sounds
        - other messages (reliably encapsulated)
        - tar files
        - PostScript
        - FTPable file pointers
        - 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.

The ability to create e-mail messages with audio and other non-textual
contents has been around for a while, but almost always as part of a
vendor-specific "solution."  This means that you can't create a
message on a NeXT system containing PostScript information and "Lip
Service" (NeXT's audio e-mail tool) and easily handle the same message
on an HP 9000/710, a Sun SPARCstation IPC, and a Silicon Graphics
Iris.  That's a problem that MIME helps to solve.

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 Procrustean mail transport
protocols, such as BITNET and MMDF, that like to slice, dice, and
stretch the headers and bodies of e-mail messages.

Here are a couple of 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/richtext" form (explained in question 3.2),
	suitable for display on a mildly intelligent ASCII terminal;
	and

        - in a plain text, ordinary message 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.4 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.

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

2.2) MIME features that may or may not be present

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

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

2.3) Further information

A nice overview of the MIME specification by Mark Grand is available
from:

ftp://ftp.netcom.com/pub/mdg/mime.ps
ftp://ftp.netcom.com/pub/mdg/mime.txt

{ Any other documents that should be referenced? }

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

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")
ESMTP           Extended SMTP - RFC 1651
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
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
noogie          Zen technique to improve understanding - knuckles on skull
part            a piece of a MIME message containing some data type
PBM             an image format
PEM             Privacy Enhanced Mail
PostScript      a popular page description language
RFC             request for comments; proposed or standard Internet protocols
SMTP            Simple Mail Transport Protocol - RFC 821
text/enriched   simple text markup language for MIME - RFC 1563
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 worldwide web (see section 4.4)

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

2.5) Newsgroups and mailing lists

 - You're probably reading comp.mail.mime at the moment.  This is
   the USENET newsgroup devoted to discussions of MIME.
 
 
 - There is also a mailing list, info-mime, which 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, send subscription
   requests to:
 
	 info-mime-request@thumper.bellcore.com
 

 - There is a UK exploder for info-mime (info-mime-uk).  Contact:
 
	 info-mime-uk-request@mailbase.ac.uk
 
   The Mailbase software archives all contributions, which are then
   accessible via these URLs:
 
   ftp://mailbase.ac.uk
   gopher://mailbase.ac.uk
 
   ...and via mailserver; send a message to mailbase@mailbase.ac.uk, with
   a message body containing, e.g. "send info-mime-uk 08-1993".
 
 
 - The archive ftp://ftp.ora.com/pub/usenet/comp.mail.mime stores
   articles in three formats: by subject, by article number, and by
   month.  See the README file for more information.
 
 
 - There is also a [comp.mail.multi-media] newsgroup, which contains
   general discussions of multi-media e-mail, not necessarily MIME.
 
 
 - 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.  
--

3) Miscellaneous questions
--------------------------

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.

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

3.2) What's "text/enriched"?  "text/simplemail"?

These two subtypes of the "text" type have a similar aim: to offer
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.

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

The text/enriched type is defined in RFC 1563.  It supersedes
text/richtext, which was defined in RFC 1341.

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

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).  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 will not suffer the same restrictions on export).

PEM will (eventually) be integrated with MIME.  See

    draft-ietf-pem-mime-03.txt

for the latest work on this.

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.

{ This section needs additional information. }

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

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.

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

3.5) What about a group 3 facsimile encoding?

It is rumored that there was an attempt to include G3 FAX in the
original MIME specification, but that it was impossible for the
authors of the MIME specification to gain a consensus on how to encode
the data.  So G3 FAX has been left for a future MIME implementation.
But you can always define your own body part.

Here are some snippets relevant to MIME and FAX.

The MIME-MHS documents define a G3Fax body part that is conformant with
the X.400 G3Fax definition.

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

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

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.

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

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.

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

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) which extend RFC 1327 to define conversions
between MIME and X.400.

Some MTAs, notably the ISODE Consortium's version of PP (see section 8)
have MIME gatewaying support.

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

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.

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

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

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

4) MIME information available from the Internet
-----------------------------------------------

4.1) Anonymous FTP

Information about FTPable stuff is scattered throughout this FAQ.
More specifically, look into the RFCs.  Other goodies can be found in
the MH and MetaMail source trees:

ftp://thumper.bellcore.com/pub/nsb

This contains a collection of MIME sample messages which can be used
to test implementations.

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

4.2) Mail based archive servers

4.2.1) Eitech "ServiceMail"

    [ Jay C. Weber <weber@eitech.COM> 13-Oct-1992 ]

    We (Enterprise Integration Technologies Corporation) have a MIME
    implementation, which we are distributing freely.  Instead of a
    MIME MUA, it is a toolkit for building services that automatically
    process MIME messages.  It is similar, in spirit, to the few other
    e-mail-scripting packages except:

      o it exploits several MIME features
      o it is intended to run standalone (as opposed to a back-end to a MUA)
      o it uses TCL (from Berkeley) as its scripting language

    and support for PEM is in the works.

    EIT is providing ServiceMail access to the ServiceMail toolkit.
    If you have the METAMAIL or some other MIME-compliant mail reader,
    just send the message

        To: services@eitech.com
        Subject: archive-request servicemail.tar.Z

    and read the response(s) using METAMAIL.  Save the result in
    servicemail.tar.Z

    The package can also be retrieved by anonymous FTP from the site
    eitech.com.

    If you have any problems with acquisition, installation, or use,
    don't hesitate to send mail to "servicemail-help@eitech.com" and
    ask for help.

    IF YOU WANT FUTURE UPDATES ON TOOL KIT VERSIONS, BUGS, AND
    SERVICES, MAKE SURE YOU ARE ON THE PACT-KIT MAILING LIST.  To get
    on it, send a message to "services@eitech.com" with subject
    "listserv subscribe pact-kit your-real-name".

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

4.2.2) Metamail "mailserver"

    [ Nathaniel Borenstein <nsb@thumper.bellcore.com> 9-Jan-1993 ]

    The metamail distribution includes a simple "mailserver" shell
    script that can be used to operate a MIME-conformant mail server
    mechanism, e.g. for making anon-ftp files available as MIME mail.
    ServiceMail is also now available under the "contrib" area of the
    metamail distribution.


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

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

4.4) 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
--
    
5) Published books and articles
-------------------------------

 - "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.
 
 
 - Connexions Sep 1992

    [ Alec Henderson <alech@hpindda.cup.hp.com> 18-Dec-1992 ]

    There is a good introductory article on MIME in the September 1992
    issue of Connexions; also several other interesting articles on
    e-mail, both MIME and X.400.  (Ole Jacobsen, the Connexions
    editor, was kind enough to send me a copy of the September issue.)

--

6) MIME based relays for commercial mail services
-------------------------------------------------

6.1) Large national or international providers

{ Lots missing here.  Anyone got any info these, or any others? }
{    America On-line                                            }
{    Dialog                                                     }
{    Genie                                                      }
{    MCI Mail                                                   }
{    Sprintmail                                                 }


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

6.1.1) ATTMAIL

    [ Steve <atthelp@attmail.com> 30-Dec-1992 ]

    We do support binary attachment but are not MIME compliant nor do
    we have an X.400 to MIME conversion header routine. This is 'in the
    works', however, and due to overwhelming interest by our users and
    other prmd's, research and development are currently engaged in
    working on the issue. I do not have any information on when this
    will be available, but will let you know when I receive word of our
    MIME status.

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

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

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

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

{ Should coordinate this with the global e-mail list that is posted to }
{ comp.mail.misc.                                                     }

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

6.2) Local and regional providers

{ Any info?  Should coordinate this with e.g. the PDIAL list. }

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