Thread View: comp.mail.mime
3 messages
3 total messages
Started by Tim Goodwin
Tue, 30 Nov 1993 18:38
comp.mail.mime frequently asked questions list (FAQ) (1/3)
Author: Tim Goodwin
Date: Tue, 30 Nov 1993 18:38
Date: Tue, 30 Nov 1993 18:38
663 lines
25609 bytes
25609 bytes
Archive-Name: mail/mime-faq/part1
Last-modified: 1993/11/30
Version: 3.2
comp.mail.mime frequently asked questions list (FAQ) (1/3)
Part I -- Frequently Asked Questions
This is part I of a Frequently Asked Questions document about MIME, the
multipurpose and multi-media standard for Internet mail.
Part I covers frequently asked questions.
Part II is a listing of MIME products.
Part III covers advanced topics.
0 Contents
Sections which have changed since the last posting are marked with a `!' in
the first column. New sections are marked with `+'.
Part I -- Frequently Asked Questions
0 Contents
1 Introduction
1.1 Authorship
1.2 Conventions
2 What is MIME?
! 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 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 Radiomail
6.2 Local and regional providers
Part II -- MIME products
! 7 Freely available MIME packages
7.1 Conversions from other mail systems
! 8 Commercial MIME packages
9 Packages for MIME in Usenet
9.1 Introduction
9.2 News readers and transports with MIME support
Part III -- Advanced topics
10 Information
! 10.1 MIME-relevant RFCs and other standards
! 10.2 List of registered 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
This FAQ was begun by Ed Vielmetti. It is now maintained by me, Tim
Goodwin. Contributions have come from a cast of dozens: see section 12
for a list of contributors.
1.2 Conventions
I have used some typographical conventions. Eventually I hope to format
this as simplemail, but in the meantime...
Direct quotations begin with an attribution in a standard format, and
are indented by four spaces.
FTPable goodies appear thus:
FTP: domain.name:path/to/package
Note that I usually list only the distribution site -- please try your
nearest FTP archive first.
You'll occasionally see text in braces, like this.
{ Here is some example meta-text. }
Generally, these indicate places where information is missing, I'm
unsure of my ground, or I plan major changes 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 mail me.
2 What is MIME?
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 email among many different
computer systems that use Internet mail standards.
If you were bored with plain text email messages, thanks to MIME you
now can create and read email 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 email 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 email 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 of PhoneNet from 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 email 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 email 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/enriched'' 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, a low-level network
management facility.)
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 email 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
FTP: ftp.netcom.com:pub/mdg/mime.ps
FTP: ftp.netcom.com:pub/mdg/mime.txt
This is a nice overview of the MIME specification by Mark Grand.
{ 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 1425
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
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 1523
text/simplemail another (even simpler?) text markup language
user agent the end user's mail program, e.g. MH, ELM, /bin/mail, etc.
2.5 Newsgroups and mailing lists
You're probably reading comp.mail.mime at the moment. There is a
mailing list which is gatewayed with comp.mail.mime. 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, contact:
info-mime-uk-request@mailbase.ac.uk
The Mailbase software archives all contributions, which are then
accessible via FTP and gopher (mailbase.ac.uk), and mailserver
(mailbase@mailbase.ac.uk, with message body containing, e.g. "send
info-mime-uk 08-1993"
There is also a [comp.mail.multi-media] newsgroup, which contains
general discussions of multi-media email, not necessarily MIME.
There are various mailing lists specific to particular implementations
of MIME. If I know of such a list, it is mentioned in the section on
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 II 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 standardisation 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 1523. 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 email is not secure. No authentication, confidentiality, or
data integrity properties are provided in SMTP, RFC-822, or MIME.
People desiring any or all of those security properties in their email
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.
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?
{ This section needs some work - any volunteers? }
It is rumored that there was an attempt to include G3 FAX in the
current MIME standard, 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 email 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 was defined in RFC 1327.
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.
{ Sorry this is a bit scant---I haven't even had a chance to read the }
{ RFCs yet. Any contributions to this section gratefully received. }
3.9 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, mentioned in item 2.4. Other
goodies can be found in the MH and MetaMail source trees.
FTP: thumper.bellcore.com:pub/nsb
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
email-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
Published books or articles that cover MIME.
Marshall T. Rose has recently published the fourth book in his
networking "trilogy".
Marshall T. Rose
"The Internet Message: closing the book with electronic mail"
Prentice-Hall
ISBN 0-13-092941-7
It is a reasonably complete, although not technically detailed, review
of the Internet world of electronic mail, including recent developments.
One chapter is devoted to MIME.
[ 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
email, both MIME and X.400. (Ole Jacobsen, the Connexions
editor, was kind enough to send me a copy of the September issue.)
[ Daniel Glazman <Daniel.Glazman@grif.grif.fr> 30-Aug-1993 ]
To be published soon in "TRIBUNIX" the French Unix Users Group
(AFUU) newspaper: "Les extensions MIME", Daniel Glazman.
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 }
{ Compuserve }
{ 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 Radiomail
[ Jerry Sweet <jsweet@irvine.com> 17-Dec-1992 ]
RadioMail Corp. (formerly Anterior Technology) operates three types
of email services having these statuses with respect to MIME:
1. UUCP/Internet gatewaying. The gateway passes MIME messages using
7 bit encodings in either direction. The sender and receiver must,
of course, have MIME-complaint user agents in order to handle MIME
email.
2. 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.
3. Wireless email gatewaying. This service can pass MIME messages
using 7-bit encodings in either direction. However, MIME per se is
understood neither by the MS-DOS hosted user agents presently
supplied by RadioMail Corp. for use on radio modem equipped
computers, nor by any RadioMail-compatible third-party MS-DOS
hosted user agents. This may change.
{ Should coordinate this with the global email 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 I
comp.mail.mime frequently asked questions list (FAQ) (2/3)
Author: Tim Goodwin
Date: Tue, 30 Nov 1993 18:38
Date: Tue, 30 Nov 1993 18:38
1038 lines
36539 bytes
36539 bytes
Archive-Name: mail/mime-faq/part2
Last-modified: 1993/11/30
Version: 3.2
comp.mail.mime frequently asked questions list (FAQ) (2/3)
Part II -- MIME products
This is part II of a Frequently Asked Questions document about MIME, the
multipurpose and multi-media standard for Internet mail.
Part I covers frequently asked questions.
Part II is a listing of MIME products.
Part III covers advanced topics.
7 Freely available MIME software packages
Name: Andrew
Product: Multimedia system
Platform: Unix
FTP:
Author:
Comments:
[ Susan Straub <susan+@andrew.cmu.edu> 11-Jan-1993 ]
Andrew is a very large and ambitious software system developed at
Carnegie Mellon University. It is installed at hundreds of sites
throughout the world, and includes a multimedia document editor,
help system, and various other utilities. In particular, it
includes a feature-rich program, "messages", which can read and
send mail and news articles in MIME format, including images,
audio, richtext, and more. Andrew is available in binary release
for several Unix system architectures, and also in source form.
Be warned that the source distribution is itself about 50
megabytes, but you really are getting a LOT of stuff. For
information on how to obtain a copy of Andrew, send mail to
info-andrew-request@andrew.cmu.edu.
Name: c-client
Product: MUA library code
Platform: Unix, Macintosh, MS-DOS, TOPS-20
FTP:
Author: Mark Crispin
Comments:
[ comp.mail.misc FAQ ]
Software writers only:
c-client is a general library useful for creating MUA's. It
provides a Application Program Interface for retrieving and
manipulating mail messages. It supports the latest draft of
MIME. It is driver based, and easily ported to new platforms and
MTAs. The currently supported platforms include various versions
of BSD and SysV Unix, MS-DOS, Macintosh and even TOPS-20(!). It
supports mailboxes in /usr/spool/mail, mbox, mail.txt, mh, carmel
format, as well as remote mailbox access via the IMAP2 protocol
described in RFC-1176 and extended by the IMAP2bis extensions.
c-client does not contain any user interface. Rather, it contains
everything else that goes into an MUA. c-client is called with
such functions as mail_open(), mail_fetchheader(), mail_setflag(),
etc.
Just the thing if you want to write a new MUA.
Contact the author (Mark Crispin <mrc@panda.com>) for more details.
Name: elm
Product: MUA
Platform: Unix
FTP:
Author:
Comments:
[ Syd Weinstein <syd@dsinc.dsi.com> 21-Dec-1992 ]
Elm support for MIME:
2.3 - uses metamail supplied patch from Nathaniel Borenstein.
2.4:
reading: detects MIME headers and calls metamail automatically
if the message cannot be displayed on the current screen using
the native capabilities of the display (recognizes some char
sets as native)
sending: detects [include ] markers and makes them MIME attachments.
Still very 'crude', but its all we had time for, as to the
release deadline of 'Elm' and MIME.
3.x:
reading: probably no change from 2.x, but will understand
some 'file storage' types and allow for splitting off attachments
on their own.
sending: will allow defining attachments to be added and auto build
the MIME stuff, in addition to the [include ] syntax.
release status:
2.3: obsolete
2.4: Current PL is 17.
3.x: not planned until some time in 1994.
Name: emil
Product: tool
Platform: Unix
FTP: ftp.uu.se:pub/unix/networking/mail/emil
FTP: ftp.sunet.se:pub/unix/mail/emil
Author: Martin Wendel <martin@alba.udac.uu.se>
Comments:
[ Martin Wendel <martin@alba.udac.uu.se> 8-Nov-1993]
Emil is a tool for converting between message formats used by MIME,
Eudora, SUN mailtool, PC and Mac based clients, etc. It is easily
extensible. It can work either standalone, as an argument driven
filter program, or, if linked with sendmail8.6. or IDA sendmail,
as a mail gateway convertering messages sent between various types
of Internet mail clients. It will give a possibility to convert
encoding formats of attachments and convert character sets of
text. It can make a heterogenous mail environment, consisting of
various types of mail clients, act as a homogenous environment; for
instance sending only MIME based messages to the outside world.
Name: encdec
Product: tool
Platform: ISO C
FTP: ftp.efd.lth.se:pub/mail/encdec.c.gz
Author: Joergen Haegg <jh@efd.lth.se>
Comments: encdec is a simple standalone encoder/decoder for base64 and
quoted printable written in ISO C.
Name: Eudora 1.4
Product: MUA
Platform: Macintosh
FTP: qualcomm.com:mac/eudora/1.4/Eudora1.4.sea.hqx
Author: Steve Dorner <sdorner@qualcomm.com>
Comments:
Eudora 1.4 is a MUA for Macs that uses POP3 and SMTP and supports MIME.
Name: HUyMail
Product: MTA/MUA
Platform: VMS
FTP: ftp.technion.ac.il:pub/unsupported/vms/local/local/huymail*.bck
Author: Yehavi Bourvine
Comments:
[ Yehavi Bourvine <YEHAVI@vms.huji.ac.il> 22-Jul-1993 ]
HUyMailer is a store and forward mailer for VAX/VMS and AXP/VMS
systems which supports as transports: DECnet, Multinet/TcpIp,
HUJI-NJE and PMDF. The software is available freely for
non-commercial use as a C source code.
The mailer supports two users' interfaces: VMS/MAIL (to which the
connection is done via MAIL11 DECnet connection) or a locally
written interface called BMAIL. BMAIL is a menu oriented interface
which supports MIME and Hebrew.
Name: Iride
Product: MUA
Platform: Macintosh
FTP: gnbts.univ.trieste.it:mime/Iride.sea.hqx
Author: GNBTS
Comments:
[ From the README ]
Iride is (or will be -- it's currently in beta test) an
implementation of a MIME user agent on the Apple Macintosh
computer. It was developed as part of a project of the GNBTS -
Gruppo Nazionale Bioingegneria sezione di Trieste, for the
integration of multimedia mail with hospital data storing
facilities, in particular for the transfer of bioimages.
This is a far from a complete MIME implementation, but I think
it is quite usable.
To use it you need:
o Macintosh with MacTCP 1.1 or better installed
o 32 bit ColorQuickDraw if you want to use images
o audio input device if you want to create audio messages
o connection to a SMTP mail relay
o connection to a POP3 server
MIME types supported:
text/plain charset=US-ASCII only
text/richtext (no tool for composing richtext yet)
audio/basic
audio/X-macaudio generated when a NOT sampled audio pasted in
image/GIF
image/X-macPICT generated when color QuickDraw is missing only
multipart/mixed each part is shown in a different window
MUST change this
multipart/parallel
multipart/alternative handled as multipart/mixed
MUST change this
Name: metamail
Product: MUA and tools
Platform: Unix Amiga MS-DOS
FTP: thumper.bellcore.com:pub/nsb/mm.2.6.tar.Z
The metamail distribution that Nathaniel Borenstein supports.
FTP: thumper.bellcore.com:pub/nsb/contrib2.6.tar.Z
Contributed sources.
FTP: thumper.bellcore.com:pub/nsb/amiga2.5.tar
Amiga binaries and utilities
FTP: thumper.bellcore.com:pub/nsb/dos2.5.tar.Z
MS-DOS binaries
Author: Nathaniel Borenstein
Comments:
[ Paul Eggert <eggert@bi.twinsun.com> ]
Metamail is a software implementation of MIME, designed for easy
integration with traditional mail-reading interfaces -- typically,
users do not invoke metamail directly. Ideally, extending the
local email or news system to handle a new media format is a
simple matter of adding a line to a mailcap file. Mailcap files
are described in RFC 1343.
Name: MH 6.8
Product: MUA
Platform: Unix
FTP: ftp.ics.uci.edu:pub/mh/mh-6.8.tar.Z
FTP: louie.udel.edu:portal/mh-6.8.tar.Z
Author:
Comments:
MIME support is available for the MH message handling system; the
primary reader and generator is the program mhn(1) although other MH
programs are also changed. The current release of MH is 6.8, the first
to include MIME support when appropriately installed. mhn does not
use the mailcap mechanism described in RFC 1343.
A tutorial for mhn is available:
FTP: ftp.ics.uci.edu:mh/contrib/multimedia/mhn-tutorial.tex, .sty, .ps
See the newsgroup comp.mail.mh for further information.
Name: MIME for VM/CMS
Product:
Platform: VM/CMS
FTP: { gopher, see comments }
Author:
Comments:
[ Rick Troth <TROTH@ricevm1.rice.edu> 21-Jul-1993 ]
This MIME decoder is available via Gopher from ricevm1.rice.edu
under "Other freely distributable CMS software", which is under
"CMS Gopher Software".
It correctly reads:
o text/plain,
o text/richtext, and
o image/gif.
GIFs require the VMGIF package from Belgium. I need filters for
PBM and PGM and then they'd work too. Sounds are not useful on
the standard 3270 terminal (dumb terminals just don't play sounds).
It splits out multipart/[anything] into separate files. CMS has a
standard directory "browser" (FILELIST) that lets you view a bunch
of related files and decide what, if anything, you want to do with
them.
Message/external-body doesn't work well, but probably will given
more development time. I could use some samples to help with the
debugging of that part.
It does NOT do applications, except for the one, octet-stream.
(which is treated as a kind-of "sendfile" utility) There *is* a
PostScript interpreter for CMS, but it is reported to be a dog (we
don't have it). But I do hope to put the extraction code in for
these eventually.
If a given content-type isn't understood, you just view the item
as-is.
For composition, there's no CHARSET= parameter on the
Content-Type: text/plain line. It's EBCDIC until it gets into
SMTP, then it's ASCII, then it might be anything, so I've left off
the CHARSET= parameter.
An "attach" command is added to RiceMAIL when you run this, which
would then change the message from text/plain to multipart/mixed
and append the attachment after a boundary. Attachments don't
"close" properly; that is, the final boundary isn't correct, but is
correctly processed by all of the MIME compliant readers I've
checked. (there's some feature of RiceMAIL that causes this)
This thing is based on CMS Pipelines, so adding features is easy
since we now have the base for MIME processing.
Name: MIME tools for GNU Emacs
Product: MUA
Platform:
FTP: wnoc-fuk.wide.ad.jp:pub/GNU/etc/emacs-mime-tools.shar
Author: Masanobu UMEDA
Comments:
[ Masanobu UMEDA <umerin@mse.kyutech.ac.jp> 07-Aug-1993 ]
MIME tools that consist of "mime.el", "rmailmime.el" and
"metamail.el" are tools for reading and composition of MIME
messages for GNU Emacs and its variants. "mime.el" is a simple
MIME message composer that works with mail mode, news mode, and
mhe letter mode. Messages of plain and richtext text, audio, and
image, and multipart messages of them can be composed by using
"mime.el". "rmailmime.el" is for reading MIME messages within
Rmail. "metamail.el" is an interface to metamail. The metamail
package is required by these tools.
Name: MIME tools for NeXT
Product: editor
Platform: NeXT
FTP:
Author: Dave Lacey
Comments:
[ Dave Lacey <dave@blackbox.isca.uiowa.edu> ]
I'd like to keep you apprised of some MIME work I'm doing. I'm
interested in using MIME as a transport medium for multi-media
gopher documents. My particular use is for Radiology info, but it
would work for just about anything.
I've got a NeXT Gopher client almost working and I also have a
NeXT based MIME file editor that reads/creates MIME documents.
Both work, but need a bit more extension. I will likely
distribute the source to this, so the MIME reader (which is
essentially an object) can be re-used in other apps.
Name: MIXMH
Product: MUA
Platform: Unix with X
FTP: aun.uninett.no:pub/unix/mixmh-0.2.tar.Z
Author:
Comments:
[ Harald Tveit Alvestrand <Harald.Alvestrand@delab.sintef.no> 10-Dec-1992 ]
This version is based on XMH version 1.6 from SEI, Carnegie Mellon.
It supports sending MIME with extended character sets in the headers
(per RFC 1342) and the body (per RFC 1341 text/plain). It has
limited support for multipart messages.
The source is freely redistributable and modifiable.
As you can see from the version number, it is still not considered
fully stable. Bugs may be reported to mixmh-bugs@uninett.no
Information and discussion will take place on mixmh-info@uninett.no;
mail to mixmh-info-request@uninett.no to join.
Name: mpack
Product: MUA/utility
Platform: Unix, MS-DOS, Macintosh, Amiga
FTP: export.acs.cmu.edu:pub/mpack/mpack-1.0-src.tar.Z
Sources for all versions except Amiga
FTP: export.acs.cmu.edu:pub/mpack/mpack-1.0-src-amiga.tar.Z
Additional sources for Amiga
FTP: export.acs.cmu.edu:pub/mpack/mpack-1.0-pc.tar.Z
MS-DOS binaries
FTP: export.acs.cmu.edu:pub/mpack/mpack-1.0-mac.hqx
Macintosh binary
FTP: export.acs.cmu.edu:pub/mpack/mpack-1.0-amiga.lha
Amiga binaries
Author: John Gardiner Myers, Chris Newman (Mac), Mike Meyer (Amiga)
Comments:
[ John Gardiner Myers <jgm+@CMU.EDU> 2-Oct-1993 ]
Mpack is a minimal implementation of MIME, designed for encoding and
decoding binary files in MIME messages. In short, it is the MIME
equivalent of uuencode and uudecode. For backwards compatibility,
it can also decode messages in split-uuencoded format.
Name: Pegasus mail
Product:
Platform: MS-DOS, MS-Windows, Macintosh
FTP: risc.ua.edu:pub/network/pegasus/*
Author: David Harris <david@pmail.gen.nz>
Comments:
[ James Ford <JFORD@ua1vm.ua.edu> 2-Nov-1993 ]
Pegasus Mail is an Email package for Novell network v2.15 and higher
that supports MHS (natively) and SMTP. The MS-DOS version (v3.01a)
is MIME compliant; the MS-Windows version should be by mid-November.
I do not know the timetable for the Mac version. You can either
get a PC-based SMTP gateway for it (Charon, by Brad Clements) or a
(Netware v3.11) NLM-based version (Mercury, by David Harris) from
risc.ua.edu. I believe that the SMTP gateway Mercury supports 8-bit
MIME encoding.
Name: Pine
Product: MUA
Platform: Unix
FTP: pine.cac.washington.edu:mail/pine.tar.Z
Full distribution, including Pico and IMAPd
Binaries also available in the same directory
Author: Laurence Lundblade, Michael Seibel, Mark Crispin
Comments:
[ From the release notes 21-Sep-1993 ]
Pine(tm) --a Program for Internet News & Email-- is a tool for
reading, sending, and managing electronic messages. It was designed
specifically with novice computer users in mind, but can be tailored
to accommodate the needs of "power users" as well. Pine uses
Internet message protocols (e.g. RFC-822, SMTP, MIME, IMAP, NNTP)
and runs on Unix and MS-DOS.
The guiding principles for Pine's user-interface were: careful
limitation of features, one-character mnemonic commands,
always-present command menus, immediate user feedback, and high
tolerance for user mistakes. It is intended that Pine can be learned
by exploration rather than reading manuals. Feedback from the
University of Washington community and a growing number of Internet
sites has been encouraging.
Pine's message composition editor, Pico, is also available as a
separate stand-alone program. Pico is a very simple and easy-to-use
text editor offering paragraph justification, cut/paste, and a
spelling checker.
7.1 Conversions from other mail systems
A number of older email systems have defined ad hoc ways of dealing
with binary file enclosures and multipart messages. This section is
a pointer to some tools that would aid in transition efforts to the
standard MIME approach.
Name: n2m
Product: conversion tool
Platform: NeXT
FTP: nexus.yorku.ca:pub/n2m.shar
Author:
Comments:
[ Dave Collier-Brown <davecb@ccs.yorku.ca> 04-Jan-1993 ]
Nn2m is a program that converts a file containing a NeXT-format
multimedia message into a file containing a MIME-format multimedia
message.
It is usable on Berkeley-derived systems, or ones otherwise using
/usr/lib/sendmail as a mail transfer agent. It is in use on SunOS
4.1.1 and Ultrix 4.2, tested briefly on Aix 3.2 and NeXT.
Description: it is used with non-NeXT mail user agents to convert
NeXT mail to MIME, which is intelligible to more than just the NeXT
mail program. The resulting file will usually be more intelligible
to non-multimedia mail user agents.
The textual part of the mail is converted into text, as well as
Microsoft RTF, and the attachments follow, as text/plain wherever
possible, as base64 encoded binaries otherwise. This suffices for
messages with ASCII files pasted into them.
Caveat: This is a converter, not a translator: the conversion of
sound and of the initial ``index.rft'' file is not correctness-
preserving.
Name: sun-to-mime
Product: conversion tool
Platform: OpenWindows
FTP: cs.utk.edu:pub/MIME/sun-to-mime.perl
FTP: cs.utk.edu:pub/MIME/sun-to-mime.c
Author: Keith Moore
Comments:
[ Keith Moore <moore@cs.utk.edu> 27-Dec-1992 ]
A perl script (and conversion to C of same) that converts
OpenWindows mail to MIME. Body parts currently supported are:
text, gif, Sun rasterfile (converted to image/gif), postscript, and
audio. Other types default to application/octet-stream. It's easy
to extend the set of types supported and to add conversions, if
necessary.
The script requires uuencode, uudecode, zcat (aka uncompress),
and the "convert" program from ImageMagick. If you don't have
ImageMagick you can probably substitute the pbm stuff with little
fuss.
Name: uu-to-mime
Product: conversion tool
Platform: perl
FTP: cs.utk.edu:pub/MIME/uu-to-mime.perl
Author: Keith Moore <moore@cs.utk.edu>
Comments: A perl script that translates an RFC 822 message containing a
single uuencoded file to a MIME message containing a
base64-encoded file.
8 Commercial MIME software packages
Name: ECSMail
Product: MUA/MTA
Platform: Unix, NT, OS/2, OpenVMS, MS-DOS, MS-Windows, Mac System 7
Contact: ECS Sales <ecs-sales@edm.isac.ca>
Author:
Comments:
[ Steve Hole <steve@edm.isac.ca> 24-Aug-1993 ]
ECSMail is an electronic mail product for building enterprise mail
systems. It is designed from start to finish as a system for
establishing mail services throughout an organization, with external
organizations and the world information system in general. It does
this by using a completely standards based architecture.
ECSMail is comprised of the following system components:
ECSMail MUA Set - a set of Mail User Agents (MUA)
ECSMail MTA Set - a set of Message Transport Agents (MTA)
ECSMail MS Set - a set of Message Services (MS)
All components support both MIME/822 and X.400, and run under
Unix, Microsoft NT, OS/2, OpenVMS. Additionally, the MUA Set runs
under MS-DOS, Microsoft Windows, and Mac System 7.
Pricing for the ECS products and ISA business information can be
obtained by contacting:
ECS Sales
835 10040 - 104 Street
Edmonton, Alberta, Canada
T5J 0Z2
Phone: 403-420-8081
Fax: 403-420-8037
or by sending a request through electronic mail to the address:
ECS Sales <ecs-sales@edm.isac.ca>
Name: Eudora 2.0
Product: MUA
Platform: Macintosh
Contact: eudora-sales@qualcomm.com
Author: Steve Dorner <sdorner@qualcomm.com>
Comments:
A commercial version with more features than the freely available one. For
pricing information, see
FTP: qualcomm.com:/mac/eudora/E_by_QC.sea.hqx
Name: IBM multimedia mail
Product:
Platform: OS/2
Contact: Jerry Cuomo <gcuomo@watson.ibm.com>
Author: IBM
Comments:
[ Larry Salomon Jr <os2man@panix.com> 10-Dec-1992 ]
I'm not going to follow this group, but I wanted to state that IBM -
at the T.J. Watson Research Center - is developing a multimedia mail
application for OS/2 which is based on the Mime spec. They demoed
it at Interop.
For more information, including (probably) how to become a test site
(I haven't confirmed whether they're actually going to do this,
but they've done it before), contact the department manager, Jerry
Cuomo, at gcuomo@watson.ibm.com.
Name: iGate
Product: WordPerfect Office gateway
Platform:
Contact: smart@actrix.gen.nz
Author: Smart Systems
Comments:
[ Quentin Smart <smart@acme.gen.nz> 25-Sep-1993 ]
iGate provides seamless conectivity to SMTP mail from WordPerfect
office. Running as a native gateway under the Office Connection
server and incorporting a TCP/IP stack iGate is a complete solution
with no extras like MHS or TCP/IP stacks required.
Further information from:
Smart Systems
PO Box 5017
Wellington, New Zealand
+64 6 3561484
smart@actrix.gen.nz
Name: Mail*Hub
Product:
Platform: Control Data 4000 Series Mips-based Unix systems
Contact: rrr@svl.cdc.com
Author: Control Data Systems
Comments:
[ <rrr@duck.svl.cdc.com> 23-Dec-1992 ]
Mail*Hub includes support for X.400, X.500, SMTP, and creating,
viewing, and sending MIME enclosures in mail. In addition, the Fax
Gateway portion of Mail*Hub supports sending mail with MIME
enclosures to a Fax machine. Graphical MIME components
(Postscript, GIF, TIFF,...) are automatically recognized and
imaged at the receiving Fax machine.
Name: Mail-it
Product: MUA
Platform: MS-Windows
Contact: mail-it@unipalm.co.uk
Author: Unipalm Ltd
Comments:
[ Tom Kermeen <tomk@unipalm.co.uk> 11-Aug-1993 ]
Mail-it is a mail user agent for Windows 3.1. Implemented using the
Microsoft Extended MAPI architecture and with MIME functionality
added in, Mail-it v2.0 has a wide range of features including:
full drag and drop;
hierarchical foldering;
interaction with mail-aware and mail-enabled applications (MAPI);
full MIME support;
local address book;
access to MAPI-enabled directory services;
support for SMTP, POP2, POP3, and UUCP;
Currently in beta, Mail-it v2.0 will ship in Q4 93. For further
information email mail-it@unipalm.co.uk.
Name: MEUF
Product: MUA
Platform: Unix/X
Contact:
Author: Daniel Glazman
Comments:
[ Daniel Glazman <Daniel.Glazman@grif.grif.fr> 30-Aug-1993 ]
Meuf is a student project (now 2 years old) I developed at Ecole
Nationale Superieure des Telecommunications de Paris with the
System staff. It has grown A LOT to become a MIME-native MUA
running under Xt/Xaw.
Earlier non-MIME versions (1.3 and 1.4) are available by anonymous
ftp from ftp.inria.fr and ftp.enst.fr. They are used by at least 4
industrial and academic sites in France.
Meuf full-MIME version is currently in beta-test and may become a
commercial product.
Name: MPOWER
Product:
Platform:
Contact:
Author: HP
Comments:
[ Harald Alvestrand <Harald.Alvestrand@delab.sintef.no> 22-Jan-1993 ]
If anyone is interested, the new multimedia product from HP called
MPOWER supports MIME format mail.
You can drag and drop a picture onto the mail icon, and it will be
sent as a MIME message.
(Unfortunately, they forgot to quote the delimiter that had a dot in
it, and PINE failed to parse that......well, it's a betatest.)
Name: PC-MM (PC Mail Manager)
Product: MUA
Platform: MS-Windows
Contact: Lars_Hagberg@li.icl.se
Author: ICL
Comments:
[ Tomas Kullman <tomku@li.icl.se> 30-Sep-1993 ]
PC-MM from ICL is a Mail User Agent for Windows 3.1 implemented on
Windows Socket API and TCP/IP. PC-MM is currently working on PC-NFS
but is designed to be network software independent (i.e. will work
on most TCP/IP softwares supporting WinSocket API).
PC-MM is a MIME conformant internet mailer supporting SMTP and IMAP2
for sending and receiving. PC-MM requires a UNIX mail server (or
similar supporting SMTP and IMAP2).
PC-MM V1.0 supports a lot of nice features, such as:
- user friendly interface
- built-in and user-defined text editor
- drag and drop between folders
- local and server based folders
- integrated address book
- message sorting and tagging
- "watch dog" for incoming messages
PC Mail Manager is announced and volume shipping mid November 1993.
For pricing and product packaging information please contact Lars
Hagberg at ICL ProSystems AB; E-mail: Lars_Hagberg@li.icl.se or
phone: + 46 (0)13 11 70 00.
Name: PMDF
Product: MTA
Platform: VMS
Contact: sales@innosoft.com service@innosoft.com
Author: Innosoft International
Comments:
The VMSNET newsgroup 'vmsnet.mail.pmdf' is available for discussion.
[ Ned Freed <ned@innosoft.com> ]
Send technical inquiries to service@innosoft.com. Product
information, pricing, and literature can be obtained from
sales@innosoft.com. The phone number is (909) 624-7907; FAX is
(909) 621-5319. Street address is:
Innosoft International, Inc.
250 W. First St., Suite 240
Claremont, CA 91711
Name: PP
Product: MTA
Platform: Unix
Contact:
Author:
Comments:
PP is a Mail Transport Agent (MTA), kindof son-of-MMDF-plus-X.400. It
is built on ISODE.
[ Harald Alvestrand <Harald.Alvestrand@delab.sintef.no> 18-Dec-1992 ]
The ISODE Consortium release of PP will in the near future support
gatewaying between MIME and X.400 according to the MIME-MHS
Internet-Drafts.
It will also support ESMTP.
Name: SMTPLINK 2.1
Product:
Platform:
Contact:
Author:
Comments:
[ <support@ccmail.com> 16-Dec-1992 ]
Because this version (2.1) is a 2-3 QTR-93 release you should be
talking to your sales rep about the tentative features of this
product. They can be reached at 800-448-2500.
Name: STI Document Browser
Product: MS-Windows 3.1 (shipping), NeXTstep/X11/VMS (in the pipeline)
Platform:
Contact: info@sti.fi
Author: Stream Technologies Inc
Comments:
[ Ed Anselmo <anselmo@nic.near.net> 31-Dec-1992 ]
Product name: STI Document Browser
Platforms:
How and where to get:
Stream Technologies Inc.
Valkjarventie 2
SF-02130 Espoo
FINLAND
Tel: +358 0 43577340
Fax: +358 0 43577348
Email: info@sti.fi
Name: Super-TCP
Product:
Platform: MS-Windows
Contact: TCP@FrontierTech.COM
Author: Frontier Technologies
Comments:
[ Ray C Langford <ray@isi.frontiertech.com> 28-Apr-1993 ]
Frontier Technologies' Super-TCP for MS-Windows includes MIME
support in their Email mail system that is a part of the Super-TCP
for Windows package.
Super-TCP for Windows is a Windows Sockets compliant, 100% DLL
implementation that can also operate in a TSR mode. Applications
include: Network News Reader, Telnet, FTP Client/Server, NFS
Client/Server, SMTP/POP2&3 MIME Email, Telnet Redirector,
Interactive Talk, and more. Options are also available for PPP,
X.25, and OSI.
With the MIME support in Email, any type of binary file may be
attached to your message, including Postscript files, spreadsheet
files, database files, word processor files, graphic files, audio
files, and digital video files.
The packages in the Super-TCP product line that include the
Email (SMTP/POP2&3) with MIME support are:
- Super-TCP for Windows Version 3.0
(Complete TCP/IP package)
- Super-TCP/NFS for Windows Version 3.0
(Complete TCP/IP package with NFS client/server)
- Super-TCP Applications for Windows Version 3.0
(Windows Sockets applications only)
For further information, email TCP@FrontierTech.COM or call
+1 414 241-4555.
Name: Z-Mail
Product: MUA
Platform: Unix
Contact: info@z-code.com
Author: Z-Code Software Corporation
Comments:
[ Carlyn M. Lowery <lowery@zen.z-code.com> 29-May-1993 ]
Z-Mail, a Unix World Magazine "Product of the Year" winner for 1991,
is a complete electronic mail system for workstations. Z-Mail
provides Motif and Open Look graphical user interfaces, as well
as two character modes. The software has been ported to nearly
every system that runs Unix, and it works with all standard Unix
mail transport agents including sendmail, binmail, smail, MMDF and
X.400 gateways. Z-Mail can replace or coexist with standard mail
user agents on the system, including BSD Mail, AT&T mailx, Sun Mail
Tool, Elm, or Mush. Most anyone can use Z-Mail "off the shelf" and
immediately benefit from its simple interface and advanced features.
Z-Mail also includes Z-Script, a powerful scripting language that
enables users to customize and extend Z-Mail's capabilities.
Z-Mail's multi-media capabilities allow easy integration with
best-of-class products including spreadsheets, desk-top publishing,
graphics, fax, voice, and video. For example, when users receive a
spreadsheet file, Z-Mail can be configured to automatically launch
the associated application and load the the attachment automatically
and transparently to the user. Z-Mail understands MIME-format
documents and is also compatible with Sun's multimedia Mailtool.
Mac, MS-DOS, and MS-Windows versions, as well as native MIME
support, are planned for this summer.
For more information on Z-Mail, contact:
Z-Code Software Corp.
4340 Redwood Hwy., Suite B-50
San Rafael, CA 94903
tel: (415) 499-8649
fax: (415) 479-0448
e-mail: info@z-code.com
Also, you can anonymous-ftp a demo copy of Z-Mail from "ora.com" in
the directory pub/z-code/zmail/2.1. (The file you want is named
zm.XXX.tar.Z, where XXX is your type of machine.) You'll need to
call us after you do so we can send you an activation key.
9 MIME and Usenet news
9.1 Introduction
Usenet articles are (by design) very similar to RFC 822 mail messages.
It is therefore reasonable to expect MIME software to be adopted for use
on Usenet.
9.2 News readers and transports with MIME support
Name: GNUS
Product: reader
Platform: GNU Emacs
FTP:
Author: Masanobu UMEDA
Comments:
[ Masanobu UMEDA <umerin@mse.kyutech.ac.jp> 07-Aug-1993 ]
GNUS is an NNTP-based newsreader for GNU Emacs. GNUS versions
3.14.4 and later directly support reading of articles written in
MIME format. It only requires the metamail package. Compositions
of articles written in MIME format requires "mime.el" that is a
part of MIME tools for GNU Emacs (see 3.13).
Name: gnus-mime.el
Product: reaJoe Ilacqua der
Platform: GNU Emacs
FTP: world.std.com:dist/gnus-mime.el.shar
(also in the contrib tree of metamail)
Author: Joe Ilacqua
Comments:
[ Joe Ilacqua <spike@world.std.com> 24-Jun-1993 ]
"gnus-mime.el" is an ELISP package that adds support for MIME to
GNUS. This is the second release: I consider it very beta, and I'm
sure there are bugs, but it does work. It provides support both to
read and to post USENET articles in MIME format. It's scarcest
feature is support for multi-part multi-media ".signatures".
I believe that gnus-mime.el is for GNUS prior to version 3.14.4.
Name: INN
Product: transport
Platform:
FTP:
Author:
Comments:
[ Christopher Davis <ckd@eff.org> 03-Jun-1993 ]
There is some minimal MIME support in the INN package. Since INN
is a transport system, not a newsreader, the support is for
transferring MIME messages, not reading them.
[ Christophe Wolfhugel <Christophe.Wolfhugel@grasp.insa-lyon.fr> 23-Jul-1993 ]
INN's MIME support is today divided in two parts:
1) the possibility to have nnrpd add default MIME headers to
locally posted articles;
2) transfer-encoding changes on transport with `innxmit', i.e. recode
8bit to quoted-printable.
Name: MH
Product: reader
Platform:
FTP:
Author:
Comments:
[ John Romine <jromine@ics.uci.edu> 30-Jul-1993 ]
If you compile MH to use NNTP, it can read news with its "bbc"
command; MH supports MIME.
Name: nn
Product: reader
Platform:
FTP:
Author:
Comments:
[ Luc Rooijakkers <lwj@cs.kun.nl> 26-Jul-1993 ]
The current beta release of nn tags newly posted articles as
text/plain; charset=xxx with transfer encoding 8bit if the message
contains any 8 bit characters.
Reading support needs further work.
Name: SNews
Product: reader
Platform: MS-DOS OS/2
FTP: ftp.wimsey.com:~ftp/pub/msdos/uupc/snews191.zip
MS-DOS binaries
FTP: ftp.wimsey.com:~ftp/pub/msdos/uupc/snws191o.zip
OS/2 binaries
FTP: ftp.wimsey.com:~ftp/pub/msdos/uupc/snws191s.zip
Source
Author:
Comments:
[ Daniel Fandrich <dan@fch.wimsey.bc.ca> 27-Aug-1993 ]
Revision 1.91 of the SNews newsreader for MS-DOS systems
fixes several bugs in version 1.90 (alpha), as well as adding
some much-needed features, including built-in support for ISO
8859/1/2/3/4/9 character sets (RFC 1521 and RFC 1522) and a single
key interface to the metamail MIME decoder (or other user-specified
program). An additional bonus is the availability of an OS/2
version.
Name: trn
Product: reader
Platform:
FTP:
Author:
Comments:
trn 3.0 has support for reading MIME articles with metamail, and
creating them with mhn.
End of Part II
comp.mail.mime frequently asked questions list (FAQ) (3/3)
Author: Tim Goodwin
Date: Tue, 30 Nov 1993 18:38
Date: Tue, 30 Nov 1993 18:38
341 lines
16134 bytes
16134 bytes
Archive-Name: mail/mime-faq/part3
Last-modified: 1993/11/30
Version: 3.2
comp.mail.mime frequently asked questions list (FAQ) (3/3)
Part III -- Advanced Topics
This is part III of a Frequently Asked Questions document about MIME, the
multipurpose and multi-media standard for Internet mail.
Part I covers frequently asked questions.
Part II is a listing of MIME products.
Part III covers advanced topics.
10 Information
10.1 MIME-relevant RFCs and other standards
The RFCs mentioned here are mainly relevant to people building MIME
software. As an end user, if your mail system is nice to you, you
won't really have to know very much about these things.
RFC and Internet-Drafts are available by anonymous FTP from any decent
archive site. If you're really stuck, try
FTP: ds.internic.net:rfc/*
FTP: ds.internic.net:internet-drafts/*
MIME is defined in RFC 1521 (MIME Mechanisms for Specifying and
Describing the Format of Internet Message Bodies) and RFC 1522
(Representation of Non-ASCII Text in Internet Message Headers).
These are Internet standards-track protocols. For the full
implications of this, see RFC 1540 (IAB Official Protocol Standards).
Here is their current status.
1521: Draft Elective Standard
1522: Draft Elective Standard
These two RFCs do not fully define MIME. For one thing, they are
based on RFC 822 (Standard for the format of ARPA Internet text
messages), as revised by RFC 1123 (Requirements for Internet hosts -
application and support) and must be read in conjunction with these.
For another, they are extensible. See 10.2 for a complete list of
registered subtypes.
There are a whole lot of other RFCs that deal with email, including
these.
IAB standards-track RFCs
1502 X.400 Use of Extended Character Sets
1496 Rules for Downgrading Messages from X.400(88) to X.400(84)
when MIME Content-Types are Present in the Messages
1495 Mapping between X.400 and RFC-822 Message Bodies
1494 Equivalences between 1988 X.400 and RFC-922 Message Bodies
1427 SMTP Service Extension for Message Size Declaration.
1426 SMTP Service Extension for 8bit-MIMEtransport.
1425 SMTP Service Extensions.
1424 Privacy Enhancement for Internet Electronic Mail: Part IV.
1423 Privacy Enhancement for Internet Electronic Mail: Part III.
1422 Privacy Enhancement for Internet Electronic Mail: Part II.
1421 Privacy Enhancement for Internet Electronic Mail: Part I.
1327 Mapping between X.400(1988)/ISO 10021 and RFC 822.
1314 File format for the exchange of images in the Internet.
Other RFCs (Informational, Experimental, or Historical)
1489 Registration of a Cyrillic Character Set.
1468 Japanese Character Encoding for Internet Messages.
1456 Conventions for Encoding the Vietnamese Language.
1428 Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME.
1357 Format for emailing bibliographic records.
1345 Character Mnemonics & Character Sets.
1344 Implications of MIME for Internet mail gateways.
1343 User agent configuration mechanism for multimedia mail format
information.
1339 Remote mail checking protocol.
1321 MD5 Message-Digest algorithm.
1225 Post Office Protocol: Version 3.
1211 Problems with the maintenance of large mailing lists.
1176 Interactive Mail Access Protocol: Version 2.
1197 Using ODA for translating multimedia information.
1154 Encoding header field for internet messages.
1153 Digest message format.
1049 Content-type header field for Internet messages.
1036 Standard for interchange of USENET messages.
934 Proposed standard for message encapsulation.
807 Multimedia mail meeting notes.
10.2 List of registered MIME types
A list of registered MIME types is available from
FTP: isi.edu:in-notes/mime/mime-types
This is the latest version.
Type Subtype Description Reference
---- ------- ----------- ---------
text plain [169,NSB]
richtext [169,NSB]
tab-separated-values [Paul Lindner]
multipart mixed [169,NSB]
alternative [169,NSB]
digest [169,NSB]
parallel [169,NSB]
appledouble [MacMime,Patrik Faltstrom]
header-set [Dave Crocker]
message rfc822 [169,NSB]
partial [169,NSB]
external-body [169,NSB]
news [RFC 1036, Henry Spencer]
application octet-stream [169,NSB]
postscript [169,NSB]
oda [169,NSB]
atomicmail [atomicmail,NSB]
andrew-inset [andrew-inset,NSB]
slate [slate,terry crowley]
wita [Wang Info Transfer,Larry Campbell]
dec-dx [Digital Doc Trans, Larry Campbell]
dca-rft [IBM Doc Content Arch, Larry Campbell]
activemessage [Ehud Shapiro]
rtf [Paul Lindner]
applefile [MacMime,Patrik Faltstrom]
mac-binhex40 [MacMime,Patrik Faltstrom]
news-message-id [RFC 1036, Henry Spencer]
news-transmission [RFC 1036, Henry Spencer]
wordperfect5.1 [Paul Lindner]
pdf [Paul Lindner]
zip [Paul Lindner]
macwriteii [Paul Lindner]
msword [Paul Lindner]
remote-printing [RFC1486,MTR]
image jpeg [169,NSB]
gif [169,NSB]
ief Image Exchange Format [RFC-1314]
tiff Tag Image File Format [MTR]
audio basic [169,NSB]
video mpeg [169,NSB]
quicktime [Paul Lindner]
Each <type> has a directory
FTP: isi.edu:in-notes/mime/<type>
containing the definitions of its subtypes.
10.3 Internet Engineering Task Force (IETF) working groups
The IETF working group on Privacy-Enhanced Mail (PEM) has developed
extensions that permit confidentiality, authentication, and integrity to
be provided in a manner backwards compatible with RFC-821 and RFC-822
(see 3.4). Work is underway to align PEM and MIME which will provide
real security to MIME email.
The IETF MIME working group is not actively considering significant
changes to the specifications. However the WG still exists as a forum
for MIME developers, as a home for interpretation questions, and to
handle any problems or ambiguities that might arise in MIME.
11 Developers' FAQs
11.1 How can I register a new MIME type?
The procedures for registering new content types, character set
values, access types, and conversions parameters with IANA (the
Internet Assigned Numbers Authority) are documented in RFC 1521.
11.2 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 1425) is open-ended; so far two
extensions have been defined.
Message size declaration (RFC 1427) 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 1426) 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.
11.3 Where can I get some sample MIME messages?
FTP: thumper.bellcore.com:pub/nsb/samples/*
11.4 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 people, over a long time (look at the Acknowledgements section of
RFC 1521). 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.
11.5 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.
11.6 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.
12 Acknowledgements
Many people have contributed to this document.
They include:
Alan Robiette, Alec Henderson, Axel Boldt, Carlyn Lowery, Chris Pepper,
Christophe Wolfhugel, Christopher Davis, Craig Huckabee, Daniel
Fandrich, Daniel Glazman, Dave Curry, Dave Lacey, David Collier-Brown,
David Miller, Ed Anselmo, Edward Vielmetti, Erik van der Poel, Harald
Alvestrand, Ian Hoyle, James Ford, Jason Beyer, Jay Weber, Jerry Sweet,
Joe Ilacqua, Joergen Haegg, John Gardiner Myers, John Martin, John
Romine, Joyce Reynolds, Keith Moore, Larry Salomon Jr, Lars-Gunnar
Olsson, Luc Rooijakkers, Marc VanHeyningen, Mark Crispin, Mark Grand,
Marshall Rose, Martin Wendel, Masanobu Umeda, Michael Parson, Michael
Urban, Nathaniel Borenstein, Ned Freed, Paul Eggert, Quentin Smart, Ran
Atkinson, Ray Langford, Rich Ragan, Rick Troth, Ron Barak, Steve Dorner,
Steve Hole, Stuart Lynne, Susan Straub, Syd Weinstein, Tommy Wallo,
Yehavi Bourvine.
If I've left your name off, please accept my apologies. Drop me a
note and I'll include it for next time.
Thanks also to Jonathan Kamens, for coordinating the *.answers groups,
and for his post_faq program which brought you this FAQ.
End of Part III
--
Tim Goodwin | "Alvestrand's equality: gateways = pain"
PIPEX Ltd | -- Harald T Alvestrand.
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads