comp.mail.mime FAQ (frequently asked questions list)
MIME FAQ maintainer
Content-Type: text/plain; charset=us-ascii
Content-Description: comp.mail.mime FAQ (frequently asked questions list)
Content-Transfer-Encoding: 7bit
Message-Id: <mime_868...@irvine.com>
MIME-Version: 1.0
Archive-Name: mail/mime-faq/part1
Version: $Id: mime1,v 3.23 1997/06/11 23:27:11 jsweet Rel $
Posting-Frequency: monthly
X-Comment: archive-name information provided redundantly
because of rules for coalescing message/partials.
Archive-Name: mail/mime-faq/part1
Version: $Id: mime1,v 3.23 1997/06/11 23:27:11 jsweet Rel $
Posting-Frequency: monthly
==========================================================
comp.mail.mime frequently asked questions list (FAQ) (1/9)
==========================================================
Part 1: Introductions and Basic Information about MIME
--
i) Overview
This is part 1 of a Frequently Asked Questions document about MIME,
the multipurpose and multi-media standard for Internet mail.
There are 9 parts, each posted separately.
--
ii) Contents
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 '+'.
Part 1: Introductions and Basic Information about MIME
i) Overview
ii) Contents
1.1) What is MIME?
1.2) Help! I got a message in MIME format--how do I decode it?
1.3) MIME glossary
1.4) Conventions used in this FAQ document
1.5) Where to find information about MIME
1.6) Where can I get the comp.mail.mime FAQ?
1.7) FAQ Maintainers
1.8) Acknowledgements
1.9) Permissions
Part 2: MIME End-User topics
2.1) What can I use to display MIME messages?
2.2) MIME features that may or may not be present
2.3) Why does MIME define base64 instead of using uuencode?
2.4) How can I use uuencode with MIME?
2.5) Does Microsoft Mail support MIME?
2.6) What do I do with binhex-ed mail?
2.7) Can I do MIME on a (pick one) PC/Macintosh/Envoy/Whatever?
2.8) MIME support in commercial mail services
Part 3: Advanced MIME topics
3.1) So, does MIME introduce any new security problems?
3.2) What about security and privacy issues?
3.2.1) PEM
3.2.2) MOSS
3.2.3) PGP
3.2.4) S/MIME
3.3) What's "text/enriched"?
3.4) What about a group 3 facsimile encoding?
3.5) Should I always use external body parts to save space?
3.6) What mail servers can I reference?
3.7) Can I interwork between MIME and X.400?
3.8) Where else is MIME used?
3.9) How can I register a new MIME type?
3.10) What's ESMTP, and how does it affect MIME?
3.11) Where can I get some sample MIME messages?
3.12) Wouldn't MIME be better if it did <foo>?
3.13) So what about multilevel encodings?
3.14) Why doesn't MIME include a mechanism for compression?
3.15) What's this Content-Disposition header?
3.16) What character sets can be used with MIME?
Part 4: Appendix A(1): Pointers to MIME specifications
! A) Pointers to MIME specifications
! A.1) MIME-relevant RFCs, drafts, and standards
A.2) MIME types
! A.2.1) List of registered MIME types
Part 5: Appendix A(2): Pointers to MIME specifications (continued)
! A.2.1) List of registered MIME types (continued)
! A.2.2) List of known unregistered MIME types
Part 6: Appendix B(1): Freely Available MIME products
B) Freely Available MIME products
B.1) Libraries and Patches
! B.2) Conversion tools and extension packages
Part 7: Appendix B(2): Freely Available MIME products (continued)
B.3) Mail user agents and transport systems
B.4) Packages for MIME in USENET
Part 8: Appendix C(1): Commercial MIME products
C) Commercial MIME products
Part 9: Appendix C(2): Commercial MIME products (continued)
C) Commercial MIME products (continued)
--
1.1) What is MIME?
MIME, the Multi-purpose Internet Mail Extensions, is a freely
available set of specifications that offers a way to interchange text
in languages with different character sets, and multi-media e-mail
among many different computer systems that use Internet mail
standards.
If you were bored with plain text e-mail messages, thanks to MIME you
now can create and read e-mail messages containing these things:
- character sets other than US-ASCII
- enriched text
- images
- sounds
- other messages (reliably encapsulated)
- tar files
- PostScript
- pointers to FTPable files
- other stuff
MIME supports not only several pre-defined types of non-textual
message contents, such as 8-bit 8000Hz-sampled mu-LAW audio, GIF image
files, and PostScript programs, but also permits you to define your
own types of message parts.
Before MIME became widespread, you might have been able to create a
message containing, say, a PostScript document and audio annotations,
but more often then not, the message was encoded in a proprietary,
non-transportable format. That meant that you couldn't easily handle
the same message on another vendor's workstation, or even get it
intact through a mail gateway in the first place. Now, depending on
the completeness of your MIME-capable mail system, there's a good
chance that it'll "just work" (but see section 1.2 for some warnings
on this subject).
One of the best things about MIME is that it's a "four-wheel drive
protocol" (to borrow a description applied originally to PhoneNet by
Einar Stefferud). MIME was carefully designed to survive many of the
most bizarre variations of SMTP, UUCP, and other Procrustean mail
transport protocols that like to slice, dice, and stretch the headers
and bodies of e-mail messages.
Here are a few examples of how MIME is being used in the real world,
now:
1. Dr. Marshall T. Rose mails out his SNMP-related newsletter, "The
Simple Times" as multi-media e-mail messages in several forms:
- in a PostScript form, with beautiful typesetting and a
two-column page layout, suitable for printing on a laser
printer;
- in a "text/html" form (RFC 1866), suitable for
examination via a WWW browser. (Formerly,
text/richtext, another SGML-like markup language,
was used.)
- in an ordinary, plain text, form.
(SNMP is the Simple Network Management Protocol.)
2. IETF document announcements (RFCs, Internet Drafts, etc.) are
structured as multipart MIME messages. The first part contains the
document abstract. The second part is itself a multipart message,
containing external references to the document itself (one via a
mail-server, one via anonymous FTP). Thus, with a suitable UA
(User Agent, see 1.3 for glossary), you can read the abstract,
and then have the complete document retrieved for you (by the
most appropriate method) at the press of a button.
3. A "pointer" to this FAQ is posted weekly in comp.mail.mime. The
pointer article contains MIME external contents that MIME-capable
mail user agents can use to obtain the FAQ via WWW, Internet FTP,
or mail server.
--
1.2) Help! I got a message in MIME format--how do I decode it?
If you receive some content type that your mail user agent can't
already handle automatically, then you'll have to modify your global
or personal mail system configuration to deal with it--if you can.
It's not always possible, short of spending a year of your life to
write the required programs.
Some bits of advice:
- Look in the MIME FAQ (part 1 of which you're reading now) to
see if someone already has a tool or product that will decode the
content type that you're attempting to handle. Appendices B and C
list many MIME-capable products and packages, some commercial,
some free.
- Check the MIME Meta-FAQ. It's posted in comp.mail.mime along
with this FAQ. The meta-FAQ offers general advice for dealing
with various MIME problems. The meta-FAQ also may be found at
this URL:
ftp://ftp.ics.uci.edu/pub/mh/contrib/multimedia/mime-meta-FAQ
- A common decoding question is about "base64". Technically,
base64 is a content transfer encoding, not a MIME type per se.
It looks like line after line of evil stuff like this:
H52QbdC0aJOmTZkXbcKkYUNGzhs4ACJKnEixosWLGDNq3FgRhEcbNG...
To decode it, you need something that'll unpack base64. One
solution, called "munpack", may be found at this URL:
ftp://ftp.andrew.cmu.edu/pub/mpack/
Versions are available for Unix, MS-DOS, Macintosh, and Amiga
platforms. See the Meta-FAQ for some hints and tips about how
to run munpack. Other decoders, some free, some commercial,
are listed in appendices B and C of this FAQ.
* * *
Here your faithful MIME FAQ maintainer feels the need to rant a bit on
the subject of poor MIME usage and concomitant MIME decoding problems.
MIME capability doesn't automatically confer interoperability with the
rest of the world. Any random data can be mapped into MIME one way or
another, but some consideration needs to be given to the target
audiences.
Still, as Einar Stefferud likes to point out, "'Can' implies 'shall.'"
Platform or application-specific MIME data formats inevitably leak out
to the rest of the world, prompting instant FAQs: "Huh? Now how do I
make my mail reader handle _this_? And why was it sent to me?"
For creators of MIME messages, here are some preventive suggestions:
- Know how your attachments are going to be sent. Bear in mind
that what's reasonable for another Macintosh/Windows/Envoy/Whatever
recipient isn't necessarily reasonable for the rest of the world.
For example, sending that Microsoft Word document as an attachment
might not work out as well as you think it should.
If options are available for turning off attachments, do so,
except perhaps for specific correspondents known to have the
ability to view the attachments. This is particularly relevant to
users of mail systems in Microsoft operating environments.
Microsoft TNEF data, for example, which has been seen to be
leaking out to the wider Internet, is not something that most
Internet correspondents can presently handle. In addition to
attachments, TNEF data may include links to OLE objects, fonts,
colors, and other information that doesn't have the same form
or meaning outside a Microsoft operating environment.
- Be somewhat conservative about content types when sending to
mailing lists or other public forums, or consider using
multipart/alternative.
- Watch character set selections and content transfer encodings.
For example, some commonly used character sets on Apple Macintosh
computers use eight bits, not the standard seven bits, and also
contain a few non-standard glyphs.
Here is an example of a typical issue for personal computer
users:
[ Michael P Urban <ur...@cobra.jpl.nasa.gov> 14-Feb-1996 ]
If you want to send non-ASCII text (e.g., if you are a
Macintosh user and you send text containing a bullet), you
should realize that the mail system has NO WAY of knowing
whether the recipient has the same sort of computer you have.
The non-ASCII binary code for a bullet on a Macintosh is
different from the one used on Intel machines, which is
different from LATIN-1 (which has no such character).
--
1.3) MIME glossary
Every subculture needs its list of buzzwords; here's a small
collection for MIME.
body the part of a message after the header (the "meat")
content a portion of a MIME message
CTE content transfer encoding (e.g. base64, quoted-printable, etc.)
ESMTP Extended SMTP - RFC 1869
external part a "pointer" to a part available via FTP or other means
GIF graphical interchange format for images
header the To, From, Subject, etc. at the start of a message
HTML hypertext markup language; used in WWW documents
JPEG an image compression standard for still images
mail transport the "post office", e.g. sendmail, smail, MMDF, etc.
MIME Multipurpose Internet Mail Extensions - RFCs 2045-2049
MPEG an image compression standard for moving pictures
MTA Mail Transport Agent, see "mail transport"
MUA Mail User Agent, see "user agent"
multi-media nebulous marketroid term meaning audio and visual stuff
part a piece of a MIME message containing some data type
PBM an image format
PEM Privacy Enhanced Mail
PGP Pretty Good Privacy
PostScript a popular page description language
RFC request for comments; proposed or standard Internet protocols
SMTP Simple Mail Transfer Protocol - RFC 821
text/enriched simple text markup language for MIME - RFC 1896
text/simplemail another (even simpler?) text markup language
URL WWW uniform resource locator; access-method://host/path
user agent the end user's mail program, e.g. MH, ELM, /bin/mail, etc.
WWW the world-wide web
--
1.4) Conventions used in this FAQ document
- Direct quotations begin with an attribution in a standard format,
and are indented by four spaces.
- Pointers to resources available via the Internet, such as references
to FTPable goodies, appear in WWW URL format. URLs beginning with
"ftp:" refer to FTP sites. For example:
ftp://domain.name/path/to/package
Those with FTP access, but without WWW access, may treat such
references as follows:
1. Log into host domain.name using anonymous FTP
2. Look for /path/to/package
An FTP reference usually lists only the distribution site; please
try your nearest FTP archive first. Archie may be of some help
here.
URLs beginning with "http:" refer to WWW servers. URLs beginning
with "gopher:" refer to gopher servers.
Internet browsing tools, such as Mosaic, know about URLs.
- You'll occasionally see text in braces, like this.
{ Here is some example meta-text. }
Sometimes, this indicates a place where information is missing, or
where the information may be unreliable, or where major changes are
planned in the near future. You can ignore these if you're just
looking for information. But if you can help fill in the gaps, and
you want to achieve fame, fortune, and your name at the bottom of
this FAQ, please send e-mail to the maintainer.
--
1.5) Where to find information about MIME
{ Please feel free to contribute references to books, articles,
web pages, newsgroups, and other sources of information. }
Books:
The Internet Message: closing the book with electronic mail
Marshall T. Rose
Prentice-Hall
ISBN 0-13-092941-7
This book is a complete review of the Internet world of electronic
mail, including recent developments. There is considerable detail,
and it would make the perfect companion to the mail RFCs for any
budding implementor.
On the other hand, the detail should be quite easy to skip for those
interested in just an overview.
As usual, Marshall's informed and often vigorous opinions are clearly
marked off as "soapboxes", to be objectively skipped or delightedly
sought out, according to preference.
One chapter of the book is devoted to MIME.
Articles and Papers:
[ Daniel Glazman <Daniel....@der.edf.fr> 27-Oct-94 ]
(In English):
N.Borenstein, Bellcore, "Multimedia Mail From the Bottom Up or
Teaching Dumb Mailers to Sing", ConneXions, pp. 10-16, Nov.91
G.Vaudreuil, CNRI, "MIME: Multi-Media, Multi-Lingual Extensions for
RFC 822 Based Electronic Mail", ConneXions, pp. 36-39, Sep.92
(In French):
D.Glazman, EDF/DER, "Les Extensions MIME", Tribunix No 57, Oct.94
Information available from the Internet:
- Via FTP:
Information about FTPable stuff is scattered throughout this FAQ.
More specifically, look into the RFCs mentioned in appendix A of
this FAQ.
Other goodies can be found in the MH and MetaMail source trees.
Refer to the appendices of this FAQ for lots of details and URLs
beginning with "ftp:".
Refer to appendix A for information about how to retrieve RFCs via
FTP.
A nice overview of the MIME specification by Mark Grand is available
from this URL:
http://www.mindspring.com/~mgrand/mime.html
- Via Mail-based archive servers:
A few Internet sites whose archives contain MIME-related information
support retrieval via e-mail servers. One of these is ics.uci.edu.
References in URL form to ftp.ics.uci.edu may be used to formulate
retrieval requests to send to the archive-server address at
ics.uci.edu. To find out more about how to use that mail server, send
a message whose body contains the line "help" to the address
"archive...@ics.uci.edu".
RFCs may be requested from a mail-based archive server. Refer to
appendix A for information about how to do that.
Several freely available packages, including ServiceMail and metamail,
contain mail-based archive servers. Some commercial packages do as
well. Refer to appendices B and C of this FAQ for details. Installing
a mail-based archive server at your site makes it possible to send out
messages containing external body contents that can be used to
retrieve materials automatically from your site via e-mail.
[ Arjan van der Meer <arja...@htsa.hva.nl> 30-Jan-1995 ]
Mail for more info: mime-Do...@docserver.cac.washington.edu
It sent me a brief and clear E-mailing about how and what MIME is.
- From USENET newsgroups:
news:comp.mail.mime
This is the USENET newsgroup devoted to discussions of MIME.
Comp.mail.mime articles are archived here:
ftp://ftp.ncd.com/pub/usenet/comp.mail.mime
Articles are stored in three formats: by subject, by article
number, and by month. See the README file for more information.
news:comp.mail.multi-media
This newsgroup contains general discussions of multi-media e-mail,
not necessarily MIME.
- From Internet mailing lists:
info-mime
Info-mime is gatewayed with comp.mail.mime. This is a
bidirectional gateway, so every message to the mailing list also
appears on the newsgroup, and vice versa. If you are unable or
unwilling to read USENET news, here is where to send subscription
requests:
info-mim...@cs.utk.edu
info-mime-uk
This is a UK exploder for info-mime. Here is where to send
subscription requests:
info-mime-...@mailbase.ac.uk
Mailbase software archives all articles sent to the info-mime-uk
mailing list. The articles are accessible via these URLs:
ftp://mailbase.ac.uk
gopher://mailbase.ac.uk
Archived articles are also available via mailserver; send a message
to mail...@mailbase.ac.uk, with a message body containing a
retrieval command, e.g. "send info-mime-uk 08-1993".
ietf-types
RFC 2048 makes mention of a discussion list for proposed MIME type
registration, "ietf-types". The subscription address is this:
In the body of the request message specify this command:
subscribe ietf-types your-address@your_site.your_net
Please see also section 3.9 of this FAQ for some additional notes
about making proposed MIME type registrations available for
review on the ietf-types list.
other lists
There are various mailing lists specific to particular
implementations of MIME. If we know of such a list, it is
mentioned in the section of this document about that
implementation.
- From the world-wide web:
There are many web URLs scattered throughout this document.
Various sources of information about mail systems that support
MIME may also be found at these URLs (list contributed by
Brad Knowles <br...@azathoth.ops.aol.com>):
Internet Mail Consortium
http://www.imc.org/
Brad Knowles's comp.mail.sendmail FAQ
http://www.his.com/~brad/sendmail/
SMTP Resources Directory
http://www.dns.net/smtprd/
SunWorld Online Email Connectivity overview
http://www.sun.com/sunworldonline/swol-08-1995/swol-08-connectivity.html
Matt Wall's E-mail Web Resources
http://andrew2.andrew.cmu.edu/cyrus/email/email.html
Bill Wohler's Email References
http://www.worldtalk.com/html/msg_resources/email_ref.html
--
1.6) Where can I get the comp.mail.mime FAQ?
- It is posted approximately monthly to the newsgroups comp.mail.mime,
comp.answers, and news.answers. The "Expires:" field is set such
that---on systems that honor this field---the most recent edition
shall always be in the news article database.
- Many sites archive news.answers postings, including these:
ftp://ftp.uu.net/usenet/news.answers/mail/mime-faq/
ftp://rtfm.mit.edu/pub/usenet-by-group/news.answers/mail/mime-faq/
If possible, please try to find a closer site; for example, by
asking archie for "mime-faq". Alternatively, use WWW search
engines to look for the MIME FAQ.
- An HTML version of the MIME FAQ is available at this URL:
http://www.cs.ruu.nl/wais/html/na-dir/mail/mime-faq/.html
(Brought to you by the Department of Computer Science,
Utrecht University, The Netherlands.)
If you find a non-working hypertext link in the HTML versions,
you're welcome to bring it to the attention of the MIME FAQ
maintainer, but unless it's a problem with a URL reference in the
original document, the MIME FAQ maintainer probably can't fix it
directly.
- If you are reading this FAQ via some fixed medium such as hardcopy
or CD-ROM, please try to obtain the latest edition from the net
instead.
There is also a Part 0, the "Meta-FAQ", posted monthly, that attempts
to help with any special problems that you may have with reading MIME
messages such as the MIME FAQ postings. A pointer to the Meta-FAQ
is posted weekly. The Meta-FAQ is usually available with the MIME FAQ;
look for "comp.mail.mime meta-FAQ: Help for MIME problems". The
meta-FAQ's filename is typically "mime0".
--
1.7) FAQ Maintainers
Current maintainer:
Jerry Sweet <mime...@ics.uci.edu>
Please note:
Questions about mail systems, how to decode MIME parts on your
computer, and other such issues, if not already answered in the
FAQ, should be posted to comp.mail.mime or to the info-mime mailing
list.
Correspondence sent to the MIME FAQ maintainer primarily should
address information in the MIME FAQ---corrections, additions, or
suggestions for improvement. You must put the word "maint:"
at the beginning of your subject, or you'll get an automated
response.
Previous maintainers (thanks, guys!):
Ed Vielmetti - originator
Tim Goodwin
Contributions have come from a cast of dozens; see below for the
list of contributors.
--
1.8) Acknowledgements
In addition to those named elsewhere in this document, contributors to
this document have included these persons:
Niklas Agren
Harald Alvestrand
Ed Anselmo
Ran Atkinson
Ron Barak
David Barr
Jason Beyer
Axel Boldt
Nathaniel Borenstein
Yehavi Bourvine
Douglas Boyce
David Collier-Brown
Mark Crispin
Dave Curry
Roman Czyborra
Christopher Davis
Steve Dorner
David Eaves
Paul Eggert
Daniel Fandrich
Pat Farrell
James Ford
Ned Freed
John Gardiner Myers
Daniel Glazman
Tim Goodwin
Mark Grand
Ed Greshko
Joergen Haegg
Gisle Hannemyr
Alec Henderson
Steve Hole
Ian Hoyle
Craig Huckabee
Joe Ilacqua
Olle Jarnefors
Tim Kehres
Brad Knowles
Dave Lacey
Ray Langford
Carlyn Lowery
Stuart Lynne
John Martin
David Miller
Keith Moore
Lars-Gunnar Olsson
Michael Parson
Jerry Peek
Chris Pepper
John R MacMillan
Rich Ragan
Joyce Reynolds
Alan Robiette
John Romine
Luc Rooijakkers
Marshall Rose
Remco Rutten
Larry Salomon Jr
Rahmat M. Samik-Ibrahim
Piero Serini
Michael Shields
Quentin Smart
Susan Straub
Jerry Sweet
Rick Troth
Masanobu Umeda
Michael Urban
Erik van der Poel
Marc VanHeyningen
Edward Vielmetti
Larry W. Virden
Tommy Wallo
Jay Weber
Syd Weinstein
Martin Wendel
Alan Wehmann
Sascha Wildner
Christophe Wolfhugel
If we've left your name off please accept our apologies. Drop us a
note and we'll include it for next time.
The following institutions and individuals have provided resources for
maintaining the MIME FAQ:
- The University of California, Irvine; Department of Information and
Computer Science (http://www.ics.uci.edu)
- Einar Stefferud <st...@nma.com>
- Irvine Compiler Corp (http://www.irvine.com)
Thanks also go to Jonathan Kamens, for coordinating the *.answers
groups, and for his post_faq program which brought you this FAQ.
--
1.9) Permissions
Permission is granted for non-profit redistribution of the unedited
comp.mail.mime FAQ.
For-profit redistribution of the unedited comp.mail.mime FAQ is
presently permitted, but the maintainers request that you notify them.
(For this purpose, commercial USENET newsfeeds, bboards, and other
electronic or physical media distributions that incidentally include
this FAQ as part of a full re-distribution of the newsgroups in which
the FAQ appears, needn't notify us.)
--
End of Part 1
*************
--
MIME FAQ maintainer
Archive-Name: mail/mime-faq/part5
Version: $Id: mime5,v 3.23 1997/06/11 23:27:11 jsweet Rel $
Posting-Frequency: monthly
--
==========================================================
comp.mail.mime frequently asked questions list (FAQ) (5/9)
==========================================================
Part 5: Appendix A(2): Pointers to MIME specifications
~~~~~~
--
Overview
--------
This is part 5 of a Frequently Asked Questions document about MIME,
the multipurpose and multi-media standard for Internet mail.
The table of contents is in part 1.
--
A.2.1) List of registered MIME types (continued)
{ Again, please feel free to let us know about especially useful or
definitive URLs for any particular type. Examples: specifications,
tutorials, or freely available software for decoding or displaying. }
Audio types
-----------
There is one audio type pre-defined in RFC 2046:
type: audio/basic
see: RFC 2046
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/audio/basic
Other audio types:
type: audio/32kadpcm
see: RFC 1911
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/audio/32kadpcm
[ Keith Moore <mo...@cs.utk.edu> 9-Oct-96 ]
Audio/32kadpcm uses g.721; which (I believe) sox can decode. Do
an archie regexp search for 'sox.*tar'.
"Vnd" (vendor-defined) types:
audio/vnd.qcelp
Image types
-----------
There is one image type pre-defined in RFC 2046:
type: image/jpeg
see: RFC 2046
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/jpeg
Other image types:
type: image/cgm
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/cgm
type: image/g3fax
see: RFC 1494
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/g3fax
type: image/gif
see: RFC 1521 (obs.)
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/gif
comment: Deleted from the primary MIME specs in RFC 2046 because of
patent issues.
type: image/ief
see: RFC 1314
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/ief
type: image/naplps
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/naplps
type: image/png
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/png
type: image/tiff
see: RFC 1314
see: RFC 1528
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/tiff
"Vnd" (vendor-defined) image types:
(see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/)
image/vnd.dwg
image/vnd.dxf
image/vnd.fpx
image/vnd.net-fpx
image/vnd.svf
Message types
-------------
There are three message types pre-defined in RFC 2046:
type: message/external-body
see: RFC 2046
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/message/external-body
type: message/partial
see: RFC 2046
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/message/partial
type: message/rfc822
see: RFC 2046
see: RFC 822
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/message/rfc822
Other message types:
type: message/http
see: RFC 2068
type: message/news
see: RFC 1036
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/message/news
comment: RFC 1036 does not discuss MIME encapsulation of USENET articles,
since it predates MIME by about six years.
Model types
-----------
The model top-level type is defined in RFC 2077; it is not pre-defined
in the MIME RFCs.
type: model/iges
see: RFC 2077
see: http://speckle.ncsl.nist.gov/~jacki/igests.htm
type: model/vrml
see: RFC 2077
see: http://vrml.wired.com/arch/
type: model/mesh
see: RFC 2077
see: http://www-dsed.llnl.gov/documents/tests/mesh.html
Multipart types
---------------
There are four multipart types pre-defined in RFC 2046:
type: multipart/alternative
see: RFC 2046
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/alternative
type: multipart/digest
see: RFC 2046
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/digest
type: multipart/mixed
see: RFC 2046
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/mixed
type: multipart/parallel
see: RFC 2046
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/parallel
Other multipart types:
type: multipart/appledouble
see: RFC 1740
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/appledouble
type: multipart/byteranges
see: RFC 2068
type: multipart/encrypted
see: RFC 1847
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/encrypted
type: multipart/form-data
see: RFC 1867
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/form-data
type: multipart/header-set
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/header-set
type: multipart/related
see: RFC 2112
type: multipart/report
see: RFC 1892
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/report
type: multipart/signed
see: RFC 1847
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/signed
type: multipart/voice-message
see: RFC 1911
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/voice-message
Text types
----------
There is one text type pre-defined in RFC 2046:
type: text/plain
see: RFC 2046
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/plain
Other text types:
type: text/enriched
see: RFC 1896
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/enriched
type: text/html
see: RFC 1866
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/html
type: text/richtext
see: RFC 1341 (obs.)
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/richtext
comments: obsolete - see text/enriched instead
type: text/sgml
see: RFC 1874
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/sgml
type: text/tab-separated-values
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/tab-separated-values
"Vnd" (vendor-defined) text types:
(see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/)
text/vnd.latex-z
text/vnd.fmi.flexstor
Video types
-----------
There is one video type pre-defined in RFC 2046:
type: video/mpeg
see: RFC 2046
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/video/mpeg
For "vnd" (vendor-defined) video types, refer also to this URL:
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/video/
Some vendor-defined application types have been grandfathered into
the top-level, but this doesn't preclude later registration into the
"vnd" subtree.
Here is a list of vendor-defined video types:
video/quicktime
video/vnd.motorola.video
video/vnd.motorola.videop
video/vnd.vivo
Character sets
--------------
Character sets pre-defined in RFC 2046 for use with MIME are
US-ASCII and ISO-8859-X, where X is in the range 1..10.
See RFC 1700 for the latest list of character sets registered
for use with MIME.
Access types for external contents
----------------------------------
See this URL for a list of registered access-types:
ftp://ftp.isi.edu/in-notes/iana/assignments/access-types
(It's supposed to be a directory, but presently it's just one file.)
Also see RFC 1700.
The access types pre-defined in RFC 2046 are as follows:
what: access-type=ANON-FTP
for: anonymous FTP
see: RFC 1635
see: RFC 959
what: access-type=content-id
for: experimental content-id access-type
see: RFC 1873
what: access-type=FTP
for: non-anonymous FTP
see: RFC 959
what: access-type=LOCAL-FILE
for: directly retrievable file
see: RFC 2046
what: access-type=MAIL-SERVER
for: request to a mail-based archive server
see: RFC 2046
what: access-type=TFTP
for: trivial file transfer protocol
see: RFC 1350
comment: RFC 2046 cites RFC 783 (obs.) for TFTP rather than RFC 1350.
There is one access type that is no longer pre-defined in the MIME
RFCs:
what: access-type=AFS
for: CMU Andrew File System
see: http://www.transarc.com/afs/transarc.com/public/www/Product/AFS/FAQ/faq.html
comment: Deleted from the primary MIME specs in RFC 2046.
Content transfer encodings
--------------------------
See this URL for a list of registered content transfer encodings
(CTEs):
ftp://ftp.isi.edu/in-notes/iana/assignments/transfer-encodings
(It's supposed to be a directory, but presently it's just one file.)
The content transfer encodings (CTEs) pre-defined in RFC 2045 for use
with MIME are as follows:
cte: 7bit
see: RFC 2045
cte: 8bit
see: RFC 2045
cte: base64
see: RFC 2045
cte: binary
see: RFC 2045
cte: quoted-printable
see: RFC 2045
--
A.2.2) List of known unregistered MIME types
Here is a list of some known x-types, x-subtypes, and x-parameters.
The enumeration of these x-types here does not imply any kind of
standardization or open specification. The meanings of x-types depend
on private agreements between senders and receivers. Some x-types may
eventually become registered types; see sections A.2.1 and 3.9.1.
Just because an x-type is generated by a proprietary mail user agent
doesn't necessarily mean that only that MUA can handle the x-type.
Metamail and MH, for example, permit you to set up your own mechanisms
to handle various standard and non-standard content types. In
particular, it may simply be a matter of invoking some commercial
application (aka invoking an "external viewer") to view data used by
that application.
The Metamail source distribution comes with pre-defined mailcap
entries for handling some x-types; these may offer clues about how to
configure your own mail user agent.
Not all of the x-types listed here begin with "x-". Although x-types
without the "x-" prefix may contravene the MIME specification, the
fact remains that someone out there is generating them. Listing such
types here is not intended to enshrine such types.
{ NOTE: some of the meanings of these x-types are GUESSES by the FAQ
maintainer. Please let us know about incorrect guesses, and, if
possible, supply a URL pointing to information about the x-type.
And please feel free to let us know about whatever wacko or not-so-wacko
x-types that your UAs may unleash on an unsuspecting world. If you
have a URL for a document that describes the format, so much the
better. Please at least let us know what applications are generating
the x-types in question. }
Application types
type: application/green-commerce
for: commercial transactions
see: http://www.fv.com/pubdocs/agc-spec.txt
type: application/ms-tnef
from: Microsoft
see: application/vnd.ms-tnef
type: application/pgp
from: PGP
for: Pretty Good Privacy
see: RFC 2015
see: section 3.2 of the MIME FAQ
type: application/safe-tcl
for: enabled-mail
comment: see multipart/enabled-mail, below
type: application/x-aiff
from: Z-Mail
for: AIFF audio data
type: application/x-bcpio
from: MHonArc
for: bcpio data
type: application/x-bitmap
from: Z-Mail
for: X11 bitmaps
type: application/x-cpio
from: MHonArc
for: cpio archives
type: application/x-csh
from: MHonArc
for: csh scripts
type: application/x-dvi
from: MHonArc
for: TeX DVI data
type: application/x-framemaker
from: Z-Mail
for: FrameMaker documents
type: application/x-gtar
from: MHonArc
for: GNU tar archives
type: application/x-hdf
from: MHonArc
for: hdf data
type: application/x-inventor
from: Z-Mail
for: Inventor files
type: application/x-island-draw
from: Z-Mail
for: IslandDraw files
type: application/x-island-paint
from: Z-Mail
for: IslandPaint files
type: application/x-island-write
from: Z-Mail
for: IslandWrite files
type: application/x-jot
from: Z-Mail
for: Jot documents
type: application/x-latex
from: MHonArc
for: LaTeX documents
type: application/x-lotus-notes
from: Lotus Notes
comment: may use unregistered cte "uue" (uuencode)
type: application/x-macbinhex40
from: TCP/Connect II
for: Mac BinHex 4.0
comment: see application/macbinhex40
type: application/x-metamail-patch
from: metamail
for: patches to metamail
type: application/x-mif
from: MHonArc
for: Frame MIF documents
type: application/x-movie
from: Z-Mail
for: MoviePlayer documents
type: application/x-ms-tnef
from: Worldtalk
for: proprietary "tunneling" type for MS Exchange
type: application/x-netcdf
from: MHonArc
for: netcdf data
type: application/x-patch
from: { unknown }
for: miscellaneous source code patches
see: patch(1)
type: application/x-sgi
from: Z-Mail
for: SGI ImageWorks documents
type: application/x-sh
from: MHonArc
for: sh scripts
comments: obvious security problem
type: application/x-shar
from: MHonArc
for: shell archives
comments: obvious security problem
type: application/x-showcase
from: Z-Mail
for: Showcase documents
type: application/x-sv4cpio
from: MHonArc
for: SVR4 cpio archives
type: application/x-sv4crc
from: MHonArc
for: SVR4 crc data
type: application/x-tar
from: MHonArc
for: tar archives
type: application/x-tcl
from: MHonArc
for: tcl programs
comments: obvious security problem
type: application/x-tex
from: MHonArc
for: TeX documents
type: application/x-texinfo
from: MHonArc
for: GNU texinfo documents
type: application/x-troff
from: MHonArc
for: plain troff documents
type: application/x-troff-man
from: MHonArc
for: troff -man documents
type: application/x-troff-me
from: MHonArc
for: troff -me documents
type: application/x-troff-ms
from: MHonArc
for: troff -ms documents
type: application/x-ustar
from: MHonArc
for: ustar data
type: application/x-wais-source
from: MHonArc
for: WAIS sources
type: application/x-wingz
from: Z-Mail
for: Wingz documents
type: application/x-xpm1
from: Z-Mail
for: OL pixmap files
type: application/x-wt-stf
from: Worldtalk
for: proprietary "tunneling" type for Worldtalk gateways
[ Hal German <hh...@gte.com> 24-Jan-1997 ]
This is a Worldtalk proprietary type that is used strictly for
communications between Worldtalk gateways (x.400 over SMTP).
It is highly unlikely to ever be a vnd type.
[ Bill Wohler <woh...@uluru.worldtalk.com> 24-Jan-1997 ]
The x-wt-stf type is intended to tunnel the Worldtalk internal
message format in a MIME body part. This type should, however,
never be emitted on the Internet as there really isn't any reason
to do so--we simply convert the message to MIME and send that.
type: application/x-zm-fax
from: Z-Mail
for: Z-Fax documents
Audio types
type: audio/x-aiff
from: MHonArc
for: AIFF audio data
type: audio/x-wav
from: MHonArc
for: WAV audio data
type: audio/x-macaudio
from: Iride
for: NOT sampled Macintosh audio
type: audio/x-next
from: MH 6.8
for: self-describing SunOS/NeXT audio data
see: ftp://ftp.ics.uci.edu/pub/mh/contrib/multimedia/mhn-tutorial.ps
comment: suggested by MH 6.8 docs
Image types
type: image/x-cmu-raster
from: MHonArc
for: CMU raster data
type: image/x-fits
for: FITS files
type: image/x-macpict
from: TCP/Connect II
from: Iride
for: Macintosh PICT
type: image/x-pbm
from: MHonArc
for: portable bit map data
type: image/x-pgm
from: MHonArc
for: PGM data
type: image/x-pict
from: MHonArc
for: Macintosh PICT data
type: image/x-pnm
from: MHonArc
type: image/x-portable-anymap
from: MHonArc
type: image/x-portable-bitmap
from: MHonArc
type: image/x-portable-graymap
from: MHonArc
type: image/x-portable-pixmap
from: MHonArc
type: image/x-ppm
from: MHonArc
type: image/x-rgb
from: MHonArc
type: image/x-xbitmap
from: MHonArc
for: in-lines into the HTML
type: image/x-xbm
from: MHonArc
for: in-lines into the HTML
type: image/x-xpixmap
from: MHonArc
type: image/x-xpm
from: MHonArc
type: image/x-xwd
from: MHonArc
type: image/x-xwindowdump
from: MHonArc
for: X window dump
Multipart types
type: multipart/enabled-mail
see: appendix B.1 of the MIME FAQ - "Safe-TCL (Enabled Mail)"
see: ftp://ftp.bellcore.com/pub/nsb/st/em-model.txt
see: ftp://ftp.bellcore.com/pub/nsb/st/safe-tcl.txt
see: ftp://ftp.fv.com/pub/nsb/safe-tcl-ulpaa-94.txt.gz
see: ftp://ftp.fv.com/pub/code/other/safe-tcl.tar.gz
see: http://www.sunlabs.com/research/tcl/
type: multipart/encrypted
see: RFC 1847
type: multipart/signed
see: RFC 1847
Text types
type: text/unknown
from: Worldtalk
type: text/x-html
from: MHonArc
comment: see type text/html
type: text/x-setext
from: MHonArc
for: setext
type: text/x-usenet-faq
for: Ohio State WWW FAQ documents
Video types
type: video/x-msvideo
from: MHonArc: Microsoft video data
type: video/x-qtc
from: Apple Computer
for: QuickTime TV conference calls
type: video/x-qtv
from: Apple Computer
for: QuickTime TV video/audio broadcasts
type: video/x-sgi-movie
from: MHonArc: SGI movie data
Other top-level types (all without subtypes, so not MIME-conformant):
type: x-be2
from: Andrew
comment: old
type: x-sun-attachment
from: Sun MicroSystems mailtool
type: x-zm-multipart
from: Z-Mail
comment: old
Content transfer encodings
cte: uue
for: uuencoded data
cte: uuencode
for: uuencoded data
cte: x-uue
for: uuencoded data
cte: x-uuencode
for: uuencoded data
Miscellaneous x-parameters
what: charset=x-unknown
in: text/plain
from: MH 6.8.3
for: message parts containing unidentified characters
what: charset=x-roman8
in: text/plain
from: mailx for HP-UX 10.x (possibly other mailx versions as well)
for: default character set
what: x-conversions=compress
in: application/octet-stream; type=tar
from: MH 6.8 "viamail"
see: tar(1)
see: compress(1)
--
End of Part 5
*************
--
MIME FAQ maintainer
Archive-Name: mail/mime-faq/part3
Version: $Id: mime3,v 3.23 1997/06/11 23:27:11 jsweet Rel $
Posting-Frequency: monthly
--
==========================================================
comp.mail.mime frequently asked questions list (FAQ) (3/9)
==========================================================
Part 3: Advanced MIME topics
~~~~~~
--
Overview
--------
This is part 3 of a Frequently Asked Questions document about MIME, the
multipurpose and multi-media standard for Internet mail.
The table of contents is in part 1.
--
3) Advanced MIME topics
--
3.1) So, does MIME introduce any new security problems?
Yes. MIME user agents can do previously unheard of things with mail
messages, notably giving them as input to other programs.
PostScript is probably the biggest potential security hole. One
famous example is the "melting screen" PostScript program, which
destroys screens maintained by Display PostScript implementations. For
another example, PostScript can be used to change the password on some
PostScript printers with previously undefined passwords, which denies
the use of the printer until the printer's password can (somehow) be
changed back. Yet other Display PostScript implementations may allow
file operations. (NeXTstep wisely disables file operations. With
GhostScript, they can be disabled by the "-dSAFER" command line option.
Use of this option (in mailcap, etc.) is highly recommended.)
The enumeration of these security holes is not to be interpreted as
encouragement to exploit the holes. They are mentioned only because
they are well known. Refer to books such as "Practical UNIX Security"
and to news groups such as comp.security.misc for general information
about system security.
--
3.2) What about security and privacy issues?
Both users and administrators should be aware that ordinary Internet
and UUCP e-mail is not secure. No authentication, confidentiality, or
data integrity properties are provided in SMTP, RFC 822, or MIME.
Persons desiring any or all of those security properties in their
e-mail should look into the use of Privacy-Enhanced Mail (PEM). Other
forms of e-mail security, such as PGP (Pretty Good Privacy), are also
available.
[ Raph Levien <ra...@kiwi.cs.berkeley.edu> 19-Feb-1996 ]
I just wrote a survey of five proposals for email encryption: MOSS,
MSP, PGP, PGP/MIME, and S/MIME (in alphabetical order). It's
available on the Web at:
http://www.c2.org/~raph/comparison.html
3.2.1) PEM
At least one no-cost implementation of PEM is available in the US and
Canada. There are also a number of implementations being developed in
Europe (hopefully these shall not suffer the same restrictions on
export).
See also the following RFCs:
RFC 1421 through RFC 1424 - PEM
RFC 1847 - Security Multiparts for MIME
RFC 1848 - MIME Object Security Services
3.2.2) MOSS
[ James M Galvin <tismoss...@tis.com> 13-Sep-1995 ]
MOSS is a Privacy Enhanced Mail (PEM) derivative that is a
proposed internet standard for adding security services to MIME.
MOSS uses the cryptographic techniques of digital signature and
encryption to provide origin authentication, integrity, and
confidentiality to MIME objects.
TIS/MOSS is a reference implementation of MIME Object Security
Services (MOSS) [RFC 1848]...a security toolkit that provides
digital signature and encryption services for MIME objects.
3.2.3) PGP
A system providing similar functionality to PEM implementations is PGP.
PGP is an implementation, not a specification, and it does not carry
the blessing of the IETF, or any other body. It is, however,
available at no cost throughout the world (although its status with
respect to certain US patents is dubious). Caveat emptor.
[ "Jeffrey I. Schiller" <j...@mit.edu> 24-Jun-1994 ]
There is now a freeware version of PGP that is not dubious from a
patent standpoint.
Bi...@yrkpa.kias.com notes the existence of the PGP FAQ from
alt.security.pgp. In addition to enumerating various implementations,
the PGP FAQ document indicates that information about how to obtain
the officially blessed version of PGP is available from:
http://web.mit.edu/network/pgp-form.html
There is also an O'Reilly book out on the subject of PGP. It
contains, among other useful information, an unflinching report
on how PGP came to be.
[ Michael Elkins <elk...@aero.org> 18-Dec-1995 ]
If you are interested in joining the discussion of issues on a
standard for use of PGP to encrypt/sign Internet e-mail messages using
MIME, you may be interested in this list. I highly encourage everyone
who is working on incorporating PGP into a mail client to join, even
if you don't participate in the discussion, since it will be the best
source of information about the developing proposed standard.
To join the list, send mail to
pgp-mime...@lists.uchicago.edu
with a subject of "subscribe".
Submissions should be sent to
pgp-...@lists.uchicago.edu
[ Raph Levien <ra...@kiwi.cs.berkeley.edu> 16-Dec-1995 ]
I've got a collection of information about this proposed standard on
my PGP/MIME Web page:
http://www.c2.org/~raph/pgpmime.html
[ Ned Freed <Ned....@innosoft.com> 19-Jul-1996 ]
A document describing how to combine RFC 1847 and PGP was recently
accepted as a proposed standard. [ See RFC 2015. ]
The old "let's do this via an encoding" theme has been discussed
ad nauseum in at least two other forums (pem-dev and pgp-mime),
and the conclusion is and has always been that encryption via encoding
is a total nonstarter.
3.2.4) S/MIME
[ Ned Freed <Ned....@innosoft.com> 18-Oct-96 ]
S/MIME was only recently published as an Internet Draft. If the
handling of security-related matters in the IETF runs true to previous
form for S/MIME, we're at least a year away from it becoming a
standards-track RFC, and probably a whole lot longer.
[ Kee Hinckley <naz...@utopia.com> 18-Oct-96 ]
It is, however, pretty clear from anyone who has read Netscape's
releases, or been to Internet Expo, that standard or not, people will
be using it (and claiming it as a standard) in less than six months.
The good news is that several of the companies I spoke to were talking
to each other to guarantee interoperability.
--
3.3) What's "text/enriched"?
The text/enriched type offers simple text markup, without making the
text unreadable to someone without the software to interpret it.
The text/enriched scheme uses markup commands enclosed in angle
brackets. For example, here is how you would <bold>embolden</bold> a
single word.
The text/enriched type is defined in RFC 1896. It supersedes
text/richtext, which was defined in RFC 1341 (obs.). See part 3 of
this FAQ for information about how to obtain RFCs.
A freely available implementation of a viewer for text/enriched is
part of the metamail 2.7 "richtext" program, via the undocumented
command line option "-e". See appendix B of this FAQ for details
about metamail.
Other markup language proposals have been made. One is simplemail,
which is more like a standardization of certain existing practices in
mail and news articles. For example, here is how you would *emphasize*
a single word.
Simplemail is explained in an Internet Draft by Bill Janssen and Evan
Kirshenbaum. See part 3 of this FAQ for information about how to
obtain Internet Drafts.
--
3.4) What about a group 3 facsimile encoding?
There is an X.400-conformant G3 facsimile type for MIME, "image/g3fax".
The specifications are in the MIME-MHS documents.
{ What current commercial and non-commercial software packages implement
viewers or generators for the image/g3fax content type per se, as opposed
to fax image rendering for other MIME content types? And which of these
interoperate with the remote printing experimental domain "TPC.INT"? }
The early MIME specification did not include a G3 facsimile type, but
there were some efforts along these lines anyway:
[ Stuart Lynne <s...@wimsey.com> 30-Dec-1992 ]
I have prototype scripts operating with metamail to do some of this.
Some of it is in contrib directory.
Currently I have 2 scripts:
mm2fax - convert mail and metamail messages to TIFF/F (uses various
tools to convert different body parts to TIFF/F);
faxmm - send rfc822 and mime e-mail messages via facsimile (uses
mm2fax to convert to TIFF/F).
[ Ned Freed <n...@innosoft.com> 31-Dec-1992 ]
PMDF-FAX is a set of channel programs for PMDF that provide
facilities for converting text, PostScript, and various other
formats into Group 3 FAX, as well as a set of programs that take
these Group 3 FAX files and use them to drive a variety of FAX
modems. MIME is used throughout to provide type information,
multipart facilities, and so forth. PMDF-FAX was developed with MIME
in mind from the outset.
See also: news:comp.mail.misc - "FAQ: How can I send a fax from the Internet?"
--
3.5) Should I always use external body parts to save space?
Not necessarily. In many cases, for example, at the ends of UUCP
connections, your recipients may not be able to retrieve external body
parts easily. It depends on your audience. Making files available via
a mail server is to be encouraged. It is always possible to provide
MIME alternative parts that first offer FTP, then mail server options.
--
3.6) What mail servers can I reference?
There are various mail servers available. Check news.answers for
the FAQ about mail server software. We do not presently have a
recommendation.
--
3.7) Can I interwork between MIME and X.400?
Conversion between RFC 822 and X.400 is defined in RFC 1327 and
RFC 1495.
Recently, the MIME-MHS working group has published RFCs (which are on
the IAB standards track) that extend RFC 1327 to define conversions
between MIME and X.400.
Some MTAs, notably the ISODE Consortium's version of PP (see appendix B)
have MIME gatewaying support.
--
3.8) Where else is MIME used?
Gopher
[ Randall Atkinson <atki...@tengwar.itd.nrl.navy.mil> 2-Jan-1993 ]
There is experimental work underway in the Internet Gopher community
to include MIME as a mechanism for marking the content of files.
The freely distributable Gopher client for NeXTstep 3.0 includes
MIME support. Other gopher clients will probably add it eventually.
World Wide Web
[ Marc VanHeyningen <mvan...@cs.indiana.edu> 26-Jun-1993 ]
There is more-than-experimental work underway in the Internet World
Wide Web (WWW) community to use MIME as the mechanism for marking
the contents of information exchanged via HyperText Transfer
Protocol (HTTP); the specification of HTTP/1.0 dictates that both
the request and the response are more or less MIME-compliant
messages. There are implementations already doing this today.
Support is also included for format negotiation (e.g. a server
might have both a PostScript and a plaintext version of a paper
and decide which to send based on what the client can accept,
presentation preferences, size, and the like.) It's nearly as
complicated as the "badness" mechanisms in TeX, and unrelated to
(and, for its application, probably superior to) the
multipart/alternative MIME type.
There is an FAQ for WWW in comp.infosystems.www
--
3.9) How can I register a new MIME type?
The procedures for registering new content types, character set
values, access types, and conversion parameters with IANA (the
Internet Assigned Numbers Authority) are documented in RFC 2048.
You might also find it useful to review Harald T. Alvestrand's
notes:
[ "Harald T. Alvestrand" <Harald.T....@uninett.no> 27-Oct-94 ]
I put up a few words on how I understand the current MIME body
part registration procedures on
http://domen.uninett.no/~hta/ietf/media-types.html
The Web version includes hyperlinks to the relevant IANA archives
and RFCs.
RFC 2048 makes mention of a discussion list, "ietf-types", to which
proposed MIME type registrations are to be submitted for review. The
current subscription request address for the ietf-types list is this:
In the body of the request message specify this command:
subscribe ietf-types your-address@your_site.your_net
A pointer to the ietf-types list's message archive may be found in
Harald T. Alvestrand's aforementioned web page on MIME body part
registration procedures.
Two deadly mistakes are made over and over again in proposed MIME type
registrations sent to the ietf-types list: incorrect name designation
and lack of attention to security considerations.
Here are some tips to avoid making those same mistakes (mostly thanks
to Keith Moore and Ned Freed):
* Name your type properly.
- You may not register an "x-" type name.
- You may not register a new type at the top level--for example a
type named "application/toe-fungus"--unless the type has gone
through the IESG approval process, a process that may include
publishing supporting material in an RFC.
Unless you want to go through all that, use instead the "vnd" or
"prs" name spaces. For example, the previous example instead
might be named "application/vnd.fooco.toe-fungus", which uses a
fictitiously IANA-approved producer name "fooco".
* Do _not_ say "none" in the security considerations section.
- Are you really willing to testify in public that there are no
security risks associated with using your proposed MIME type,
or with using products that may act on that type?
Consider that there are significant security risks with using
most data formats, including "plain text", Microsoft Word,
PostScript, Java, and anything that can contain activeX controls.
The list keeps growing.
If you haven't examined the security issues for your proposed
type, then say that you have not. If you know that your type
should be used only in trusted environments, then say that.
- You should document the risks that you _have_ considered. If
you've uncovered any threats, describe those threats and document
any known countermeasures for those threats. For example, when
the data are acted upon by or fed to some program on the
recipient's system, can such action cause permanent side-effects
on that system? Can it expose the user's data or actions to the
outside world? Is there any automatic action associated with the
data, such as receipt notification, that might take place without
warning the recipient? Many would consider this a breach of
security.
- If your type contains other media types, do the encapsulated
media types have their own security considerations? Does the
encapsulation format itself add risks? Can the encapsulation
format thwart firewalls or filters?
--
3.10) What's ESMTP, and how does it affect MIME?
ESMTP (Extended Simple Mail Transfer Protocol) is a mechanism by which
extensions to "traditional" (RFC 821) SMTP can be negotiated by client
and server. The mechanism (RFC 1869) is open-ended; so far two
extensions have been defined.
Message size declaration (RFC 1870) offers a graceful way for servers
to limit the size of message they are prepared to accept. (With SMTP,
the only possibility is for the server to discard the message after it
has been sent in its entirety. There is no way for the client to know
that it was the size of the message that caused the problem.)
When a message is returned to the user as being too large to deliver,
one possible approach might be to fragment the message using the MIME
Message/Partial mechanism, and resubmit it.
Depending on the exact reason for the "too large" rejection, this may
or may not be a good idea. For example, the limitation may reflect
the recipient's disk quota, in which case the fragmented message will
not be fully deliverable either.
The possibility of fragmentation should, therefore, be left to the
user's discretion (not performed automatically by the SMTP client).
8bit-MIMEtransport (RFC 1652) opens up the possibility of sending 8bit
data in mail messages, without having to use base64, quoted-printable,
or another encoding, and without the breakage that can result from
sending 8bit data to an unsuspecting RFC 821 SMTP server. RFC 1428
(Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME)
discusses some of the implications of this.
The "just send 8 bits" (via plain, un-extended SMTP) philosophy still
has its adherents. Here are some heavily edited excerpts from an
argument on the subject:
[ Rahul Dhesi <dh...@rahul.net> 16-Sep-1996 ]
Human readers tend to be quite smart about figuring out what to do
with incoming email. Just send them 8 bits, and let them decide what
to do with it. If they don't like it they will delete it or complain
to the sender's postmaster etc.
[ Mark Crispin <m...@CAC.Washington.EDU> 16-Sep-1996 ]
In order to understand why "just send 8-bits" raises such hackles,
it is necessary to look beyond strictly technical issues. It is
trivial with most of today's machines (and even with the old
36-bit machines!) to send and receive undamaged 8-bit email. The
issues are of a wider scope than merely technical issues.
1) Legacy software. This software was compliant with published
standards when it was written. Historically, the Internet
community has avoided declaring standards-compliant legacy
software to be "broken", as opposed to merely "lacking recent
extensions".
2) Data integity and reliability. High-order bit zeroing and
software crashing when characters > 0x7f are encountered (both
have been reported) in *Full Standard compliant* software are
real issues.
3) Lessons of the past. "Just use ISO-646" didn't work because it
did not scale to multi-national email. The proponents of "just
send 8-bits" will have us believe that "zones" that share a
single 8-bit coded character set are large enough that the same
scaling problems won't occur, or that they aren't important
enough to worry about. In effect, they claim that
interoperability problems between France and Germany are
important, but interoperability problems between Germany and
the Czech Republic aren't.
4) Politics. Whether or not it is stated as such, "just send
8-bits" is perceived in certain areas of the world as a
declaration that the "Internet Standard Character Set" is being
changed from US-ASCII to ISO-8859-1. There are *vehement*
objections to this. Some folks even base their objections to
Unicode on the (incorrect) perception that Unicode declares
ISO-8859-1 as a "base level" and thus gives a perceived unfair
advantage to Western Europe.
ESMTP provides a mechanism for cooperating software to interchange
8-bit. Why, if "just send 8-bits and fix all the old systems" is
a viable option, is there such a problem with the option of
"deploy ESMTP and send 8-bits". The answer is that it is much
harder to deploy ESMTP than it is to pretend that "just send
8-bits" is deployed everywhere.
--
3.11) Where can I get some sample MIME messages?
Here are two sources:
ftp://ftp.bellcore.com/pub/nsb/samples/
http://www-dsed.llnl.gov/documents/tests/email.html
Here're more sources:
[ Patrik Faltstrom <p...@bunyip.com> 13-Dec-1994 ]
At 12:55 AM 12/11/94, Richard Willis wrote:
>Could someone tell me what the address of the person in Sweden
>is who kindly provided a set of MIME-conformancy tests via
>listserver...
My address is p...@bunyip.com, and the address of the listserver
is mime...@bunyip.com. Send the command (actually the name of the
file you want) as the subject in the message. Start with the command
"HELP".
[ "Erik Huizer (SURFnet BV)" <Erik....@surfnet.nl> 20-Jan-1995 ]
Test messages can be requested in the following way:
Send mail to <mime...@relay.surfnet.nl> with a subject field
containing [ a type/subtype designation, or one of these: ]
X-local <to test how your UA deals with undefined content-types>
nested <returns a message that contains nested multipart contents>
iso-8859-1 <returns a message with text/plain charset=iso-8859-1>
A message containing the requested content-type will be returned to
the address contained in the from field.
--
3.12) Wouldn't MIME be better if it did <foo>?
This question is asked for various values of <foo>. Perhaps the most
common is "multilevel encodings": see the next question. There are
a couple general points that apply to all <foo>.
1. Please remember that MIME is the result of a lot of work by a lot
of persons, over a long time (look at the Acknowledgements section of
RFC 2049). A great many ideas, probably including yours, were
considered. In many cases, there were conflicting goals, such as
simplicity and interoperability on the one hand, and power and
flexibility on the other.
2. If you really think you've got an original idea which would improve
MIME, the correct place to pursue it is not this newsgroup, but the
working group mailing list (having first read the archives, to check
that it really is new). Yes, this is going to be a lot more work than
posting a news article.
--
3.13) So what about multilevel encodings?
MIME uses a two-level encoding scheme. The original object (for
example, a picture, or a text document) is encoded using a well
defined mechanism appropriate to that object (perhaps GIF for the
picture, and text/enriched for the document). Then a second encoding
is used to ensure that the first encoding can be transmitted intact
(probably base64 for the GIF, and quoted printable for the
text/enriched document).
Note that there is a very small number of the second encodings (five,
but three of these are simply indications of what kind of data an
unencoded body part contains), and it is not expected that there will
be many more in the foreseeable future.
The multilevel encodings idea is for a more generalized MIME-like
encoding mechanism that could indicate many arbitrary transformations
of the original object. For example,
Content-Type: application/tar; conversions="encrypt,compress,uuencode"
might indicate a UNIX tar file that had been encrypted, then
compressed, then uuencoded. (This is a fictitious example of how MIME
might have worked; it's not legal MIME. Don't worry if you've never
heard of some of these transformations.)
This may look like an attractive scheme at first, but it has a number
of problems.
1. If you've been brought up on UNIX and command pipelines, the
implementation of such a scheme seems trivial. Surely any half-decent
machine can do something similar? Unfortunately, this turns out to be
true only for a very restricted definition of "half-decent". In
practice, it would be awfully difficult to implement this on a lot of
systems. Probably even more systems would not allow new
transformations to be just "slotted in", and would require
recompilation or reshipping whenever a new one came along.
2. Each successive transformation reduces the size of the audience who
can successfully decode the message. Every MIME mailer must be able
to decode base64 and quoted-printable, so it's guaranteed that you can
at least get back to the raw data. What if, in the above example, I
have tar, decrypt, uudecode, but no uncompressor?
3. Such a scheme does not increase the scope of the framework defined
by MIME. If uuencoded, compressed, encrypted tar files are useful
things to sling around, it is entirely possible to define a new MIME
type (presumably a subtype of application) to handle them.
--
3.14) Why doesn't MIME include a mechanism for compression?
Compression is a difficult area. It was considered by the working
group, but no consensus was reached. There is still work going on in
this area: there may someday be a compressed-64 encoding.
Most compression algorithms have one of more of these undesirable
properties: they are covered by patent, they require the ability to
treat the input as a stream of bits, they use a large data space. The
chances of finding a truly interoperable compression algorithm are
therefore rather slim.
It is worth noting that most or all of the image and video subtypes
(including GIF, JPEG, TIFF, and MPEG) define their own compression
schemes.
--
3.15) What's this Content-Disposition header?
It's a way to specify what needs to be done with a MIME content, such
as storing it in a file with a particular name, or displaying it.
For information about Content-Disposition, see RFC 1806.
See also RFC 2112 and the following draft document for information
about a complementary content-type, multipart/related.
--
3.16) What character sets can be used with MIME?
There are several character sets registered for use with MIME. The
registered character sets are listed in the media-types document
(see appendix A).
[ Jungshik Shin <jung...@net161-61.student.yale.edu> 20-Jul-1996 ]
Chuck Cairns (chu...@fc.hp.com) wrote:
> Can someone give me a pointer to the MIME charsets used for Japanese
> (shift-jis and euc) and Chinese. I've read thru the faq and looked at
> rfc1700 but it's not clear to me what is usual practice.
See RFC 1468 for Japanese, RFC 1557 for Korean and RFC 1922 for
Chinese, all available at ftp://ftp.internic.net/rfc and other places.
Also, you may wish to read Ken Lunde's CJK.inf at
http://jasper.ora.com/lunde and references therein.
[ Knut S. Vikor <knut....@smi.uib.no> 12-Dec-1996 ]
This just to note an "ABC on using languages other than English on the
Net", which aims at giving an introduction to the uninitiated about
what the problems are for using non-English in email or other network
communications.
http://www.hf.uib.no/smi/ksv/char.html
--
End of Part 3
*************
--
MIME FAQ maintainer
Archive-Name: mail/mime-faq/part9
Version: $Id: mime9,v 3.23 1997/06/11 23:27:11 jsweet Rel $
Posting-Frequency: monthly
--
==========================================================
comp.mail.mime frequently asked questions list (FAQ) (9/9)
==========================================================
Part 9: Appendix C(2): Commercial MIME products
--
Overview
--------
This is part 9 of a Frequently Asked Questions document about MIME, the
multipurpose and multi-media standard for Internet mail.
The usual disclaimers apply; you know what they are: no
endorsements implied, no warranty, no safety, no nuthin'! :-)
--
C) Commercial MIME packages (continued)
--
Name: Mail*Link Internet for PowerTalk
Product: PowerTalk to SMTP/MIME Internet Mail Gateway
Platform: Macintosh System 7.5
Contact: in...@starnine.com
Phone: 510-649-4949
Author: StarNine Technologies, Inc.
Comments:
[David Thompson <da...@starnine.com> 19-Sept-1994 ]
Mail*Link Internet for PowerTalk is a personal gateway that allows
System 7.5 users in SMTP/POP3 environments to exchange messages
with Internet mail users.
Version 1.0 supports System 7.5 and System 7 Pro Macintoshes with
MacTCP (included) on a local area network. It uses the standard
Simple Mail Transfer Protocol (SMTP) and Post Office Protocol
(POP3) for sending and reading mail within the LAN. If the LAN is
connected to the Internet, PowerTalk users can also exchange
messages with external Internet users. Version 1.5, due out in
September, 1994 will support SLIP or PPP connections.
Incoming Internet messages are placed in the PowerTalk universal
mailbox on the desktop. Users can send Internet messages from
within their preferred PowerTalk-savvy application such as
WordPerfect, ClarisWorks, or the Finder. The gateway supports
standard Macintosh file enclosure handling methods including
AppleSingle-UUEncode, Datafork only-UUENCODE, MacBinary, and
BinHex, as well as MIME.
A 60-day trial version of the gateway is available on StarNine's
anonymous FTP server (ftp://ftp.starnine.com/pub/evals/pt-inet)
as well as on the CD-ROM version of Apple's System 7.5 product
(look in the CD Extras folder).
Name: Marcel Lite
Product: MUA
Platform: Acorn RISCOS
Contact: ANT Sales <sa...@ant.co.uk>
Phone: +44 1223 567808
Where: http://www.ant.co.uk/
Author:
Comments:
[ Nick Smith <n...@ant.co.uk> 17-Nov-1995 ]
Marcel Lite is a MUA for Acorn RISCOS that can decode, display and
compose mail with MIME, uuencode and btoa attachments. Mail can be off
local disc, or from an IMAP server over a TCP/IP stream.
It also operates threading news reading, reading from a local spool or
from an NNTP server.
Details including a datasheet and screenshots are available from:
http://www.ant.co.uk/
Name: Mi'Mail
Product: MUA
Platform: MS Windows 3.x
Contact: in...@irisoft.be
Phone: +32 16 23 23 01
Author: IRISoft Research
Comments:
[ Jean-Louis Herman <jlhe...@irisoft.be> 12-Apr-1995 ]
Mi'Mail is a electronic mail product with:
- Full MIME support (Nested multiparts, Message/Partial,...).
- Distributed address books.
- Connection with X500 for getting electronic addresses.
- Distributed, hierarchical and open folder system (folders
contain messages but also any kind of document, any application
can get the information stored in the folders).
- User friendly interface (drag and drop, context sensitive help,
powerful editor).
- Uses SMTP and POP3 over TCP or over serial lines with modems.
- Automatic solution for managing the compatibility between MIME
and non MIME users.
- DDE server (with the same interface as cc:mail).
- Transparent support of ISO 8859 character sets.
- Easy management of the attachments (use of the Windows
registration database, drag and drop,..)
- Automatic mail checking, sendmail acknowledgment support,
Multi-user application.
An evaluation version is available at the following site:
ftp://ftp.eunet.be/pub/EUnet/dos
Name: MMail
Product: MUA
Platform: SunOS, Solaris
Contact: mm...@atelier.demon.co.uk
Author: Atelier de Software Ltd.
Comments:
[ "Dr. Martin R. Raskovsky" <mar...@atelier.demon.co.uk> 18-Jul-1995 ]
MMail: a WYSIWYG text composition, visualization and MIME mailer.
- Text organized in different fonts.
- Inline images (images mixed with text)
Works on Sun/SPARC with:
Operating System: SunOS 4.1.2 or greater, Solaris 2.1 or greater
Window Manager: X11, OpenLook, Motif
Free full functionality evaluation available via FTP.
MMail - Features:
WYSIWYG full text composition and visualization.
(MIME/text/enriched or MIME/application/MMail)
Text Organization:
Adjust to margins
Line attributes (Left, Center, Right, Spread, Fixed)
Images mixed within text delivered as multipart/mixed
IMAP2 interface (and IMAP4 when it becomes available)
Hyphenation (in 17 different languages)
Spell (via Unix spell)
Multiple fonts (ISO-8859-1)
MIME/attachments via mailcap to viewer
Alias and Group
Mail Box Filing/Editing
Ignored unwanted headers
Automatic File Carbon Copy
File Include (signature, template, image)
Message Find/Sort/Move/Delete/Undelete/History
Data Base of known MIME/MMail users
Name: MPOWER
Product:
Platform:
Contact:
Author: HP
Comments:
[ Harald Alvestrand <Harald.A...@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: NetMail/3000
Product: SMTP/MIME compatible electronic mail system for HP3000s
Platform: HP3000 MPE/V, HP3000 MPE/iX
Contact: solc...@netcom.com (Solution Centers International)
Telephone: (US) 800 Net-Mail (UK)+44 (0480) 301364 (Other) +1 916 622-0630
Fax: (US) 916 622-0738 (UK) +44 (0480) 493109 (Other) +1 916 622-0738
Author: 3k Associates (sup...@3k.com)
Comments:
[ Chris Bartram <r...@3k.com> 3-Jun-1994 ]
NetMail/3000 is a full featured electronic mail system for HP3000
computer systems which was designed as an SMTP and MIME compatible
network mail system. NetMail/3000 provides a user interface
compatible with "dumb" terminals, but also has hooks to identify and
utilize features of HP terminals and PC or Mac based HP terminal
emulator packages. Users can send messages (8-bit character sets are
supported) and attach any number of files (host or pc based) to their
messages (PC/Mac based files are automatically retrieved and loaded),
and all messages (and attachments) are exported in MIME format, though
users can specify that files be encoded via 'uuencode' or 'binhex' if
necessary to be readable by non-MIME compatible mail systems).
NetMail/3000's user interface is also unique in that Windows-based
terminal emulator users can allow NetMail/3000 to automatically
extract and pass any message parts (not displayable in the terminal
emulator) directly to their PC and have the appropriate application
launched to view the file. (NetMail/3000 interrogates the PC on
startup to determine the file types "associated" with applications.)
NetMail/3000 also includes directory synchronization capability
(compatible with Lotus' cc:Mail ADE format), a POP2 server, a
quote-of-the-day and daytime server, and will soon be offering a
HP3000-based gopher server. NetMail/3000 is priced independent of cpu
size/speed/number of users, and includes network capability in the
base product. 3k Associates is also an HP Channel Partner.
Name: NetMail/3000 HPDesk FSC Gateway
Product: SMTP/MIME compatible gateway for HPDesk users
Platform: HP3000 MPE/V, HP3000 MPE/iX
Contact: solc...@netcom.com (Solution Centers International)
Telephone: (US) 800 Net-Mail (UK)+44 (0480) 301364 (Other) +1 916 622-0630
Fax: (US) 916 622-0738 (UK) +44 (0480) 493109 (Other) +1 916 622-0738
Author: 3k Associates (sup...@3k.com)
Comments:
[ Chris Bartram <r...@3k.com> 3-Jun-1994 ]
The NetMail/3000 HPDesk FSC Gateway provides a bi-directional gateway
between HPDesk mail users and the SMTP/MIME world. Any number of
message attachments per message are supported; incoming messages are
broken down into files on the HP3000 for HPDesk users and appear as
normal message attachments, outgoing attachments are encoded as
MIME-compatible message attachments (or optionally just as UUENCODED
binary attachments for compatibility with non-MIME compatible
mailers).
The gateway operates in real-time, is a background process on the
HP3000 (which is interrupt driven and uses minimal system resources),
and requires no special hardware or additional software. The product
is priced independent of platform size or type or number of users.
Free 45 day demos are available.
Name: Netscape Navigator 2.x (Mozilla)
Product: MUA, NUA
Platform: Windows, Macintosh, Unix
Contact: in...@netscape.com
Where: http://home.netscape.com/
Where: ftp://ftp.netscape.com (free downloadable evaluation version)
Author: Netscape Communications Corporation
Comments:
[ Jamie Zawinski <j...@netscape.com> 1-Feb-1996 ]
Netscape Navigator, a World Wide Web browser, is now a MIME mail
and news reader as well. Features of version 2.0:
- simple graphical user interface;
- POP3, SMTP, NNTP, and NNTP+SSL ("secure news") on all platforms;
- supports direct mail-spool access or external "movemail" on Unix;
- drag and drop between folders;
- integrated address book, including mailing lists;
- built-in "biff";
- inline display of HTML, Enriched Text, GIF, JPEG, and XBM documents;
- automatic encoding in base64 and quoted-printable, as appropriate;
- automatic decoding of base64, quoted-printable, and uuencode;
- support for AppleDouble attachments on all platforms;
- nearly identical UI for mail and news;
- tightly integrated with the World Wide Web, including all the usual
Netscape Navigator features;
- very fast!
Free unlimited-functionality 90 day evaluation copies are available
for the following platforms:
- Windows 3.1 - IRIX 5.x
- Windows95 / Windows NT - Linux
- Macintosh - OSF/1 2.0
- AIX 3.2 - SunOS 4.x
- BSDI - SunOS 5.x (Solaris 2.x)
- HPUX 9.xx
See http://home.netscape.com/comprod/mirror/index.html to download it.
[ John Delacour <ere...@bournemouth-net.co.uk> 27-Mar-1996 ]
I used Netscape [2.0 for the Macintosh] only for a short while to
test it and compare it - at least they do allow modification of
the character set in the header in the user interface which is
something most other mailers are only just realizing is important,
but the ... errors in Quoted-Printable make it unreliable from the
point of view of most ordinary users.
[ Jamie Zawinski <j...@netscape.com> 28-Jun-1996 ]
Mozilla 3.0b5 has just been released. We have made three distinct
sets of improvements to the mail and news subsystems: we have added
options to change the word-wrapping behavior of the Message
Composition window; we have added related options to change the
wrapping behavior of the Mail and News viewing windows; and we have
made a number of improvements to the presentation of attachments.
[ Steinar Bang <s...@metis.no> 07-Oct-1996 ]
> what is the best setting for e-mail/news: MIME or 8-bit?
Your message will still be a MIME message, even if you toggle on
"8bit". In particular, this toggle doesn't affect the encoding of
images.
Using anything except 8bit will get you flamed on Norwegian news
groups. Especially if you use national characters in headers.
This same switch also quietly toggles on and off RFC 1522 [obs.]
encoding in headers. Since the RFC 1522 [obs.] encoding is broken
on older versions of Netscape (is it still broken in release
3.0?), it won't even show up correctly on news readers that are
MIME savvy (eg. Gnus + tm).
Name: ObjectSet MAIL SDK
Product: OO SDK
Platforms: Win32, Win16, MacOS, Java
Contact: in...@smartcodesoft.com
Phone: (847) 945 3516
Where: http://www.smartcodesoft.com and http://www.smartcode.fr
Pricing: $395-$495
Author: Smartcode Software Inc
Comments:
[ Olivier Meirhaeghe <olivier.m...@smartcodesoft.com> 6-Nov-96 ]
ObjectSet MAIL SDK is a MIME/SMTP/POP3 SDK. It encapsulates these
three protocols in an EZ OO API. ObjectSet supports MIME1.0. The
MailMessage (MIME) Objects handles construction and parsing of MIME
compliant messages, encoding of Bodyparts. It is aimed towards
developers who want to easily integrate Mail into their applications,
or use Mail as the transport layer for their development. Integrates
with MFC (windows),CodeWarrior/Powerplant,MacApp (Apple). DLLs, OCX ,
ActiveX and Java to come. Unix: Ask us.
Further Details, Demo MUA and MIME Explorer, Sample Application source
Code, and a demo version of the Libraries with complete documentation
can be found on our web site, at http://www.smartcodesoft.com/
Name: PC-MM (PC Mail Manager)
Product: MUA
Platform: MS-Windows
Contact: Lars_H...@li.icl.se
Author: ICL
Comments:
[ Tomas Kullman <to...@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_H...@li.icl.se or
phone: + 46 (0)13 11 70 00.
[ Brad Knowles <br...@azathoth.ops.aol.com> 3-Apr-1996 ]
According to Matt Wall's web page "E-mail Web Resources" at
http://andrew2.andrew.cmu.edu/cyrus/email/email.html, PC-MM has been
renamed Embla.
Name: PMDF
Product: MTA
Platform: VMS
Contact: sa...@innosoft.com ser...@innosoft.com
Author: Innosoft International
Comments:
The VMSNET newsgroup 'vmsnet.mail.pmdf' is available for discussion.
[ Ned Freed <n...@innosoft.com> ]
Send technical inquiries to ser...@innosoft.com. Product
information, pricing, and literature can be obtained from
sa...@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: SecureMail
Product: MUA
Platform: AIX 3.2.5, SunOS 4.1, HP-UX 10.0, Open Desktop 3.0
Contact: in...@sware.com
Phone: (404) 315-6296, ext. 112
Where: http://www.secureware.com
Pricing: $200 - $275
Author: SecureWare, Inc.
Comments:
[ Dottie Thornton <dot...@sware.com> 27-Jul-95 ]
SecureMail is an e-mail package that includes Privacy Enhancement
and Digital Signature capabilities. SecureMail supports MIME with a
Motif graphical user interface and includes the following features:
- Authentication, integrity, and encryption of messages
- Graphical interface and on line help.
- Spelling checker and word wrap.
- Address book with groups and nicknames
- Support for multi-media (MIME) attachments.
SecureWare, Inc.
2957 Clairmont Road, Ste. 200
Atlanta, GA 30329
Name: SMTPLINK 2.1
Product:
Platform:
Contact:
Author:
Comments:
[ <sup...@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: in...@sti.fi
Author: Stream Technologies Inc
Comments:
[ Ed Anselmo <ans...@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
E-Mail: in...@sti.fi
Name: Super-TCP
Product: protocol stack + MUA
Platform: MS-Windows
Contact: T...@FrontierTech.COM
Author: Frontier Technologies
Comments:
[ Ray C Langford <r...@isi.frontiertech.com> 28-Apr-1993 ]
Frontier Technologies' Super-TCP for MS-Windows includes MIME
support in their E-Mail 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 E-Mail, Telnet Redirector,
Interactive Talk, and more. Options are also available for PPP,
X.25, and OSI.
With the MIME support in E-Mail, 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
E-Mail (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, e-mail T...@FrontierTech.COM or call
+1 414 241-4555.
[ "Carl S. Gutekunst" <c...@hideji.worldtalk.com> 31-Oct-1994 ]
The current release of SuperTCP is 4.00R2. The stack no longer
supports a TSR mode. Their MIME MUA is considerably improved in
this release.
Name: TCP/Connect II version 2.0
Product: MUA, news reader
Platform: Macintosh
Contact: sa...@intercon.com
Author: InterCon Systems Corporation
Comments:
[ Amanda Walker <ama...@intercon.com> 6-Sep-1994 ]
Full support for MIME in email, viewing support for MIME in news.
Includes inline composition and display of the following MIME
content types:
text/plain image/gif video/quicktime
text/richtext image/jpeg audio/basic
text/enriched image/x-macpict
application/applefile
application/x-macbinhex40
multipart/mixed
character sets: US-ASCII, ISO-8859-1
Provides drag & drop support for file enclosures, automatic
encoding and decoding of AppleSingle/AppleDouble ("MacMIME") body
parts, as well as BinHex & uuencode for backward compatibility.
Runs native on Power Macintosh computers.
For more information please contact:
InterCon Systems Corporation
950 Herndon Parkway
Herndon, VA 22070 USA
+1 703 709 5500 (voice)
+1 703 709 5555 (fax)
sa...@intercon.com (Internet email)
[ Dave Saunders <da...@intercon.com> 7-Mar-1995 ]
To add to the list of contact information:
http://www.intercon.com/
ftp://ftp.intercon.com/
Additionally, we have a Windows product which also is MIME
aware. It does not have the nifty display features that the
Mac product has though...
Name: TenFour
Product: TFS Gateway
Platform: Windows
Contact: in...@tenfour.com
Where: http://www.tenfour.com
Comments:
[ Rickard Olsson <ric...@tenfour.se> 24-May-1996 ]
The TFS Gateways are an entire family of Windows-based modules which
connect different electronic mail systems to one another. TFS
connections to Internet Mail (both SMTP and UUCP) and MCI Mail exist
from cc:Mail, Microsoft Mail, Microsoft Exchange, Lotus Notes, Novell
GroupWise and FirstClass. Features include directory synchronization,
easy install and setup in Windows, MIME compatibility, traffic
statistics, mailback, virusscanning and auto reply.
Name: Ultimate Mail Tool
Product: MUA
Platform: Linux
Platform: IRIX
Platform: HPUX
Contact: u...@topaz.kiev.ua,lo...@crocodile.org
Contact: http://www.crocodile.org/UMT/UMT.html
[ Vadim Zaliva <lo...@crocodile.org> 31-Jan-1996 ]
UMT is MIME mail reader for Unix/X11.
Key features:
1. Xfaces
2. POP3.SMTP
3. ! Multifont/color message editor end viewer
4. Fancy GUI
5. Easy customisable
Now it's beta. All betas are Free. Linux version will be free
forever. We are going to sell version for HP and SGI. SUN version
coming soon.
Name: WIG (Workgroup Internet Gateway)
Product: MTA
Platform: MS Windows 95
Contact: Simon Bates <s...@softalk.demon.co.uk>
Contact: http://www.demon.co.uk/softalk
Author:
Comments:
[Simon Bates <s...@softalk.demon.co.uk> 07-Jul-1996]
The Workgroup Internet Gateway lets an entire organisation send and
receive Internet mail using only a single dial up (or direct)
connection to the Internet.
The Workgroup Internet Gateway will let users of MS Exchange client
for Win95 (or any MAPI enabled client, such as Netscape) and MS Mail
3.11 send and receive Internet mail. All incoming mail is held
centrally in a database and redistributed to the relevant In boxes.
WIG can send and receive binary files in MIME format.
Name: Z-Mail
Product: MUA
Platform: Unix
Contact: in...@z-code.ncd.com
Contact: http://www.ncd.com/
Contact: ftp://ftp.ncd.com (downloadable demo version)
Author: NCD Software Corp.
Comments:
[ Carlyn M. Lowery <low...@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.
[ Scott Hetherington <sc...@z-code.ncd.com> 26-Oct-1995 ]
We have released several versions of Z-Mail for Windows and Z-Mail
for Macintosh (both MIME compliant).
--
End of Part 9
*************
--
MIME FAQ maintainer
Archive-Name: mail/mime-faq/part8
Version: $Id: mime8,v 3.23 1997/06/11 23:27:11 jsweet Rel $
Posting-Frequency: monthly
--
==========================================================
comp.mail.mime frequently asked questions list (FAQ) (8/9)
==========================================================
Part 8: Appendix C(1): Commercial MIME products
--
Overview
--------
This is part 8 of a Frequently Asked Questions document about MIME, the
multipurpose and multi-media standard for Internet mail.
The usual disclaimers apply; you know what they are: no
endorsements implied, no warranty, no safety, no nuthin'! :-)
--
C) Commercial MIME products
Submission guidelines:
Information for this section about commercial MIME-capable software
packages may be contributed by anyone, including the firms offering
the packages.
The FAQ maintainers look with favor on _brief_ entries, preferably as
non-hypeful as possible, that are provided in the existing entry
format, but it's fair simply to offer corrections, updated
information, or unbiased consumer-oriented comments.
Send new or updated entries to the address "mime...@ics.uci.edu";
posting to comp.mail.mime isn't necessarily sufficient.
This section is getting unwieldy, so all entries for commercial
products may be subject to being edited down to shorter summaries of
any available concrete information, along with contact information and
any relevant URLs.
Readers should bear in mind that files whose names contain version
numbers are often out of date by the time that you try to find them,
so you may need to poke around in the parent directories to locate the
latest versions.
--
Name: Echelon
Product: MUA
Platform: NEXTSTEP
Contact: ak...@freenet.acsu.buffalo.edu
Author: Doug Boyce <ak...@freenet.acsu.buffalo.edu>
Comments:
Echelon is a MUA for NEXTSTEP that can decode, display, and compose both
NeXTmail and MIME. Most MIME types are supported. A demo version is
available from
Where: ftp://nova.cc.purdue.edu/pub/next/submissions/Echelon_1.12.tar.gz
Name: ECSMail
Product: MUA/MTA
Platform: Unix, NT, OS/2, OpenVMS, MS-DOS, MS-Windows, Mac System 7
Contact: ECS Sales <ecs-...@edm.isac.ca>
Phone: +1 403 420 8081
Author:
Comments:
[ Steve Hole <st...@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-...@edm.isac.ca>
Name: E-Mail Connection 2.5.03
Product: MUA
Platform: Microsoft Windows
Where: http://www.connectsoft.com/products/free_emc25.shtml
Contact: ConnectSoft
Comments:
[ "Daniel J. Trentman" <tren...@seis.utah.edu> 16-Jul-1995 ]
The following introduced it to me:
-------
From yx...@econ.lsa.umich.edu (Yuan Xiao)
Newsgroups: comp.mail.misc
Subject: a very very good e-mail program
Date: 13 Jul 1995 22:03:44 GMT
I'm wondering why nobody has mentioned E-Mail Connection 2.5.03 from
ConnectSoft. The commercial version is an award-winning all-purposed
e-mail program that can send e-mail to internet, AOL, CompuServe, etc.
Now they are giving away a version of this program for free! It has
all features of the commercial version but can only send internet
e-mail (but I think many people only need to send internet e-mail). It
has MIME, automatically records sender's address in your address book,
has a spell checker, rules to sort incoming mail, folders, drag and
drop, two modes of operation (one for novices with help and one for
experts), automatic checking incoming mail on server at scheduled time
interval, etc. Above all, it has the most beautiful interface I've
ever seen in an e-mail program (except for that e-mail program in the
movie "Disclosure". I'm wondering does such a thing exist or is
anybody going to write one?). You can even set a wallpaper in the
program window. It certainly beats Eudora (the freeware version. Of
course, it beats any commercial program by price) in terms of features
and interface. It's as easy to use. It's superior to Pegasus in terms
of interface and ease of use. I don't know how it compares to Pegasus
in terms of feature but it does include all the features an average
user will ever need. It's such a pleasure to use this program that I
find I'm sending much more e-mails after I acquired this program!
- -Aaron
-------
Name: Eudora 2.0.2
Product: MUA
Platform: Macintosh
Contact: eudora...@qualcomm.com
Author: Steve Dorner <sdo...@qualcomm.com>
Author: Jeff Beckley <bec...@qualcomm.com> (Windows Version)
Comments:
Commercial versions of Eudora with more features than the freely
available ones.
Information about the commercial versions of Eudora can be found at:
ftp://ftp.qualcomm.com/quest/eudora/windows/Eudor2Info-*.exe
ftp://ftp.qualcomm.com/quest/eudora/mac/Eudora2Info-*.sea.hqx
Name: IBM multimedia mail
Product:
Platform: OS/2
Contact: Jerry Cuomo <gcu...@watson.ibm.com>
Author: IBM
Comments:
[ Larry Salomon Jr <os2...@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 gcu...@watson.ibm.com.
Name: iGate
Product: WordPerfect Office gateway
Platform:
Contact: sm...@actrix.gen.nz
Author: Smart Systems
Comments:
[ Quentin Smart <sm...@acme.gen.nz> 25-Sep-1993 ]
iGate provides seamless connectivity 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
sm...@actrix.gen.nz
Name: Internet Exchange for cc:Mail
Product: cc:Mail to SMTP/MIME Internet Mail Gateway
Platform: MS-Windows, Windows for Workgroups, Windows 95, Windows NT
Contact: in...@ima.com
Phone: +852 2649-0135
Fax: +852 2648-5913
Author: International Messaging Associates Ltd
Comments: Updated information available at http://www.ima.com
[ Tim Kehres <keh...@ima.com> 08-Nov-1995 ]
For cc:Mail users, Internet Exchange is the gateway of choice to
provide standardized full multimedia connectivity between cc:Mail
users and their Internet partners. Internet Exchange for cc:Mail
can be used to interconnect cc:Mail networks with external users on
the Internet as well as connecting your own internal network to your
cc:Mail community.
Internet Exchange for cc:Mail Version 1.0 was the first SMTP to
cc:Mail gateway that supported the full MIME Internet standard.
This capability provided cc:Mail users with the ability to exchange
any attachment types with Internet-based email systems.
Version 1.1 of Internet Exchange adds to these capabilities by
giving Macintosh and PC cc:Mail users the ability to transparently
exchange files across platforms. Internet Exchange now supports
all Apple Macintosh file handling standards including MacMIME,
AppleSingle, AppleDouble, and BinHex as well as MIME and UUENCODE
for PC's and UNIX.
Internet Exchange gives administrators complete flexibility with
address translations. Instead of forcing a fixed conversion format
between cc:Mail user names and Internet addresses, the user names
found in the cc:Mail post office directory are first grouped into
three parts: one first name, zero or more middle names, and one
last name. The administrator can combine them in an almost infinite
number of ways for the desired address translation between cc:Mail
user names and their Internet counterparts. This automation of
the address translation rules results in significant manpower
savings versus manually maintaining address translation tables.
Internet Exchange allows for the storage of information about
destination, or peer-based capabilities. These capabilities
include attachment types that can be decoded on the remote side,
as well as permissions related to the sending and receiving of
messages to the remote machine or domain. Internet Exchange
consults the peer database prior to sending messages to first
obtain permission to send messages to the destination, and then
to determine the appropriate attachment types and encoding
methods that can be successfully received by the remote system.
To simplify administration and management, the Internet Exchange
System Manager runs under several Microsoft Windows based operating
systems. On screen buttons provide rapid access to all the gateway
operations which allow administrators to view and modify all gateway
activity. Message routing is accomplished using any combination of
host tables,Domain Name System (DNS) lookup, and default mail host
routing.
Name: Internet Mail Center
Product: gateway
Platform: Microsoft Windows
Author: U.S. Computer
Contact: sa...@usc.com
Phone: +1 408 446-0387
Fax: +1 408 446-1013
[ Will Estes <wes...@usc.com> 15-Dec-1995 ]
Internet Mail Center is a complete solution for connecting
cc:Mail and Lotus Notes mail networks to the Internet, or
to a corporate TCP/IP protocol backbone network, using the
Simple Mail Transfer Protocol (SMTP). Using Internet
Mail Center, your mail users will be able to
communicate with other SMTP RFC-822-compliant mail systems
such as UNIX sendmail, IBM PROFs, and PC-based SMTP networks.
Designed from scratch to run under Microsoft Windows 3.1, and
with a Microsoft Windows/NT 3.51 version that runs as a true NT
service due out shortly, Internet Mail Center is a secure,
cost-effective solution for small and large companies that want
to connect to Internet using industry-standard operating systems.
Internet Mail Center supports cc:Mail, Notes, and stand-alone
SMTP mail server applications.
Internet Mail Center offers full support for the Multipurpose
Internet Mail Extensions (MIME) standard, which allows for
transport of 8-bit binary content over the Internet. With
MIME, your cc:Mail and Notes users can attach binary files
using the native cc:Mail and Notes user interfaces, without
the need for any additional steps to decode or prepare messages
bound for the Internet. Messages are sent and received using
the standard interfaces for file attachments, seamlessly, and
easily.
Internet Mail Center was designed for large heterogeneous
network environments with many concurrent senders and receivers
of mail. On simple '486-class hardware, Internet Mail Center
supports more than 60 concurrent SMTP transactions.
Internet Mail Center performs many of the same functions that
UNIX sendmail does, allowing a system administrator to rewrite
user and host addresses for incoming and outgoing mail.
For More Information Contact:
U.S. Computer
[ contact information above ]
Name: InterOFFICE
Product: Multiplatform MTA and gateway for most email systems
Platform: UNIX, OS/2, VAX/VMS, Tandem NonStop, NeXTSTEP, HP 3000, AS/400,
VM/370, Wang VS
Contact: in...@bsw.com
Contact: Kevin McCarthy <k...@bsw.com>
Phone: +1 617 482 9898
Author: The Boston Software Works, Inc.
Comments:
[ Larry Campbell <camp...@bsw.com> 28-Jan-1995 ]
InterOFFICE is a portable and modular family of gateway modules
(access units, we call 'em) that interconnect a wide variety of email
systems, including: ALL-IN-1, cc:Mail, HP Desk, HP OpenMail, IBM
OfficeVision/400, IBM OfficeVision/VM (formerly known as PROFS),
Microsoft Mail, NeXTMAIL, Novell MHS, QuickMail, Tandem TRANSFER, Wang
OFFICE, X.400, and of course, Internet mail. The Internet access unit
fully supports MIME, enabling users of proprietary email systems to
exchange multipart messages containing text, images, audio, and binary
files with Internet users.
Name: Ishmail
Product: MUA
Platform: SunOS, Solaris, AIX, HP-UX, and UnixWare
Contact: in...@hal.com
Phone: +1 800 762 0253 or +1 512 834 9962
Where: ftp://ftp.halsoft.com
Pricing: $99 U.S. for single user. Multi-user/site license discounts.
Author: HaL Software Systems
Comments:
[ Frank Bieser <fra...@hal.com> 21-Jun-1994 ]
Ishmail is a MIME-capable e-mail tool with a Motif graphical user
interface. Ishmail includes the following features:
- Full support of MIME data types: plain text, rich text, GIF,
JPEG, U-LAW audio, MPEG, binary, PostScript, ODA, RFC822 mail
message, plus user-defined extensions.
- Message attachments supported via: local file, AFS, mail server,
regular FTP, anonymous FTP, and TFTP.
- Support for composing, viewing, and printing rich text messages.
- Easily customized through GUI dialogs for fonts, definition and
placement of custom buttons, message list sorting and format, etc.
- Variety of user interaction methods, ranging from "drag and drop"
and custom buttons to keyboard shortcuts.
- Support for use of, modification, and addition of sendmail-style
mail aliases.
- User defined alert commands and icons, triggered by matching
patterns in incoming mail headers.
- On-line help cards, including context sensitive help.
- Full end-user manual provided in PostScript format.
- Complete hypertext version of end-user manual available via World Wide
Web at http://www.hal.com/products/sw/ishmail/user-guide.html
HaL Software Systems
3006 Longhorn Blvd #A-113
Austin, TX 78758-7631
Name: ISODE Consortium MTA
Product: MTA
Platform: UNIX
Contact: ic-...@isode.com
Where: http://www.isode.com/
[Steve Kille <S.K...@isode.com> 26-Oct-1995]
The ISODE Consortium MTA is an X.400 and SMTP mailer, and a gateway
between these, so you can communicate with "both worlds". This
product is based on the older public domain PP MTA.
The Messaging products in the latest Isode Consortium Release
(3.0) include:
o MESSAGE TRANSFER AGENT (MTA). The MTA is designed for high
performance and operational robustness in a multi-protocol
environment. It supports X.400 (1984, 1988, 1992),
Internet Mail (SMTP/MIME), and X.400/MIME mapping according
to RFC 1327. There are extensive management features
including SNMP monitoring according to MADMAN (RFC 1566)
X.500 based routing according to the IETF MHS-DS specifications
(RFC 1801), authorisation, content conversion, and flexible
configuration.
o MESSAGE STORE. Provides multi-protocol access, using X.400
P3 and P7 and the Lightweight Message Access Protocol (LMAP)
which supports X.400 and Internet Messages. Integrated with the
MTA using P3 or co-resident access. Configuration uses
X.500, based on MHS-DS.
o MESSAGE AND DIRECTORY INTEGRATION APIs. Provision of X/Open
OSI integration APIs (MT, XDS and OM) and APIs for
integration using lightweight access protocols (LMAP, LDAP).
o X.509 SECURITY LIBRARIES. A suite of libraries providing
range of cryptographic algorithms (MD5, SHA, RSA, DSA) and
tools to form the basis of a Certification Authority based on
X.509(93) version 3 certificates.
o A TCL/TK-BASED CONFIGURATION GUI. This will be provided to
configure of MTAs and Message Stores. The configuration data is
held in the X.500 Directory.
o DOCUMENTATION. Administrator and Programmer manuals,
provided in Postscript and Frame (revisable) format.
The ISODE Consortium is a leading supplier of source technology for
open messaging, directory and security services. The primary focus is
on server technology, which includes management tools and integration
APIs. The ISODE Consortium has led long term activities to promote
open standards and has specified and promoted new standards where none
previously existed.
The ISODE Consortium makes its product available through membership,
which helps it to maintain its technology lead through commercial and
research partnership. The membership approach allows service
providers, OEMs, systems-integrators, government departments and
research organisations to avoid re-inventing non-differentiating core
technology.
The ISODE Consortium product is a source release. Binary Products
based on the technology are available from commercial vendors who are
members of the ISODE Consortium.
Name: Mail 3.3
Product: MUA
Platform: NEXTSTEP
Contact: Lennart Lovstrand <len...@next.com>
Author: NeXT Computer, Inc.
Phone: +1 800-TRY-NeXT, +1 415-366-0900
Comments:
[ Lennart Lovstrand <Lennart_...@next.com> 28-Feb-1995 ]
Mail 3.3 is an easy-to-use multimedia graphical mail user interface
that can send and receive messages in both NeXTmail or MIME format.
It has support for hierarchical mailboxes, address books, "Lip
Service" voice mail and a bunch of other stuff. Mail 3.3 comes as
part of the NEXTSTEP 3.3 User System available for NeXT Computers,
486-based PCs, HP, and SPARC based workstations.
Name: mail4u
Product: UUCP Transport Provider for the MS Exchange client
Platform: Windows 95, Windows NT
Where: http://mail4u.home.ml.org
Author: Erwin Authried
Contact: ea...@cso.co.at
Comment: requires UUCP software (UUPC/extended)
[ Erwin Authried <ea...@mail.cso.co.at> 08-Oct-1996 ]
mail4u is an extension for the Microsoft Exchange client
(a.k.a. "Windows Messaging") that makes it possible to exchange
mail via UUCP.
Currently, the following features are supported:
* MIME Support, Attachments
* 32-Bit DLL
* Low memory requirements
* Flexible configuration: support for single users as well as for
companies
* No limitation on size of body text or attachments
* Setup wizard guides a user in creating a profile
* BSMTP mode for message exchange over filesystem
* Can be used together with other transport providers (MS mail)
mail4u is marketed as shareware, without any warranty. You are
allowed to use it without registration as long as you want.
Registered users can receive free upgrades for 12 months.
Name: Mail*Hub
Product:
Platform: Control Data 4000 Series Mips-based Unix systems
Contact: r...@svl.cdc.com
Author: Control Data Systems
Comments:
[ <r...@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*Link SMTP for QuickMail, Microsoft Mail for AppleTalk, and
PowerShare
Product: Macintosh Mail systems to SMTP/MIME gateways
Platform: Macintosh
Contact: in...@starnine.com
Phone: 510-649-4949
Author: StarNine Technologies, Inc.
Comments:
[David Thompson <da...@starnine.com> 19-Sept-1994 ]
Mail*Link SMTP 3.0 is the industry-standard for connecting
Macintosh mail systems to each other, as well as PC, UNIX and
host-based mail systems on corporate LANs and the Internet. The
Mail*Link family of gateways now provides MIME support for all
major Macintosh LAN messaging systems including QuickMail,
Microsoft Mail for AppleTalk and PowerShare Collaboration servers.
Per-destination processing of messages in version 3.0 allows
gateway administrators to configure translation and enclosure
handling methods for outgoing messages addressed to a specific
SMTP address, domain, or host. The gateway ships with three
preprogrammed translation methods for sending messages to users on
PCs, UNIX, and MIME-capable systems.
Mail*Link SMTP uses the proposed MacMIME standard to allow more
flexibility when receiving messages with MIME-encoded Macintosh
files. An option to encode an attachment's datafork only with
MIME greatly increases compatibility with non-Macintosh MIME
systems. Other enclosure handling options include
MacBinary-UUENCODE, AppleSingle-UUENCODE, BinHex 4.0, and
Datafork-only-UUENCODE, and StuffIt compression.
--
End of Part 8
*************
--
MIME FAQ maintainer
Archive-Name: mail/mime-faq/part6
Version: $Id: mime6,v 3.23 1997/06/11 23:27:11 jsweet Rel $
Posting-Frequency: monthly
--
==========================================================
comp.mail.mime frequently asked questions list (FAQ) (6/9)
==========================================================
Part 6: Appendix B(1): Freely Available MIME products
~~~~~~
--
Overview
--------
This is part 6 of a Frequently Asked Questions document about MIME, the
multipurpose and multi-media standard for Internet mail.
The usual disclaimers apply; you know what they are: no
endorsements implied, no warranty, no safety, no nuthin'! :-)
--
B) Freely Available MIME products
This appendix lists MIME-capable or MIME-enabling libraries,
conversion tools, extension packages, mail user agents, and mail
transport systems.
Tools that are explicitly designed for handling MIME in USENET news
are discussed in appendix B.4, although many of the packages in this
section also deal with USENET news.
Information for this section about MIME-capable software packages may
be contributed by anyone, including the maintainers of the software.
The FAQ maintainers look with favor on brief entries that are provided
in the existing entry format, but it's fair simply to offer
corrections or updated information. Notifications of obsolete or
non-working URLs are also appreciated. Send new or updated entries to
"mime...@ics.uci.edu"; posting to comp.mail.mime isn't necessarily
sufficient.
Readers should bear in mind that files whose names contain version
numbers are often out of date by the time that you try to find them,
so you may need to poke around in the parent directories to locate the
latest versions.
See also: news:comp.mail.misc - "UNIX Email Software Survey FAQ"
--
B.1) Libraries and Patches
Name: c-client
Product: MUA library code
Platform: Unix, Macintosh, MS-DOS, Windows, TOPS-20, VAX/VMS
Where: ftp://ftp.cac.washington.edu/mail/imap.tar.Z
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 various local file formats (e.g. Unix mbox,
mail.txt, mh, mmdf), as well as remote mailbox access via the
NNTP, POP3, and IMAP protocols. This is done transparently so
the main program is normally not aware what kind of mailbox it is
accessing.
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.
c-client is distributed as part of the University of Washington
IMAP toolkit, and includes POP2, POP3, and IMAP2 (IMAP4 support
is coming soon) client and server code. However, c-client does
not require IMAP or POP, and can be built without these.
Contact the author (Mark Crispin <m...@panda.com>) for technical
questions.
Name: FITS-v2
Product: xv patch
Platform:
Where: ftp://orangutan.cv.nrao.edu/pub/aips/xv/FITS-v2.tar.Z
Author:
[ Patrick P. Murphy <pmu...@nrao.edu> 15-Nov-1994 ]
This is a patch to xv that permits it to read and write
FITS files. Granted it's probably not capable of digesting, say,
a UV database from AIPS, but for most FITS images it seems to work
reasonably well. I've used this to patch both xv versions 2 and 3
successfully.
Were you to have this, it would then be possible to view the image
by clicking on the URL/link, viewing it in xv, and then using xv's
save function to save it to a local disk. I have not used this
mode of operation extensively, and it's not at all clear how much
of the header would be preserved beyond the bare essentials, but
it's a start. If you just want "pretty pictures" it's definitely
a good method.
Another option would be to use the .mailcap to specify:
image/fits; saoimage %s
Sorry, I don't know how to make the system recognise a binary file,
though I'm sure it's possible.
Name: MI
Product: library
Platform: UNIX + SendMail
Where: http://java.science.yorku.ca/~davecb/mi
Author: David Collier-Brown <dav...@cs.yorku.ca>
Comments:
MI is a C library for ``Mail Enabling'' programs so that they can send
out mail in MIME format.
Name: MIME++
Product: library
Platform: Unix, Win32
Where: http://www.fwb.gulf.net/~dwsauder/mimepp.html
Author: Doug Sauder
Comments:
[ Doug Sauder <dwsa...@fwb.gulf.net> 8-Feb-1997 ]
MIME++ is a C++ class library for creating, parsing, or modifying
messages in MIME format. Supported features include:
* utility functions for base64 and quoted-printable encoding/
decoding
* all media-types are supported, including multipart/*, message/*,
and application/*
* the class names follow the terms used in the RFC specs as
closely as possible, making the library (hopefully) intuitive
to use
* permits extension through inheritance and polymorphism
MIME++ is under active development (as of Feb 1997) and the list of
features is continually growing.
MIME++ is copyrighted but is free for non-commercial/personal/
educational use.
Name: mimelite
Product: library
Platform: ANSI C
Where: ftp://ftp.sn.no/software/msdos/comm/offline/mimelite.zip
Where: ftp://nic.funet.fi/pub/unix/mail/mimelt20.zip
Author: Gisle Hannemyr <gi...@a.sn.no>
Comments:
[ Gisle Hannemyr <gi...@a.sn.no> 20-May-1994 ]
"mimelite" is a simple, lightweight library written in ANSI C that
supports the parsing of MIME headers and encoding/decoding of body
parts, suitable for inclusion in offline-readers.
If you develop mail and newsreader software (user agents), you
can link mimelite with your own program to make it support a
significant subset of MIME (namely the Content-Transfer-Encodings
7BIT, 8BIT, BASE64 and QUOTED-PRINTABLE). mimelite also supports
conversion between the ISO Latin 1 character set used for European
character sets on USENET/Internet and PC-based character sets
(e.g. Macintosh, IBM CP-437 and CP-850).
The distribution archive also contains UNMIME, a standalone program
to decode MIMEd messages encoded with BASE64 or QUOTED-PRINTABLE
encoding. [ Contains UNMIME.EXE for MSDOS. ]
The mimelite library is general enough to work in a number of
contexts, but it has been designed to work well on MS-DOS (where
memory is a scarce resource). Its main application is intended to
help extend MS-DOS-based "offline-readers" for RFC 822 and RFC 1036
conformant messages to also support RFC 1521 [obs.] and
RFC 1522 [obs.].
--
B.2) Conversion tools and extension packages
Name: BogoMIME
Proeduct: tool
Platform: Unix
Where: ?
Author: Bryan O'Sullivan <b...@serpentine.com>
Comments:
BogoMIME is a Perl filter that reads in a Sun mailtool-encoded message
and spits out a MIME-encoded message.
Name: emil
Product: tool
Platform: Unix
Where: ftp://ftp.uu.se/pub/unix/networking/mail/emil/
Where: ftp://ftp.sunet.se/pub/unix/mail/emil/
Author: Martin Wendel <mar...@alba.udac.uu.se>
Comments:
[ Martin Wendel <mar...@alba.udac.uu.se> 8-Apr-1994 ]
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 sendmail-5.67b+IDA-1.5
or sendmail-8.6.8, 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.
[ Tony Nugent <T.Nu...@sct.gu.edu.au> 6-Nov-1996 ]
I've had it `plugged into' my /etc/sendmail.cf file to act as a local
delivery agent to convert binhex/base64/printed-quotable into
8bit/rfc822/uuencode, then send it onto /usr/bin/deliver or
/usr/bin/procmail. It works *really* well.
Going in reverse, it can act as a "pre-filter" too. Uuencode whatever
you want to send, then filter it to get it all converted into what
mime type you want. It's very intelligent (and can even act as a
postal agent).
It does take a bit of getting used to and configuring, but once that
hurdle is behind you it works really, really well.
Name: encdec
Product: tool
Platform: ISO C
Where: ftp://ftp.efd.lth.se/pub/mail/encdec.c-1.1.gz
Author: Joergen Haegg <j...@efd.lth.se>
Comments:
encdec is a simple standalone encoder/decoder for base64 and quoted
printable written in ISO C.
Name: Enriched text valider
Product: tool
Platform: Unix (easily portable)
Author: Daniel Glazman
Contact: Daniel....@der.edf.fr
Where: ftp://lara0.exp.edf.fr/pub/MIME/testEnriched.c
[ Daniel Glazman <Daniel....@der.edf.fr> 13-Oct-1994 ]
This tool is a text/enriched valider useable in conjunction with
the 'test' field of a mailcap file (for instance). Written in std C,
its code has been made *very* simple and readable on purpose, even
if it can be optimized.
It detects unbalanced closing tags, illegal tags, tags longer
than 60 chars and <<.
Provided with the standard "as is" copyright notice. /*Enjoy !*/
Name: exmh
Product: MUA
Platform: UNIX
Where: ftp://ftp.sunlabs.com/pub/tcl/exmh/exmh-1.6.5.tar.Z
Author: "Brent Welch" <we...@eng.sun.com>
Contact: "Brent Welch" <we...@eng.sun.com>
Comments:
[ "Larry W. Virden" <lw...@cas.org> 13-Aug-1994 ]
A Tk based UI to MH. Supports nested folders, MIME/metamail.
[ Achim Bohnet <a...@rosat.mpe-garching.mpg.de> 15-May-1995 ]
Exmh supports these features:
- PGP
- xface
- embedded URLs
- glimpse full text search
- extensive user configurability and extensibility
There are three exmh-related mailing lists:
1. For new exmh version announcements, write to:
exmh-annou...@parc.xerox.com
Put this in the body:
subscribe exmh-announce y...@your.host
2. To join the exmh discussion list, write to:
exmh-user...@parc.xerox.com
Put this in the body:
subscribe exmh-users y...@your.host
3. To join the exmh developers list, write to:
exmh-worke...@parc.xerox.com
Put this in the body:
subscribe exmh-workers y...@your.host
For mailing list archives, see ftp://parcftp.xerox.com:/pub/exmh/archive
Files are in MH "packf" format, compressed.
An html-ized archive of the exmh lists and related mailing
lists (mh-users/workers, glimpse) is at
http://www.rosat.mpe-garching.mpg.de/~ach/exmh/archive/
The 3rd Edition of Jerry Peek's "MH & xmh" book from O'Reilly &
Associates includes chapters about exmh.
See also the USENET newsgroup "comp.mail.mh".
[ Sam Nuwayser <s...@suneast.east.sun.com> 17-Jan-1996 ]
The following URL is the correct location to get more
information on exmh:
http://www.smli.com/~bwelch/exmh/index.html
Name: macunpack
Product: utility package
Platform: MS-DOS (?)
Where: ftp://ftp.univie.ac.at/mac/info-mac/cmp
Author:
Comments:
A set of Macintosh utilities for extracting and decoding BinHexed
contents.
[ Mike O'Connor <m...@dojo.mi.org> 7-Sep-1996 ]
You'll want to take a look at macunpack and hexbin, part of the
macutil package available from ftp://ftp.univie.ac.at/mac/info-mac/cmp
among other places.
Name: metamail
Product: MUA and tools
Platform: Unix Amiga MS-DOS
Where: ftp://ftp.bellcore.com/pub/nsb/mm2.7.tar.Z
The metamail distribution that Nathaniel Borenstein supports.
Where: ftp://ftp.bellcore.com/pub/nsb/contrib2.7.tar.Z
Contributed sources.
Where: ftp://ftp.bellcore.com/pub/nsb/mm2.7.dos.zip
MS-DOS binaries
Author: Nathaniel Borenstein
Comments:
[ Paul Eggert <egg...@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 e-mail 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.
[ Nathaniel Borenstein <n...@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.
[ Jerry Sweet <jsw...@irvine.com> 10-Oct-1994 ]
The "richtext" program in the metmail distribution has an
undocumented command line option, "-e", which turns it into a
viewer for text/enriched, the successor to text/richtext.
[ Keith Moore <mo...@cs.utk.edu> 23-May-1997 ]
Metamail advisory from CERT:
ftp://info.cert.org/pub/cert_advisories/CA-97.14.metamail
{ That's a security vulnerability alert. References to sources
for patches to metamail version 2.7 are included. }
Name: Mew (Message interface to Emacs Window)
Product: MUA
Platform: Emacs/Mule/XEmacs
Where: ftp://ftp.csce.kyushu-u.ac.jp/pub/Misc/mew/mew-current.tar.gz
Author: Kazuhiko YAMAMOTO
Comments:
[ Kazuhiko YAMAMOTO <ka...@is.aist-nara.ac.jp> 14-Oct-1994 ]
Mew (Message interface to Emacs Window) is a message interface to
Emacs/Mule that integrates structured message such as MIME, PEM, and
PGP. Mew is now based on MH but will support USENET news soon.
Currently, following features are supported.
* Selective MIME part viewer.
* User friendly MIME composer that maps directory structure to multipart.
* PEM auto decryption and functions for encrypting and signing.
* PGP auto decryption and functions for encrypting and singing.
* LRU message cache engine.
* Only SPC key press interface.
* Asynchronous inc and scan.
* Dynamic window configuration.
* Excellent refile folder guess algorithm.
* Alias completion and expansion.
* Easy pick and scan interface.
* Mark based functions that treats multiple messages(e.g. unshar, uumerge).
You should pronouns "Mew" as it is. Of course, it is meow of cat.
P.S.
You can find PEM/PGP/MIME integration information on 00faq in Mew's
package.
Name: MHonArc
Product: HTML conversion tool
Platform: Unix
Where: http://www.oac.uci.edu/indiv/ehood/mhonarc.html
Author: Earl Hood <eh...@medusa.acs.uci.edu>
[ Earl Hood <eh...@convex.com> 2-Oct-1994 ]
MHonArc is a Perl program for converting e-mail messages as specified
in RFC 822 and RFC 1521 [obs.] (MIME) to HTML. MHonArc can perform the
following tasks:
* Convert mh(1) mail folders or mail(1) style mailboxes into an HTML
mail archive.
* Add new e-mail messages to an existing HTML mail archive generated
by MHonArc.
* Convert a single message to HTML.
An index page is created when an archive is generated. MHonArc allows
complete customization over the appearance of the index page including
the ability to insert user defined HTML markup and content-type
sensitive icons for the mail messages processed.
For details refer to: http://www.oac.uci.edu/indiv/ehood/mhonarc.html
The x-types handled by MHonArc are listed in part 5 of this FAQ.
Name: MIME for VM/CMS
Product: decoder
Platform: VM/CMS
Where: http://ua1vm.ua.edu/~troth/rickvmsw/rickvmsw.html
Author:
Comments:
[ Rick Troth <TR...@ricevm1.rice.edu> 21-Jul-1993 ]
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::Lite
Product: Perl5 modules
Platform: Unix
Where: http://www.enteract.com/~eryq/CPAN/MIME-Lite/
Author: Eryq <er...@enteract.com>
Comments:
Excerpted from the above-mentioned web page:
MIME::Lite is intended as a standalone module for generating (not
parsing!) MIME messages. It allows you to output a simple single or
multi-part message with text or binary attachments. It does not
require that you have the Mail:: or MIME:: modules installed.
Name: MIME-tools
Product: Perl5 modules
Platform: UNIX
Where: ftp://uiarchive.cso.uiuc.edu/pub/lang/perl/CPAN/authors/Eryq/
Where: ftp://ftp.cs.colorado.edu/pub/perl/CPAN/authors/Eryq/
Author: Eryq <er...@enteract.com>
Contact: Eryq <er...@enteract.com>
Contact: Eryq <er...@rhine.gsfc.nasa.gov>
Comments:
[ Eryq <er...@eryq.pr.mcs.net> 15-Nov-1996 ]
A collection of Perl5 modules for parsing/decoding and composing
single- or multipart MIME messages. Currently part of the Mail::
hierarchy, and even tighter integration is planned.
There is a general parser class, MIME::ParserBase, from which
you can inherit to create parsers with customized output
behavior. MIME::Parser is such a subclass, and is included;
it should meet most application's needs.
Parsing a MIME message yields a possible tree-like structure
of MIME::Entity objects; each consists of a MIME::Head (with all
the header information) and a MIME::Body (an abstract container
of data, which might be a scalar for small messages or a file
for large ones).
If you need to support a new encoding type, you can write your
own subclass of MIME::Decoder and install it. All the (currently 5)
standard encodings are supported. MIME::Decoder can also be used
to encode/decode a stream of bytes.
Creating multipart MIME messages is fairly easy; one starts with a
root entity, sets headers, and "attaches" other entities (which you
can give via filename or via the actual body data). There's even
a MIME::Latin1 module which automatically converts Latin-1
characters into reasonably readable 7-bit sequences, if you
want to avoid quoted-printable.
MIME-tools can be downloaded from any CPAN (Comprehensive Perl
Archive Network) mirror site; go to http://www.perl.com/CPAN/
to find the site nearest you. Documentation currently on-line
at http://www.enteract.com/~eryq/CPAN/MIME-tools/
Feel free to contact the author for questions or support.
Name: MIME tools for GNU Emacs
Product: extension package
Platform: Unix
Where: ftp://ftp.kyutech.ac.jp/pub/MultiMedia/mime/emacs-mime-tools.shar
Author: Masanobu UMEDA
Comments:
[ Masanobu UMEDA <ume...@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
Where:
Author: Dave Lacey
Comments:
[ Dave Lacey <da...@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: mpack
Product: MUA/utility
Platform: Unix, MS-DOS, OS/2, Macintosh, Amiga, Archimedes
Contact: mpack...@andrew.cmu.edu
Where: ftp://ftp.andrew.cmu.edu/pub/mpack/mpack-1.5-src.tar.Z
Sources for all versions
Where: ftp://ftp.andrew.cmu.edu/pub/mpack/mpack15d.zip
MS-DOS binaries
Where: ftp://ftp.andrew.cmu.edu/pub/mpack/mpack15o.zip
OS/2 binaries
Where: ftp://ftp.andrew.cmu.edu/pub/mpack/mpack-1.5-mac.hqx
Macintosh binary
Where: ftp://ftp.andrew.cmu.edu/pub/mpack/mpack-1.5-amiga.lha
Amiga binaries
Where: ftp://ftp.andrew.cmu.edu/pub/mpack/mpack-1.5-arc.arc
Archimedes binaries
Where: ftp://ftp.andrew.cmu.edu/pub/mpack/mpack-1.5-linux.tar.gz
Linux binaries
Author: John Gardiner Myers, Chris Newman (Mac), Mike Meyer (Amiga),
Peter Simons (Amiga), Jochen Friedrich (OS/2),
Olly Betts (Archimedes)
Comments:
[ John Gardiner Myers <jg...@cmu.edu> 16-Feb-1995 ]
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. The Macintosh
port can also handle AppleSingle, AppleDouble, and BinHex.
Starting with version 1.5, all official mpack distributions are
PGP signed by "John Gardiner Myers <jg...@cmu.edu>". The PGP
signatures are detached from the distributions themselves, in
files with the ".asc" filename extension.
[ Arjan van der Meer <arja...@htsa.hva.nl> 30-Jan-1995 ]
There is now a version of mpack/munpack for the Atari ST and
compatibles. It is just a compiled version of the UNIX 1.2 version,
but what I've tried worked okay. It is made by al...@hal.rhein-main.de.
MPACK/MUNPACK Atari ST binary -
ftp://ftp.uni-kl.de/pub/atari/misc/mpack_12.lzh
Name: n2m
Product: conversion tool
Platform: NeXT
Where: ftp://nexus.yorku.ca/pub/n2m.shar
Author:
Comments:
[ Dave Collier-Brown <dav...@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: RMIME
Product: extension package
Platform: Unix
Where: http://www.cinti.net:2000/~rmoody/rmime/
Author: Ray Moody <rmo...@cinti.net>
Excerpted from the above-indicated web page:
RMIME provides MIME support for several Emacs message reading
packages. RMIME has been designed with RMAIL in mind, but it has also
been tested with mh-e and VM. It should work with most other major
modes as well.
RMIME requires Emacs version 19.28 or greater. Emacs version 19.29 or
greater is required for full functionality.
Name: Safe-TCL (Enabled Mail)
Product: extension package
Platform: UNIX
Where: ftp://ftp.fv.com/pub/code/other/safe-tcl.tar.gz
Author: Marshall T. Rose, Nathaniel Borenstein
Contact: safe-tcl...@uunet.uu.net
Comments:
[ "Larry W. Virden" <lw...@cas.org> 13-Aug-1994 ]
Incoming email processing tool based on Tcl. Software also available
which can build MIME messages and send them. Incoming email
processing includes ability to execute encapsulated Tcl programs at
delivery or upon viewing.
[ Jerry Sweet <jsw...@irvine.com> 5-Sep-1994 ]
Papers about Enabled Mail and Safe-TCL are available from these
sources:
ftp://ftp.bellcore.com/pub/nsb/st/em-model.txt
ftp://ftp.bellcore.com/pub/nsb/st/safe-tcl.ps
ftp://ftp.bellcore.com/pub/nsb/st/safe-tcl.txt
Name: sd-launch
Product: extension package
Platform:
Where: http://www.cmf.nrl.navy.mil/CCS/people/fenner/dist/sd-launch/
Where: ftp://ee.lbl.gov/conferencing/sd/
Where: ftp://ftp.parc.xerox.com/pub/net-research/
Author:
Contact: fen...@cmf.nrl.navy.mil (William C. Fenner)
Comments:
[ "Larry W. Virden" <lvi...@cas.org> 27-Feb-1995 ]
This is a MIME/WWW browser helper to launch MBONE sessions.
Name: ServiceMail
Product: toolset
Platform: unknown
Where: ftp://eitech.com
Author: Enterprise Integration Technologies Corporation
Contact: servicem...@eitech.com
Comments:
[ Jay C. Weber <we...@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: serv...@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 "servicem...@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 "serv...@eitech.com" with subject
"listserv subscribe pact-kit your-real-name".
Name: sun-to-mime
Product: conversion tool
Platform: OpenWindows
Where: ftp://cs.utk.edu/pub/MIME/sun-to-mime.perl
Where: ftp://cs.utk.edu/pub/MIME/sun-to-mime.c
Author: Keith Moore
Comments:
[ Keith Moore <mo...@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: uudeview
Product: encoder/decoder
Platform: Unix
Where: ftp://ftp.uni-frankfurt.de/pub/dist/frank/uudeview-0.5.9.tar.gz
Author: Frank Pilhofer <f...@informatik.uni-frankfurt.de>
Comments:
[ Tony Nugent <T.Nu...@sct.gu.edu.au> 6-Nov-1996 ]
Description: Smart multi-file multi-part decoder for uuencoded,
xxencoded, Base64 and BinHex encoded files. Also
includes a similarly powerful encoder.
Keywords: uudeview, uuenview, uudecode, decoding, MIME,
xxdecode, uuencode, Base64, BinHex
Name: uu-to-mime
Product: conversion tool
Platform: perl
Where: ftp://cs.utk.edu/pub/MIME/uu-to-mime.perl
Author: Keith Moore <mo...@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.
--
End of Part 6
*************
--
MIME FAQ maintainer
Archive-Name: mail/mime-faq/part7
Version: $Id: mime7,v 3.23 1997/06/11 23:27:11 jsweet Rel $
Posting-Frequency: monthly
--
==========================================================
comp.mail.mime frequently asked questions list (FAQ) (7/9)
==========================================================
Part 7: Freely Available MIME products, section 2
~~~~~~
--
Overview
--------
This is part 7 of a Frequently Asked Questions document about MIME, the
multipurpose and multi-media standard for Internet mail.
The usual disclaimers apply; you know what they are: no
endorsements implied, no warranty, no safety, no nuthin'! :-)
--
B.3) Mail user agents and transport systems
Name: Andrew
Product: Multimedia system
Platform: Unix
Where:
Author:
Comments:
[ Susan Straub <sus...@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-andr...@andrew.cmu.edu.
Name: elm
Product: MUA
Platform: Unix
Where:
Author:
Comments:
[ Syd Weinstein <s...@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 23.
3.x: not planned until some time in 1994.
[ Sven Guckes <guc...@inf.fu-berlin.de> 18-Apr-1995 ]
> 2.4: Current PL is 23.
Make that "PL24".
> 3.x: not planned until some time in 1994.
Make that "1995". Or even "1996".
Name: Eudora 1.4.4
Product: MUA
Platform: Macintosh MS-Windows
Where: ftp://ftp.qualcomm.com/quest/eudora/windows/1.4/eudor144.exe
Where: ftp://ftp.qualcomm.com/quest/eudora/mac/1.4/eudora144.hqx
Where: ftp://src.doc.ic.ac.uk/computing/systems/ibmpc/windows3/winsock/eudora14.exe
Author: Steve Dorner <sdo...@qualcomm.com>
Author: Jeff Beckley <bec...@qualcomm.com> (Windows Version)
Comments:
Eudora 1.4 is a MUA for Macs and PCs that uses POP3 and SMTP and
supports MIME. A commercial version is also available: see the next
section.
[ "Where" info from Lourdes Yero <ly...@dino.conicit.ve> 15-May-1995 ]
Name: HUyMail
Product: MTA/MUA
Platform: VMS
Where: ftp://ftp.technion.ac.il/pub/unsupported/vms/local/local/huymail*.bck
Author: Yehavi Bourvine
Comments:
[ Yehavi Bourvine <YEH...@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
Where: 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: mercurius
Product: MUA
Platform:
Where: ftp://ftp.lii.unitn.it/pub/mercurius/mercurius.tar.Z
Author:
Contact: mercuri...@lii.unitn.it
Comments:
[ "Larry W. Virden" <lw...@cas.org> 13-Aug-1994 ]
Mercurius facilitates composing and reading multimedia electronic
messages compliant with the Multipurpose Internet Mail Extensions
(MIME).
Name: MEUF [Mail Extended Using Faces]
Product: MUA
Platform: Unix/X
Where: ftp://ftp.inria.fr
Where: ftp://ftp.enst.fr
Contact: Daniel....@der.edf.fr
Author: Daniel Glazman
Comments:
[ Daniel Glazman <gla...@cli51ak.der.edf.fr> 23-Sep-1994 ]
Meuf is a student project 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.
Currently developed version 3.0 will be released as a freely
available product as soon as I'll get the authorization. Code has
features:
Pure MUA features:
* Faces (48x48 XBM bitmaps) display using the X-Faces
header field and included logos distribution
* does not rely on "faces" package
* folders (also with Faces display)
* waste basket
* messages sort by date, subject, length, ...
* unlimited aliases
* .face, .signature, .prologue, /usr/games/fortune handling
* automagically deleted messages
* References, Priority, Bcc, Return-Receipt-To handling
* "Trusted Users" features
* ignored header fields
* online help
* drag and drop for messages/folders management
* interactive Face design
* "Properties" windows
MIME features:
* does not rely on "metamail" package
* full MIME composition and restitution for non-textual
parts and text/plain
* multiparts composition and restitution
* basic text/richtext and text/enriched restitution
* mailcap mechanism
* Sun-Attachments parsing
* MIME incorporation
* MIME-clipboard (copy/paste of MIME parts between messages)
* extraction of forwarded MIME-messages for MIME restitution
* User's Guide (PS), Admin. Guide (PS)
Successfully compiled and used with:
Sun SunOs 4.1.x and Solaris 2.x
HP 9000/7xx HP-UX > 9.01
DECstation Ultrix
IBM RS6000 AIX > 3.2.4
Convex
More information at http://lara0.exp.edf.fr/glazman/meuf.html
Availability will be announced in comp.mail.mime newsgroup.
Name: MH 6.8
Product: MUA
Platform: Unix
Where: ftp://ftp.ics.uci.edu/pub/mh/mh-6.8.tar.Z
Where: 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.3. Mhn
does not use the mailcap mechanism described in RFC 1343. Instead,
it has its own flexible extension mechanism, called a profile.
A tutorial for mhn is available here:
ftp://ftp.ics.uci.edu/pub/mh/contrib/multimedia/mhn-tutorial.tex.Z
ftp://ftp.ics.uci.edu/pub/mh/contrib/multimedia/mhn-tutorial.sty.Z
ftp://ftp.ics.uci.edu/pub/mh/contrib/multimedia/mhn-tutorial.ps.Z
See the newsgroup comp.mail.mh for further information.
Name: MIXMH
Product: MUA
Platform: Unix with X
Where: ftp://aun.uninett.no/pub/mail/mixmh/mixmh-0.3.tar.Z
Author:
Comments:
[ Harald Tveit Alvestrand <Harald.A...@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 [obs.]) and the body (per RFC 1341 [obs.] 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...@uninett.no
Information and discussion will take place on mixmh...@uninett.no;
mail to mixmh-inf...@uninett.no to join.
Name: Pegasus mail
Product: MUA
Platform: MS-DOS, MS-Windows, Macintosh
Where: ftp://risc.ua.edu/pub/network/pegasus/*
Author: David Harris <da...@pmail.gen.nz>
Comments:
[ James Ford <JF...@ua1vm.ua.edu> 2-Nov-1993 ]
Pegasus Mail is an E-Mail 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.
[ Henning Stams <hst...@k.mup.de> 21-Nov-1994 ]
MS-DOS-Version currently is 3.22. It's internationalized (German,
Czech, Dutch and many more). Windows-Version is currently 1.22; v2.0
soon to come. Also Mime-compliant MERCURY runs on NW 3.11, 3.12, 4.x
(Currently Bindery Emul. Mode; soon in NDS-Mode). Current Version:
1.13
Name: Pine
Product: MUA
Platform: Unix
Where: ftp://ftp.cac.washington.edu/pine/pine.tar.Z
Author: Laurence Lundblade, Michael Seibel, Mark Crispin
Comments:
[ From the release notes 21-Sep-1993 ]
Pine(tm) --a Program for Internet News & E-Mail-- 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.
[ David L Miller <d...@cac.washington.edu> 31-Aug-1994 ]
For more information, see http://www.cac.washington.edu/pine/
Name: postie
Product: MUA
Platform:
Where: http://www.ozemail.com.au/~adavison/postie.zip
Author:
Contact:
Comments:
[ Andrew Davison <and...@dvp.com.au> 30-Oct-1996 ]
This is source (free, portable) for a command-line mailer that
handles multi-part MIME attachments.
Name: PP
Product: MTA
Platform: UNIX
Where: ftp://ftp.uninett.no
Author:
Contact:
Comments:
PP is an X.400/SMTP mailer and gateway. The last non-commercial
version was PP 6.0 (ca. 1992), which is still available for
downloading from some Internet sites; one is listed above. PP has
since been folded into a commercial software suite from the ISODE
Consortium; see the entry for "ISODE Consortium MTA", in appendix C.
Name: Tkmailto
Product: MUA
Platform: UNIX
Where: ftp://harbor.ecn.purdue.edu/pub/tcl/code/tkmailto-1.0.tar.gz
Author:
Contact: "Johan Lindbladh" <tet...@tintin.hik.se>
Comments:
[ "Larry W. Virden" <lw...@cas.org>, 13-Aug-1994 ]
Alpha version Tk-based mail composer which supports MIME. Requires
Safe-Tcl 1.1.
Name: TkRat
Product: MUA
Platform: UNIX
Where: ftp://ftp.md.chalmers.se/pub/tkrat
Author: Martin Forssen <m...@dtek.chalmers.se>
Contact: http://www.dtek.chalmers.se/~maf/ratatosk
Comments:
[ Martin Forssen <m...@math.chalmers.se> 27-Oct-1996 ]
TkRat is a graphical Mail User Agent (MUA) which handles MIME. It
is mainly written in C but the user interface is done in tcl/tk.
TkRat has a multilingual user interface (currently English,
Swedish and Italian), it can use berkeley UNIX mailboxes as well
as IMAP, POP and mh folders. There is also an internal message
database that can be used to store messages. It also support
Delivery Status Notifications. The user interface is meant to be
easy to use and not use more resources than needed (screen space,
CPU and memory). TkRat should work on any UNIX-system with X11
installed.
Requires tclsh7.5 and wish4.1 or later.
Mailing list: ratatosk...@dtek.chalmers.se
Name: Yet Another Mailer (YAM)
Product: MUA
Platform: Amiga
Where: ftp://ftp.wustl.edu/pub/aminet/comm/mail/YAM*.lha
Where: http://www.usa.aminet.org/aminet/dirs/comm_mail.html
Author: mb...@access.ch (Marcel Beck)
Homepage: http://bitcom.ch/~mbeck/
Comments:
[ Tom Byrer <avi0...@pn.nettuno.it> 1-Mar-1997 ]
FEATURES:
* fast and easy setup (less than 5 minutes)
* hierarchical address book
* built-in POP3 and SMTP clients
* can delete email on mail server without downloading
* internal editor
* supports MIME & UUencode
* text viewer parces "email-markup"; i.e. *bold* is shown bold,
/italic/ italicized, _underlined_, and #coloured#
* background operation
* Rexx-port & commands
* filtering with auto-forwarding, deletion, or move mail to
another folder
* font sensitive, resizable GUI
* extensive online help in English, French, German, and Italian
* contains GUI catalogs for 16 different languages
* Freeware
More features are planned in the coming update, YAM 2.0.
--
B.4) Packages for MIME in USENET
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.
A number of the mail user agents and tools discussed in appendix B.1 also
handle USENET news.
Information for this section about MIME-capable USENET news software
packages may be contributed by anyone. The FAQ maintainers look with
favor on brief entries that are provided in the existing entry format,
but it's fair simply to offer corrections or updated information.
Send new or updated entries to the address "mime...@ics.uci.edu";
posting to comp.mail.mime isn't necessarily sufficient.
Readers should bear in mind that files whose names contain version
numbers are often out of date by the time that you try to find them,
so you may need to poke around in the parent directories to locate the
latest versions.
See also: news:comp.mail.misc - "FAQ: pointer to alt.usenet.offline-reader FAQs"
Name: GNUS
Product: reader
Platform: GNU Emacs
Where:
Author: Masanobu UMEDA
Comments:
[ Masanobu UMEDA <ume...@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 appendix B.3).
Name: gnus-mime.el
Product: reaJoe Ilacqua der
Platform: GNU Emacs
Where: ftp://world.std.com/dist/gnus-mime.el.shar
(also in the contrib tree of metamail)
Author: Joe Ilacqua
Comments:
[ Joe Ilacqua <sp...@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".
{ Gnus-mime.el may be for GNUS prior to version 3.14.4. }
Name: INN
Product: transport
Platform:
Where:
Author:
Comments:
[ Christopher Davis <c...@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...@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:
Where: See appendix B.1 for MH's FTP sites.
Author:
Comments:
[ John Romine <jro...@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: mhunify (aka stacknews)
Product: reader
Platform: UNIX
Where: ftp://ftp.ics.uci.edu/pub/mh/contrib/multimedia/mhunify.shar.gz
Author: Jerry Sweet <jsw...@irvine.com>
Comments:
[ Jerry Sweet <jsw...@irvine.com> 11-Aug-1994 ]
Mhunify is a set of perl scripts and templates that provides
shell-level MH functionality with USENET news. Since MH supports
MIME, MIME-format news articles just work. I've found that being
able to handle news in the same way that I handle e-mail is very
useful, although there are some tradeoffs: no kill files, no
threads, at least for now.
Mhunify also treats MH folders just like news groups. If you
subscribe to several mailing lists, and your e-mail is
automatically delivered to separate folders, say, via procmail
or via MMDF's .maildelivery, the mhunify package lets you progress
automatically through your folders just as you would news groups.
Requirements:
- csh or some shell with shell-level alias or procedure
facilities;
- perl 4.0 or later;
- MH 6.8 or later;
- direct file system access to the USENET news spool
directory (typically /usr/spool/news - as a local or NFS
mounted file system).
Some of the goodies:
stacknews - read USENET news using shell-level MH.
ncomp, nrepl, nforw
- compose, reply to, and forward to USENET
news groups (these use nwhatnow).
nwhatnow - post USENET articles & send e-mail from
the same draft.
consider - creates a folder, +consider by default,
containing specified messages.
bburst - bursts digests into a writeable folder,
+consider by default.
clearf - clears the MH folder stack.
mhpped - utility composition template pre-processor.
pscan - scan messages from point of previous scan.
Plus man pages, templates, example configuration files,
other utility programs, and a Makefile to install everything.
Name: nn
Product: reader
Platform:
Where:
Author:
Comments:
[ Luc Rooijakkers <l...@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
Where: ftp://ftp.wimsey.com/~ftp/pub/msdos/uupc/snews191.zip
MS-DOS binaries
Where: ftp://ftp.wimsey.com/~ftp/pub/msdos/uupc/snws191o.zip
OS/2 binaries
Where: ftp://ftp.wimsey.com/~ftp/pub/msdos/uupc/snws191s.zip
Source
Author:
Comments:
[ Daniel Fandrich <d...@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 [obs.] and RFC 1522 [obs.])
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: strn
Product: reader
Platform: UNIX
Where: ftp://ftp.uu.net/networking/news/readers/trn/strn/strn092.tar.gz
Author: Clifford A Adams <caa...@access.digex.net>
Comments:
Strn has support for reading and creating MIME articles.
Name: trn
Product: reader
Platform: UNIX
Where: ftp://ftp.uu.net/networking/news/readers/trn/trn.tar.gz
Author: Wayne Davison <dav...@borland.com>
Comments:
trn 3.0 has support for reading MIME articles with metamail, and
creating them with mhn.
--
End of Part 7
*************
--
MIME FAQ maintainer
Archive-Name: mail/mime-faq/part4
Version: $Id: mime4,v 3.23 1997/06/11 23:27:11 jsweet Rel $
Posting-Frequency: monthly
--
==========================================================
comp.mail.mime frequently asked questions list (FAQ) (4/9)
==========================================================
Part 4: Appendix A(1): Pointers to MIME specifications
~~~~~~
--
Overview
--------
This is part 4 of a Frequently Asked Questions document about MIME,
the multipurpose and multi-media standard for Internet mail.
The table of contents is in part 1.
--
A) Pointers to MIME specifications
--
A.1) MIME-relevant RFCs, drafts, and standards
The RFCs mentioned here are mainly relevant to persons 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.
RFCs are available by anonymous FTP from any decent archive site. If
you're really stuck, try these URLs:
http://www.internic.net/ds/rfc-index.html
ftp://ds.internic.net/rfc/
Additionally, RFCs may be requested from a mail-based archive server
by sending a message to "mail...@ds.internic.net". In the body of
the message, include one of the following commands:
document-by-name rfcNNNN
document-by-name rfcNNNN.ps
document-by-name rfc-index
where NNNN is the number of an RFC to retrieve. Not all RFCs are
available in PostScript (.ps) format. Retrieve the rfc-index to find
out what's available.
MIME is primarily defined in these RFCs:
RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One:
Format of Internet Message Bodies
RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two:
Media Types
RFC 2047: MIME (Multipurpose Internet Mail Extensions) Part Three:
Message Header Extensions for Non-ASCII Text
RFC 2048: Multipurpose Internet Mail Extensions (MIME) Part Four:
Registration Procedures
RFC 2049: Multipurpose Internet Mail Extensions (MIME) Part Five:
Conformance Criteria and Examples
{ At the time of this writing (mid-January, 1997), the rfc-index was
missing a reference for at least one of the MIME RFCs, and the
rfc-index didn't have completely up-to-date obsolescence indicators.
But the rfc-index is usually pretty reliable. }
There are many other MIME-related RFCs and drafts in progress. For a
quick overview of current Internet drafts, check out these URLs:
http://www.ietf.cnri.reston.va.us/1id-abstracts.html
ftp://ds.internic.net/internet-drafts/1id-index.txt
ftp://ftp.isi.edu/internet-drafts/
The MIME RFCs are Internet standards-track protocols. For the full
implications of this, see RFC 1920 (Internet Official Protocol
Standards).
Many other RFCs deal with e-mail, including these:
Selected IAB standards or standards-track RFCs
RFC 2142 Mailbox Names for Common Services, Roles and Functions
RFC 2112 The MIME Multipart/Related Content-type
RFC 2111 Content-ID and Message-ID Uniform Resource Locators
RFC 2110 MIME E-mail Encapsulation of Aggregate Documents,
such as HTML (MHTML)
RFC 2077 The Model Primary Content Type for Multipurpose Internet
Mail Extensions
RFC 2060 Internet Message Access Protocol - Version 4
RFC 2034 SMTP Service Extension for Returning Enhanced Error Codes
RFC 2017 Definition of the URL MIME External-Body Access-Type
RFC 2015 MIME Security with Pretty Good Privacy (PGP)
RFC 1985 SMTP Service Extension for Remote Message Queue Starting
RFC 1939 Post Office Protocol - Version 3
RFC 1894 An Extensible Message Format for Delivery Status Notifications
RFC 1893 Enhanced Mail System Status Codes
RFC 1892 The Multipart/Report Content Type for the Reporting of Mail
System Administrative Messages
RFC 1891 SMTP Service Extension for Delivery Status Notifications
RFC 1870 SMTP Service Extension for Message Size Declaration
RFC 1869 SMTP Service Extensions
RFC 1866 Hypertext Markup Language - 2.0
RFC 1864 The Content-MD5 Header Field
RFC 1848 MIME Object Security Services
RFC 1847 Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted
RFC 1767 MIME Encapsulation of EDI Objects
RFC 1740 MIME Encapsulation of Macintosh files - MacMIME
RFC 1734 POP3 AUTHentication command
RFC 1731 IMAP4 Authentication mechanisms
RFC 1700 Assigned Numbers { Way more than the title implies. }
RFC 1652 SMTP Service Extension for 8bit-MIMEtransport
RFC 1502 X.400 Use of Extended Character Sets
RFC 1496 Rules for Downgrading Messages from X.400(88) to X.400(84)
when MIME Content-Types are Present in the Messages
RFC 1495 Mapping between X.400 and RFC-822 Message Bodies
RFC 1494 Equivalences between 1988 X.400 and RFC-922 Message Bodies
RFC 1424 Privacy Enhancement for Internet Electronic Mail: Part IV
RFC 1423 Privacy Enhancement for Internet Electronic Mail: Part III
RFC 1422 Privacy Enhancement for Internet Electronic Mail: Part II
RFC 1421 Privacy Enhancement for Internet Electronic Mail: Part I
RFC 1327 Mapping between X.400(1988)/ISO 10021 and RFC 822
RFC 1314 File format for the exchange of images in the Internet
RFC 1123 Requirements for Internet hosts - application and support
Other selected RFCs (Informational, Experimental, or Historical)
RFC 2152 A Mail-Safe Transformation Format of Unicode
RFC 2076 Common Internet Message Headers
RFC 1991 PGP Message Exchange Formats
RFC 1945 Hypertext Transfer Protocol -- HTTP/1.0
RFC 1922 Chinese Character Encoding for Internet Messages
RFC 1911 Voice Profile for Internet Mail
RFC 1896 The text/enriched MIME Content-type
RFC 1895 The Application/CALS-1840 Content Type
RFC 1874 SGML Media Types
RFC 1873 Message/External-Body Content-ID Access Type
RFC 1867 Form-based File Upload in HTML
RFC 1844 Multimedia E-mail (MIME) User Agent checklist
RFC 1838 Use of the X.500 Directory to support mapping between
X.400 and RFC 822 Addresses
RFC 1830 SMTP Service Extensions for Transmission of Large
and Binary MIME Messages
RFC 1815 Character Sets ISO-10646 and ISO-10646-J-1
RFC 1806 Communicating Presentation Information in
Internet Messages: The Content-Disposition Header
RFC 1741 MIME Content Type for BinHex Encoded Files
RFC 1733 Distributed Electronic Mail Models in IMAP4
RFC 1732 IMAP4 Compatibility With IMAP2 and IMAP2bis
RFC 1641 Using Unicode with MIME
RFC 1557 Korean Character Encoding for Internet Messages
RFC 1556 Handling of Bi-directional Texts in MIME
RFC 1555 Hebrew Character Encoding for Internet Messages
RFC 1524 A User Agent Configuration Mechanism For Multimedia
Mail Format Information
RFC 1506 A tutorial on gatewaying between X.400 and Internet mail
RFC 1505 Encoding Header Field for Internet Messages
RFC 1489 Registration of a Cyrillic Character Set
RFC 1468 Japanese Character Encoding for Internet Messages
RFC 1456 Conventions for Encoding the Vietnamese Language
RFC 1428 Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME
RFC 1357 Format for emailing bibliographic records
RFC 1345 Character Mnemonics & Character Sets
RFC 1344 Implications of MIME for Internet mail gateways
RFC 1339 Remote mail checking protocol
RFC 1321 MD5 Message-Digest algorithm
RFC 1211 Problems with the maintenance of large mailing lists
RFC 1197 Using ODA for translating multimedia information
RFC 1176 Interactive Mail Access Protocol: Version 2
RFC 1153 Digest message format
RFC 1036 Standard for interchange of USENET messages
RFC 0934 Proposed standard for message encapsulation
RFC 0822 Standard for the format of ARPA Internet text messages
RFC 0821 Simple Mail Transfer Protocol
RFC 0807 Multimedia mail meeting notes
Overtly Silly RFCs
RFC 1927 Suggested Additional MIME Types for Associating Documents
RFC 1437 The Extension of MIME Content-Types to a New Medium
--
A.2) MIME types
There are registered and unregistered MIME types. Unregistered MIME
types begin with an "x-" and their meanings generally depend on
private agreements between senders and receivers. This section lists
registered types and some known unregistered types.
--
A.2.1) List of registered MIME types
The latest list of registered MIME types is available from the ISI
media-types file at this URL:
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/media-types
The media-types file also lists character sets registered for use with
MIME, access types for external-body contents, content-transfer-encodings,
and MIME/X.400 mapping tables.
The list of media types below is taken from the January, 1997 version
of the aforementioned ISI media-types file. The list isn't guaranteed
to be up-to-the-minute.
Some types, although described in RFCs, are either not officially
registered, or may never have been submitted for registration. If
such types are not listed in the ISI media-types file, they are not
included here with the registered types, and may instead be listed in
appendix A.2.2, the list of unregistered MIME types.
Subtypes exist whose names begin with "vnd.". The "vnd" prefix, which
stands for "vendor", is part of a hierarchical name space specified in
RFC 2048.
As noted in RFC 2048, "...the registration of a data type does not
imply endorsement, approval, or recommendation by IANA or IETF or even
certification that the specification is adequate." Accordingly, the
descriptions of some registered types listed in the ISI media-types
files may refer to materials available only from off-line commercial
sources, or refer to individuals rather than documents. In such
cases, a little more digging, or even reverse-engineering, may be
required to obtain details on the media-types of interest. You may
find that some of the ISI media-types files are somewhat outdated,
particularly if they still refer to RFC 1341 (obs.), RFC 1521 (obs.),
or RFC 1522 (obs.).
{ If you know of an especially useful or definitive URL for any
particular registered or unregistered type, please drop a note to the
MIME FAQ maintainers. }
{ Also, if you know of a bit of software, commercial or otherwise,
that decodes or displays a given type, please drop a note to the MIME
FAQ maintainers. URLs that are known to work for the public are
especially appreciated. }
Application types
-----------------
There are two application types pre-defined in RFC 2046:
type: application/octet-stream
see: RFC 2046
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/octet-stream
comment: As a catch-all type, this is the most widely abused MIME content-type.
type: application/postscript
see: RFC 2046
see: news:comp.lang.postscript
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/postscript
comment: Only PostScript levels 1 and 2 are permitted according to
RFC 2046. PostScript level 3 was announced by Adobe in September,
1996, but there is presently no type registered for level 3.
Application types associated with RFCs are as follows:
type: application/applefile
see: RFC 1740
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/applefile
type: application/cals-1840
see: RFC 1895
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/cals-1840
type: application/cybercash
see: RFC 1898
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/cybercash
type: application/iges
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/iges
see: RFC 2077
type: application/oda
see: RFC 1494
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/oda
type: application/pgp-encrypted
see: RFC 2015
type: application/pgp-signature
see: RFC 2015
type: application/pgp-keys
see: RFC 2015
type: application/remote-printing
see: RFC 1528
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/remote-printing
type: application/sgml
see: RFC 1874
type: application/vemmi
see: RFC 2122
type: application/x400-bp
see: RFC 1494
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/x400-bp
For general information about top-level application types, refer to
this URL:
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/
Here is a list of non-vendor-defined top-level application types that
aren't specified by RFCs (all grandfathered in):
application/activemessage
application/andrew-inset
application/atomicmail
application/mac-binhex40
application/news-message-id
application/news-transmission
application/sgml-open-catalog
application/slate
application/wita
application/zip
For general information about "vnd" (vendor-defined) application
types, refer also to this URL:
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/
While some vendor-defined application types have been grandfathered
into the top-level, this doesn't preclude later registration into
the "vnd" subtree.
Here is a partial list of vendor-defined application types whose names
were selected before the current 3-plus level "vnd.provider.type"
naming scheme arrived.
application/macwriteii
application/mathematica
application/msword
application/pdf
application/rtf
application/vnd.framemaker
application/vnd.mif
application/vnd.ms-excel
application/vnd.ms-powerpoint
application/vnd.ms-project
application/vnd.ms-tnef
application/vnd.ms-works
application/wordperfect5.1
There are many, many application types registered in the "vnd"
subtree, and the list is growing every day. Check the media-types
file for a more complete list.
Refer to section 3.9 of this FAQ for information about registering
your own type.
Here are some other notes and pointers to information about a few
vendor-defined types:
{ Again, please feel free to let us know about especially useful URLs
for any particular type. Examples: specifications, tutorials, or
freely available software for decoding or displaying. }
type: application/rtf
see: ftp://indri.primate.wisc.edu/pub/RTF/RTF-Spec.rtf
see: ftp://indri.primate.wisc.edu/pub/RTF/RTF-Spec.hqx
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/rtf
type: application/vnd.ms-tnef
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/vnd.ms-tnef
comment:
[ Carl S. Gutekunst <c...@clavinova.eng.sun.com> 14-Mar-1996 ]
TNEF (Transport Neutral Encapsulation Format) contains a serialization
of an entire Microsoft MAPI message. It is not an encoding format
like uuencode is.
[ Carl S. Gutekunst <c...@clavinova.eng.sun.com> 18-Jun-1996 ]
There is enough information in the Microsoft TNEF SDK
documentation to at least partially clone TNEF for use in
non-Microsoft mail clients.
[ Tony Hansen <han...@pegasus.att.com> 10-Mar-1997 ]
As "Inside MAPI" (De la Cruz & Thaler, 1996, Microsoft Press) puts
it (p. 255):
"Any system that is capable of sending a binary file or a text message
with one or more attachments can transmit MAPI messages containing OLE
objects, named properties, rich text, attachments, and embedded
messages. TNEF handles the sundry details of encoding and decoding
these objects, ..."
Of course, as Keith Moore points out, if the message contains an OLE
(Active/X) object with a virus, and you're using a tnef-capable
mailer, you're screwed if your tnef-capable mailer automatically
invokes the OLE object. But this is more of an argument against the
use of any tnef-capable mailer and the automatic invocation of
attachments and embedded objects.
The best solution all around is to convince your correspondents to
turn off sending tnef.
--
The list of registered media types continues in the next section of
the MIME FAQ.
End of Part 4
*************
--
MIME FAQ maintainer
Archive-Name: mail/mime-faq/part2
Version: $Id: mime2,v 3.23 1997/06/11 23:27:11 jsweet Rel $
Posting-Frequency: monthly
--
==========================================================
comp.mail.mime frequently asked questions list (FAQ) (2/9)
==========================================================
Part 2: MIME End-User topics
~~~~~~
--
Overview
--------
This is part 2 of a Frequently Asked Questions document about MIME, the
multipurpose and multi-media standard for Internet mail.
The table of contents is in part 1.
--
2) MIME End-User topics
--
2.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 appendices B and C of this FAQ.
--
2.2) MIME features that may or may not be present
An implementation of multi-media e-mail need not support the full
spec; it's possible to have a useful product that does not explore all
of the nooks and crannies of the standard.
Furthermore, MIME permits a message to contain alternative parts for
consumption by sites that can't necessarily display or listen to all
the good stuff.
Here is a list of features that someone with a good, functional
mail user agent might include for MIME support.
- Displays GIF, JPEG, and PBM encoded images, using e.g. 'xv' in the X
Window System, or (name of windows program here) in Microsoft Windows.
- Displays PostScript parts, using e.g. something that prints to a
PostScript printer, or that invokes GhostScript on an X Window System
display, or that uses Display PostScript.
- Obtains external body parts via Internet FTP or via mail server.
- Plays audio parts on workstations that support digital audio.
On the other hand, the minimal requirements for a MIME-conformant MUA
are almost trivial, yet still provide increased functionality. (The
minimal requirements are mainly concerned with ensuring that users are
not shown raw data from a MIME message inappropriately.)
See also:
- RFC 1844, the "Multimedia E-mail (MIME) User Agent Checklist",
by Erik Huizer.
--
2.3) Why does MIME define base64 instead of using uuencode?
[ Ed Greshko <egre...@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 <jg...@CMU.EDU> 1-Jun-1994 ]
Some gateways damage messages in the more common uuencode formats.
Gateways that convert between EBCDIC and ASCII, in particular, tend to
damage some of the characters used in the uuencode format. The base64
encoding is designed to be invulnerable to all known gateways.
[ Ned Freed <N...@innosoft.com> 26-Oct-1994 ]
Well, once you say UUENCODE you've already bought into a whole bunch
of different formats. There are lots of different encoders out there
that produce completely different variants of UUENCODE. (I just ran
into a new one I had never seen before yesterday, and it happens to be
one I know won't work with some of the decoders I've used.) And
sometimes they interoperate and sometimes they don't.
Because of the lack of a standard version of UUENCODE and the
resulting interoperability problems, as well as various problems with
the encoding character set used by some UUENCODE implementations, MIME
elected to go with an existing encoding originally defined, if memory
serves, in RFC989 back in 1987, as well as adding a new "lightweight"
encoding mechanism for material that's mostly text.
I should also point out that most MIME-ware supports UUENCODE as a
format even if though it is nonstandard and causes interoperability
problems.
There are a bunch of other encodings in use, like base85, btoa, and
hexadecimal. However, you really don't see these that often in
practice.
[ Dave Collier-Brown <dav...@cs.yorku.ca> 1-Feb-1996 ]
If you have to deal with IBM VM/DOS/VSE/MVS or AS/400 systems, you can
look forward to having to ``reconstruct'' uuencoded messages... because
trailing spaces get transformed to nothingness, and occasionally
printing characters get transformed to the equivalent in a different
``print train'' (Yes, Virginia, IBM mainframes still think of
character sets in terms of printer chains).
[ Ned Freed <N...@innosoft.com> 2-Feb-1996 ]
There are plenty of UUDECODE variants that silently drop grave accents
or do horrible things with them. I've seen UUDECODE variants on PC,
VMS, and UNIX systems that have problems in this area.
Another closely related problem is failure to treat lines whose
lengths don't correspond to their length character as being padded out
with spaces that have presumably been lost in transit. Very few of the
UUDECODE sources I have seen get this one right.
Often as not two characters in the UUENCODE repetoire get mapped
onto one. This, of course, is noninvertible.
{ Additional information, horror stories, etc., welcome. }
--
2.4) 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 <n...@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.
--
2.5) Does Microsoft Mail support MIME?
The short answer is "almost--maybe". For example, as of 23 June 1996,
broken base64-like encodings were being created with software that
identified itself as Microsoft Internet Mail 4.70.1080. Earlier
versions may or may not identify themselves. Different versions
apparently have various broken behaviors with respect to MIME.
Subsequent releases might eventually support MIME correctly.
There are various third-party gateways for MS Mail that claim to
support MIME.
Here are some other comments:
[ Carl S. Gutekunst <c...@clavinova.eng.sun.com> 27-Aug-1996 ]
Microsoft has at least five different products that handle Internet
Mail:
* SMTP Gateway for Microsoft Mail. (Option for Microsoft Mail
V3. Does not support MIME.)
* The MSN online service. (Does not support MIME)
* Microsoft Exchange Client. (Bundled with Windows95. Supports MIME,
but puts odd things in text/plain. Does proper Content-Types through
the Win95 file types menu.)
* Microsoft Exchange Server Internet Connector. (Optional Gateway for
Exchange Server. Supports MIME, but has its own set of oddities, the
most notorious of which is the application/ms-tnef attachment that
graces almost every message. Does not wrap long lines in text/plain,
either. Has its own private table for mapping content types.)
* Microsoft Internet Mail. (Bundled with Internet Explorer
3.0. Supports MIME and HTML, but attaches *everything* as
octet-stream, even very well known types like image/jpeg.)
[ Ned Freed <n...@sigurd.innosoft.com> 19-Feb-1996 ]
You have to be careful when you talk about MS Mail, because it is lots
of different things. There's the "classic" MS Mail, there's MS
Exchange, there's MS Mail on Mac (now owned by Star*9, I believe), and
there may well be others I have not heard about.
All of them use proprietary formats internally. Classic MS Mail uses
RFC 1154 [obs.] formats rather than MIME when talking to the Internet.
MS Exchange uses MIME, but its usage of MIME is, shall we say,
peculiar. And MS Mail on the Mac can do MIME when talking to the
Internet, and its MIME support is pretty good.
[ Carl S. Gutekunst <c...@clavinova.eng.sun.com> 20-Feb-1996 ]
As Ned noted, the MS Mail SMTP Gateway uses a variant of RFC 1154 [obs.],
a precursor of MIME that had similar intent.
The real rub with all pre-MIME Internet mail attachment models
[is that] they just didn't interoperate.
All current Microsoft Internet connectivity products are MIME
compliant, although somewhat eccentric in their behavior. Oddly
enough, the eccentric behavior is not because of Microsoft's alleged
goal to dominate the Internet with quasi-proprietary protocols, nor is
it out of ignorance. It's just a matter of finite resources and tight
delivery schedules. Surprise.
[ Steinar Bang <s...@metis.no> 19-Feb-1996 ]
>>>>> "APS" == "Andre P Stewart" <aste...@hp43326.mdc.com> writes:
APS> Microsoft Exchange is the MUA that Microsoft currently produces
APS> and supports. It is shipped with Windows95 and has clients for
APS> both Windows for Workgroups and Windows NT. Soon, a Macintosh
APS> version will be available.
From a MIME point of view it has two major annoying mis-features:
1. Its composer doesn't do line breaks. When text/plain message
parts hit the SMTP gateway, it sees lines longer than 76
characters, and encodes the message in Q-P [Quoted-Printable].
When this message is received by a MUA that doesn't understand
MIME, the message is full of ugly "=" characters.
When this message is received by a MIME-compliant MUA, the Q-P is
decoded, and paragraphs show up as very long lines.
Basically, it's ruined unless the recipient is another MSE user.
2. It gives all attachments the MIME type application/octet-stream,
and uses file name extensions to infer the type.
In addition it quotes the real name of an email address with '
which is illegal in internet email addresses, so that it has to
be quoted with ". This means that messages sent to me from MSE
have the address: "'Steinar Bang'" <s...@metis.no>.
[ Ned Freed <Ned....@innosoft.com> 23-Jun-1996 ]
Another problem with Exchange's use of quoted-printable has surfaced
recently at at least one site -- generation of illegal quoted-
printable encodings. Specifically, the site reported that Exchange
generates =0A instead of a proper hard line break per the MIME
specifications.
There now seem to be all sorts of different versions of Exchange out
there doing different things. I have yet, however, to see firsthand
one that works properly.
[ Steinar Bang <s...@metis.no> 20-Sep-1996 ]
Today I've received email from a MUA that identifies itself as
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version
4.0.837.3.
Mail from this MUA has the following properties:
1. sensible line breaks in text/plain
2. MIME types on attachments (ie. not everything as
application/octet-stream).
I've received attachments with the types
image/gif
and
application/msword
I don't think the latter one was the registered MIME type for
MSWord, the last time I looked. But it is in any case a big
improvement from application/octet-stream.
Also, it still quotes real names in single quotes, but that's an
SMTP and RFC822 problem. Not really MIME related.
See also appendix section A.2.1 in this FAQ for a discussion of
Microsoft TNEF.
--
2.6) What do I do with binhex-ed mail?
This isn't a MIME-related problem per se, but here are some possible
solutions:
[ Jim Kramer <king...@eclipse.net> 22-Feb-1996 ]
I encode binhex manually on the Macintosh and send to
MS-Windows users. They decode using Stuffit Extractor
(freeware).
[ Chris Newman <chr...@CMU.EDU> 11-Apr-1996 ]
cha...@ms.uky.edu writes:
> I need to be able to un-BinHex MIME mail sent from various
> packages that assume everyone in the worl has an unbinhexer.
> The most common form is a Mac Binhex (it may be the only
> kind?) and I see binhexing from Eudora-based mailers.
Binhex is designed to encode Macintosh files. If someone
sends you a binhex file and you don't have a Macintosh, tell
them to use standard MIME/base64 or MacMIME (Eudora's
nonstandard default configuration can be fixed easily in the
preferences). It is possible to write a program which
extracts the portion of the binhex file which is likely to be
usable on non-Macintosh computers, and I've got sample source
if you wish.
A quick look at RFC 1740 & RFC 1741 will show that use of
binhex in Internet email is generally discouraged.
[ Tim Simpson <t...@cddc.demon.co.uk> 12-Apr-1996 ]
Try emil, available from:
ftp://ftp.uu.se/pub/unix/networking/mail/emil
{ See also appendix B of the MIME FAQ. }
[ Mark Johnson <ma...@msn.ustc.vlsi.com> 11-Apr-1996 ]
Look for the program mcvert.
{ Use "archie" to locate the various versions of this
program available via anonymous FTP. }
--
2.7) Can I do MIME on a (pick one) PC/Macintosh/Envoy/Whatever?
See section 1.2.
--
2.8) MIME support in commercial mail services
{ There's lots missing here, and some of this information is aging. If
anyone has updated information about any of the various mail service
providers listed here, or any others, then send 'em to the MIME FAQ
Maintainer address <mime...@ics.uci.edu>. }
America Online
[ Jay Levitt <J...@aol.com> 06-Dec-1996 ]
AOL's native mail system supports a message with text up to 32K, and
one attachment up to 16MB. We like to leave room for people to
forward and add comments, so we consider "long text" to be anything
longer than 25K.
When incoming mail has short text plus a single MIME body part, AOL
will decode that part and show it to you as an attachment.
If incoming mail has long text, the entire message is shown to you as
a text attachment. The first 2K is shown in the message text, so you
can decide if you want to download the rest. (This is especially
useful for message digests.)
If incoming mail has more than one non-text body part, or long text
plus any non-text body parts, we have no way to fit that message into
the normal AOL schema. To avoid data loss, we take the entire
original MIME message and show it to you as an attachment. There are
many programs that can interpret MIME messages and display them.
Future versions of the AOL software will support multiple attachments
and arbitrary-length text, so this situation is only temporary. We
also plan to support access to the AOL mail system via POP3/IMAP,
allowing you to use the MIME client of your choice.
Send inquiries to postm...@aol.com. For AOL members, keyword
MAIL CENTER is a great resource.
[ Hudson Barton <hh...@mail.expand.com> 28-Nov-1996 ]
[When sending] to AOL, you must not send multipart attachments.
Compress them into a single archive. Then encode them with MIME
only. Do not binhex or uuencode.
[When sending] from AOL [to a Macintosh running Eudora] you must
again not send multipart attachments. So compress your attachments
into a single folder (with a separate compression program like
Stuffit), then binhex, then attach. When compressing, don't use
executable files like "sea" because you will often lose the
resource fork; use a "sit" file.
AT&T MAIL
[ Tony Hansen <to...@attmail.com> 6-Jan-1996 ]
The AT&T Mail SMTP gateway to the Internet fully converts between its
internal format and MIME. That is, all mail going out the SMTP gateway
should be fully MIME compliant. All mail coming in through the SMTP
gateway into AT&T Mail is converted into its internal format. Research
and development is continually improving the interaction between AT&T
Mail and the Internet standards. This includes improving the MIME-MHS
interaction. Thus, all X.400 mail that goes to the internet will
increasingly follow the internet standards on X.400 connectivity.
Send inquiries to att...@attmail.com.
CompuServe
[ Pat Farrell <pfar...@netcom.com> 31-Dec-1993 ]
CompuServe's main mail service is ASCII text based, and is not MIME
compliant. CompuServe provides robust, reliable mail transport of
binary files. CompuServe invented and copyrighted the GIF format
which is supported by MIME. There are commercial and freeware client
programs for Macs and PCs that can provide "user friendly" access to
CompuServe's text and binary mail services, display GIF files, and
interact with CompuServe's forums. (CompuServe forums are roughly
equivalent to USENET newsfeeds.)
RadioMail
[ Jerry Sweet <jsw...@irvine.com> 21-Mar-1994 ]
RadioMail Corp. (formerly Anterior Technology) operates two types
of e-mail services having these statuses with respect to MIME:
1. cc:Mail/Internet gatewaying. cc:Mail does permit binary
attachments of various types, and these attachments are encoded by
the gateway for transfer via SMTP, but the encoding is not presently
MIME-compliant. This may change.
2. Wireless e-mail gatewaying. Because the RadioMail gateway passes
a limited set of headers, MIME messages per se do not traverse
the gateway intact. 7-bit-encoded MIME messages may traverse the
gateway if encapsulated, e.g. using RFC 934. However, RadioMail
does not presently supply MIME-compliant user agents for use on
radio modem equipped MS-DOS and Macintosh computers. This will
change.
[ Mark Lovell <mlo...@radiomail.net> 4-Jan-1995 ]
The clients for both the Marco and the Envoy support a subset of MIME.
They only support body-part types that they understand, since there is
not a traditional OS on either unit. RadioMail has established a full
set of MIME interface specifications, and future clients will be built
to support them.
--
End of Part 2
*************
--