[Vorherige]
[Nächste]
[Index]
comp.mail.mime FAQ, part 2 of 9 (frequently asked questions list)
- Subject: comp.mail.mime FAQ, part 2 of 9 (frequently asked questions list)
- From: mime-faq@ics.uci.edu (MIME FAQ maintainer)
- Date: 8 Aug 1997 06:30:11 GMT
- Newsgroups: comp.mail.mime, comp.answers, news.answers
- Summary: This posting contains answers to some of the Frequently Asked Questions about MIME (Multipurpose Internet Mail Extensions). Please read it before posting a question to comp.mail.mime.
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 <egreshko@cosmo.twntpe.cdc.com> 15-Apr-1994 ]
The *major* reason is that there is no standard for uuencode. While
it is popular, the many flavors of uuencode in existence make it a
prime candidate for *non*-interoperability.
[ John Gardiner Myers <jgm+@CMU.EDU> 1-Jun-1994 ]
Some gateways damage messages in the more common uuencode formats.
Gateways that convert between EBCDIC and ASCII, in particular, tend to
damage some of the characters used in the uuencode format. The base64
encoding is designed to be invulnerable to all known gateways.
[ Ned Freed <NED@innosoft.com> 26-Oct-1994 ]
Well, once you say UUENCODE you've already bought into a whole bunch
of different formats. There are lots of different encoders out there
that produce completely different variants of UUENCODE. (I just ran
into a new one I had never seen before yesterday, and it happens to be
one I know won't work with some of the decoders I've used.) And
sometimes they interoperate and sometimes they don't.
Because of the lack of a standard version of UUENCODE and the
resulting interoperability problems, as well as various problems with
the encoding character set used by some UUENCODE implementations, MIME
elected to go with an existing encoding originally defined, if memory
serves, in RFC989 back in 1987, as well as adding a new "lightweight"
encoding mechanism for material that's mostly text.
I should also point out that most MIME-ware supports UUENCODE as a
format even if though it is nonstandard and causes interoperability
problems.
There are a bunch of other encodings in use, like base85, btoa, and
hexadecimal. However, you really don't see these that often in
practice.
[ Dave Collier-Brown <davecb@cs.yorku.ca> 1-Feb-1996 ]
If you have to deal with IBM VM/DOS/VSE/MVS or AS/400 systems, you can
look forward to having to ``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 <NED@innosoft.com> 2-Feb-1996 ]
There are plenty of UUDECODE variants that silently drop grave accents
or do horrible things with them. I've seen UUDECODE variants on PC,
VMS, and UNIX systems that have problems in this area.
Another closely related problem is failure to treat lines whose
lengths don't correspond to their length character as being padded out
with spaces that have presumably been lost in transit. Very few of the
UUDECODE sources I have seen get this one right.
Often as not two characters in the UUENCODE repetoire get mapped
onto one. This, of course, is noninvertible.
{ Additional information, horror stories, etc., welcome. }
--
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 <nsb@thumper.bellcore.com> 4-Nov-93 ]
I recently convinced myself that you can use multipart/alternative
to get a nice effect for both MIME-smart recipients and
uuencode-loving recipients, although it is ugly and wasteful:
Content-type: multipart/alternative; boundary=foo
--foo
Content-type: application/octet-stream; name=foo.uu
...uuencoded data goes here....
--foo
Content-type: real-mime-type
Content-type: base64
base64-encoded data goes here
--foo--
A good MIME viewer will only use the second part, the real MIME
data. A uuencode-oriented system, however, should ignore everything
EXCEPT the uuencoded data, because of the way uuencode works
(everything before the "begin" line and after the "end" line is
ignored).
I certainly wouldn't want to recommend the above as standard
practice, but I imagine that are enclaves or situations where it
could be useful.
--
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 <csg@clavinova.eng.sun.com> 27-Aug-1996 ]
Microsoft has at least five different products that handle Internet
Mail:
* SMTP Gateway for Microsoft Mail. (Option for Microsoft Mail
V3. Does not support MIME.)
* The MSN online service. (Does not support MIME)
* Microsoft Exchange Client. (Bundled with Windows95. Supports MIME,
but puts odd things in text/plain. Does proper Content-Types through
the Win95 file types menu.)
* Microsoft Exchange Server Internet Connector. (Optional Gateway for
Exchange Server. Supports MIME, but has its own set of oddities, the
most notorious of which is the application/ms-tnef attachment that
graces almost every message. Does not wrap long lines in text/plain,
either. Has its own private table for mapping content types.)
* Microsoft Internet Mail. (Bundled with Internet Explorer
3.0. Supports MIME and HTML, but attaches *everything* as
octet-stream, even very well known types like image/jpeg.)
[ Ned Freed <ned@sigurd.innosoft.com> 19-Feb-1996 ]
You have to be careful when you talk about MS Mail, because it is lots
of different things. There's the "classic" MS Mail, there's MS
Exchange, there's MS Mail on Mac (now owned by Star*9, I believe), and
there may well be others I have not heard about.
All of them use proprietary formats internally. Classic MS Mail uses
RFC 1154 [obs.] formats rather than MIME when talking to the Internet.
MS Exchange uses MIME, but its usage of MIME is, shall we say,
peculiar. And MS Mail on the Mac can do MIME when talking to the
Internet, and its MIME support is pretty good.
[ Carl S. Gutekunst <csg@clavinova.eng.sun.com> 20-Feb-1996 ]
As Ned noted, the MS Mail SMTP Gateway uses a variant of RFC 1154 [obs.],
a precursor of MIME that had similar intent.
The real rub with all pre-MIME Internet mail attachment models
[is that] they just didn't interoperate.
All current Microsoft Internet connectivity products are MIME
compliant, although somewhat eccentric in their behavior. Oddly
enough, the eccentric behavior is not because of Microsoft's alleged
goal to dominate the Internet with quasi-proprietary protocols, nor is
it out of ignorance. It's just a matter of finite resources and tight
delivery schedules. Surprise.
[ Steinar Bang <sb@metis.no> 19-Feb-1996 ]
>>>>> "APS" == "Andre P Stewart" <astewart@hp43326.mdc.com> writes:
APS> Microsoft Exchange is the MUA that Microsoft currently produces
APS> and supports. It is shipped with Windows95 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'" <sb@metis.no>.
[ Ned Freed <Ned.Freed@innosoft.com> 23-Jun-1996 ]
Another problem with Exchange's use of quoted-printable has surfaced
recently at at least one site -- generation of illegal quoted-
printable encodings. Specifically, the site reported that Exchange
generates =0A instead of a proper hard line break per the MIME
specifications.
There now seem to be all sorts of different versions of Exchange out
there doing different things. I have yet, however, to see firsthand
one that works properly.
[ Steinar Bang <sb@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 <kingkern@eclipse.net> 22-Feb-1996 ]
I encode binhex manually on the Macintosh and send to
MS-Windows users. They decode using Stuffit Extractor
(freeware).
[ Chris Newman <chrisn+@CMU.EDU> 11-Apr-1996 ]
chaney@ms.uky.edu writes:
> I need to be able to un-BinHex MIME mail sent from various
> packages that assume everyone in the worl has an unbinhexer.
> The most common form is a Mac Binhex (it may be the only
> kind?) and I see binhexing from Eudora-based mailers.
Binhex is designed to encode Macintosh files. If someone
sends you a binhex file and you don't have a Macintosh, tell
them to use standard MIME/base64 or MacMIME (Eudora's
nonstandard default configuration can be fixed easily in the
preferences). It is possible to write a program which
extracts the portion of the binhex file which is likely to be
usable on non-Macintosh computers, and I've got sample source
if you wish.
A quick look at RFC 1740 & RFC 1741 will show that use of
binhex in Internet email is generally discouraged.
[ Tim Simpson <tim@cddc.demon.co.uk> 12-Apr-1996 ]
Try emil, available from:
ftp://ftp.uu.se/pub/unix/networking/mail/emil
{ See also appendix B of the MIME FAQ. }
[ Mark Johnson <markj@msn.ustc.vlsi.com> 11-Apr-1996 ]
Look for the program mcvert.
{ Use "archie" to locate the various versions of this
program available via anonymous FTP. }
--
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-faq@ics.uci.edu>. }
America Online
[ Jay Levitt <Jay@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 postmaster@aol.com. For AOL members, keyword
MAIL CENTER is a great resource.
[ Hudson Barton <hhbv@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 <tony@attmail.com> 6-Jan-1996 ]
The AT&T Mail SMTP gateway to the Internet fully converts between its
internal format and MIME. That is, all mail going out the SMTP gateway
should be fully MIME compliant. All mail coming in through the SMTP
gateway into AT&T Mail is converted into its internal format. Research
and development is continually improving the interaction between AT&T
Mail and the Internet standards. This includes improving the MIME-MHS
interaction. Thus, all X.400 mail that goes to the internet will
increasingly follow the internet standards on X.400 connectivity.
Send inquiries to atthelp@attmail.com.
CompuServe
[ Pat Farrell <pfarrell@netcom.com> 31-Dec-1993 ]
CompuServe's main mail service is ASCII text based, and is not MIME
compliant. CompuServe provides robust, reliable mail transport of
binary files. CompuServe invented and copyrighted the GIF format
which is supported by MIME. There are commercial and freeware client
programs for Macs and PCs that can provide "user friendly" access to
CompuServe's text and binary mail services, display GIF files, and
interact with CompuServe's forums. (CompuServe forums are roughly
equivalent to USENET newsfeeds.)
RadioMail
[ Jerry Sweet <jsweet@irvine.com> 21-Mar-1994 ]
RadioMail Corp. (formerly Anterior Technology) operates two types
of e-mail services having these statuses with respect to MIME:
1. cc:Mail/Internet gatewaying. cc:Mail does permit binary
attachments of various types, and these attachments are encoded by
the gateway for transfer via SMTP, but the encoding is not presently
MIME-compliant. This may change.
2. Wireless e-mail gatewaying. Because the RadioMail gateway passes
a limited set of headers, MIME messages per se do not traverse
the gateway intact. 7-bit-encoded MIME messages may traverse the
gateway if encapsulated, e.g. using RFC 934. However, RadioMail
does not presently supply MIME-compliant user agents for use on
radio modem equipped MS-DOS and Macintosh computers. This will
change.
[ Mark Lovell <mlovell@radiomail.net> 4-Jan-1995 ]
The clients for both the Marco and the Envoy support a subset of MIME.
They only support body-part types that they understand, since there is
not a traditional OS on either unit. RadioMail has established a full
set of MIME interface specifications, and future clients will be built
to support them.
--
End of Part 2
*************
--
..
..