		What is MIME, and how You can benefit from it ?


This document contains parts:
		- RFC 1341, page 1	Abstract of MIME standard
		- MIME as used by this mailserver
		- MIME-aware mail-clients

Summary:
	Using  "ENCODER BASE64"  enables MIME-encapsulation with
	all of its benefits.


  ------------------------- RFC 1341 page 1 -------------------------
            Network Working Group               N. Borenstein, Bellcore
            Request for Comments: 1341               N. Freed, Innosoft
                                                              June 1992

                   MIME  (Multipurpose Internet Mail Extensions):

                      Mechanisms for Specifying and Describing
                       the Format of Internet Message Bodies

          Status of this Memo

            This RFC specifies an IAB standards track protocol  for  the
            Internet  community, and requests discussion and suggestions
            for improvements.  Please refer to the  current  edition  of
            the    "IAB    Official    Protocol   Standards"   for   the
            standardization  state  and   status   of   this   protocol.
            Distribution of this memo is unlimited.

          Abstract

            RFC 822 defines  a  message  representation  protocol  which
            specifies  considerable  detail  about  message headers, but
            which leaves the message content, or message body,  as  flat
            ASCII  text.   This document redefines the format of message
            bodies to allow multi-part textual and  non-textual  message
            bodies  to  be  represented  and  exchanged  without loss of
            information.   This is based on earlier work  documented  in
            RFC  934  and  RFC  1049, but extends and revises that work.
            Because RFC 822 said so little about  message  bodies,  this
            document  is  largely  orthogonal to (rather than a revision
            of) RFC 822.

            In  particular,  this  document  is  designed   to   provide
            facilities  to include multiple objects in a single message,
            to represent body text in  character  sets  other  than  US-
            ASCII,  to  represent formatted multi-font text messages, to
            represent non-textual material  such  as  images  and  audio
            fragments,  and  generally  to  facilitate  later extensions
            defining new types of Internet mail for use  by  cooperating
            mail agents.

            This document does NOT extend Internet mail header fields to
            permit  anything  other  than  US-ASCII  text  data.   It is
            recognized that such extensions are necessary, and they  are
            the subject of a companion document [RFC -1342].
  -------------------------------------------------------------------


		--==  MIME as used by this mailserver  ==--


	Among the mechanisms are techniques called  "Content-Transfer-
Encoding:" -methods "Quoted-Printable", and "Base64".

There is also a method to send one big file in multiple smaller messages
with enough information for later reassemble those partial messages into
original message for analysing its contents.
("Content-Type: message/partial;...");


	These encoding methods use invariant subset of US-ASCII character
set in somewhat similar fashion to that of UUENCODE, but with more robust
set of characters.

The "Quoted-Printable" is intended for transporting textual information
with relatively few characters with 8th bit set. (ISO-8859-X -character-
sets are supported by MIME-standard. Others will come later.) This method
is not very space efficient; for example  =8F (3 chars) means a character
with numeric code value (hex) 8F.

The "Base64" is like robust version of UUENCODE.  It does not suffer
from character mis-mappings between US-ASCII, and EBCDICs, while still
beeing relatively space efficient (6 bits of data per character.)


When no MIME-encoding is requested, this server assumes user knows it
best, but still puts MIME headers:

	MIME-Version: 1.0
	Content-Type: text/plain; charset=US-ASCII
	Content-Transfer-Encoding: 7bit

Normal MIMEoid method for delivering arbitary files from this server is
to use:

	Content-Type: application/octet-stream;
		name="name of file"
	Content-Transfer-Encoding: base64

Sending GIF or JPEG images have their own formats:

	Content-Type: image/GIF; name="filename.gif"
	Content-Transfer-Encoding: base64

	Content-Type: image/JPEG; name="filename.jpeg"
	Content-Transfer-Encoding: base64

If resulting file is larger than the default 60kB part size limit,
it is split; while using MIME, message is split into N parts with

	Content-Type: message/partial; id=...,
		number=...,total=...

which tells MIME-aware mail clients that original message is split into
multiple parts for delivery, and it should wait untill all parts have
arrived, before it can analyze actual message.





		--==  MIME-aware mail clients  ==--

	To get benefits of MIME, one must use MIME-aware mail-client.
There are at least following:
	- ELM 2.4 (not 2.3) (Needs MetaMail -toolpack)
	- PINE (UNIX, VMS, PC, MAC, .. versions)
	- XMH (some version)
	- MH (some version)
	- MetaMail -toolpack
	- C-client -library (and sample client(s))
	- Z-mail (commercial mail-client)
	- VMS PMDF (since 1991 summer, propably MM -utility)
	  (commercial mailer for VMS machines)

Your nearest source for them depends upon your location, however at
ftp.funet.fi there are at least following:

	/pub/unix/mail/elm/elm-2.4.11.tar.Z	( 782kB)
	/pub/unix/mail/metamail/mm.tar.Z	( 596kB)
	/pub/unix/mail/pine/pine3.05.tar.Z	(1559kB)
	/pub/unix/mail/mh/mh-mime/mh-mime.tar.Z ( 244kB)
		(needs also other files in same directory, circa 400kB)

Where are versions for non-unix platforms,  I don't know.
Ask   msdos-adm/amiga-adm/atari-adm/.. @nic.funet.fi  for pointers.

921203/mea
930710/mea
