Decoding Internet Attachments
A Tutorial by Michael
Santovec
Table of Contents
For additional help, information and resources, see my
Technical Help
page.
Why Are Attachments Encoded?
Internet e-mail and Usenet news posts were designed for plain text messages.
As such, many systems expect the messages to only contain printable characters
from the 7-bit (first bit of the 8-bit byte is always zero) ASCII character
set. These programs can have problems if the message includes extended 8-bit
(the first bit is a one) characters, such as the various accented letters.
This also poses a problem for sending files, such as images, sound, video,
spreadsheets and programs which can contain any combination of 8-bit binary
data. This even poses a problem for formatted documents, since many word
processors embed binary control fields in the files.
The way around this limitation is to encode the binary data (attachment)
into ASCII characters before sending. To the mail and news systems that the
messages travels through, the file is just so much text. At the receiving
end, the message is decoded back into the original file, none-the-worse
for the experience. Many mail and news programs automate the encoding and
decoding. However, sometimes a separate program may be required.
The nice thing about Standards is there are so many to choose from.
Encoding is no exception. Among the more popular are:
Uuencode, MIME,
Base64, Quoted-Printable and
Binhex. There are other less common
methods as well.
It should be noted that encoding is not the same as encryption.
The purpose of encoding is to allow some information to be stored
in, or pass through, a medium that can't handle the data directly. The purpose
of encryption is prevent unauthorized persons from view or using some
information. It's possible for a message to use both encoding and
encryption.
Top of page Top of
section
Uuencode
Uuencode (Unix-to-Unix Encode), as its name implies, comes from the Unix
world. It was commonly used to encode files transmitted from one Unix computer
to another. Since the early Internet consisted almost entirely of computers
running the Unix operating system, it's not surprising that Uuencode is widely
used. Today, almost all computer platforms have programs capable of
encoding/decoding using Uuencode.
Most mail and news programs can decode Uuencode. However, not all of them
can encode it. Most mail systems will pass Uuencode without problems. If
you don't know your recipient's capabilities, Uuencode is a good first guess.
Uuencode is more common in news than mail. MIME is making
inroads in mail faster than news.
Uuencode results in a transmitted message about 42% larger than the original
file. This is typical of the encoding penalty.
Below shows how the image to the right would look if Uuencoded. The first
line starts with the word "begin". The "644" represents the Unix file permissions
(read/write/execute). This is largely ignored by other operating systems.
In this example, "a.gif" is the file name.
The encoded file follows. Most lines begin with an "M" (representing the
line length) and 60 characters of data. The last data line is usually shorter,
and therefore starts with a different character. The end of the encoding
has "`" on a line by itself and then the word "end" on a line by
itself.
begin 644 a.gif
M1TE&.#EA)0`H`+,``.P`2QBQ`/__________________________________
M_____________________RP`````)0`H```$5S#(2:N]..O-N_]@*(YD:9YH
MB@(LH%ZM^U;Q3,6L+>6MW@>_5VXW%,J`Q500>5PUF:HE\4F20ITX'#:K-5FG
;WB3MZR?J^(QM9RVF'7PN'Q.K]OO^+Q^!``[
`
end
Problems can occur due to inconsistent encoding/decoding in different mail
and news programs. For example, Microsoft Outlook Express will use a blank
(x'20') as an encoding character. (Some other encoders will use the ` character
(x'60') instead of a blank.) If the blank ends up as the last character in
a line, Outlook Express will then drop the blank resulting in a short line.
If Netscape decodes this attachment, it will assume that the short line is
padded with nulls (x'00) rather than blanks. This can result with what was
orginally a x'40', x'80' or x'C0' byte becoming a 'x00'. This problem only
occurs when a x'40', x'80' or x'C0' byte was orinally at the 45th byte of
the file, or a multiple there of (e.g. 90th, 135th, etc.).
The file corruption may or may not be apparent. For an image file, a chunk
of the image may appear to be off color or otherwise distorted. For an executable
file, it may seem to run OK, give some error when used, or give incorrect
results. A ZIP file should indicate that it is corrupted when
unzipped.
This problem can be avoided if the Outlook Express user uses
MIME(Base64) encoding instead of
Uuencode. Netscape users can successfully decode the attachment by using
manual Decoding with a product such as Wincode or StuffIt
Expander, both of which correctly assume that short lines are padded with
blanks.
Top of page Top of
section
MIME
MIME (Multipurpose Internet Mail Extensions) is not actually a method for
encoding attachments. Rather, it deals with the overall structure of a message.
A message using MIME doesn't necessarily include attachments. If it does
include attachments, they most often use Base64 encoding,
or sometimes Quoted-Printable encoding. Theoretically,
MIME could even use Uuencode,
Binhex, or other methods, but that is both rare and
frowned upon in the MIME standards
(RFC
2045).
The main advantage of MIME is that it provides a consistent way for the sending
program to describe the message contents to the receiving program. The original
Internet mail message specification
(RFC
822) just describes simple text messages. The message might include an
encoded attachment, but it's up to the receiving program to find it in the
midst of the message text.
Most newer mail and news programs support MIME. However, older programs don't.
And some older mail and news servers either remove or mutilate some of the
MIME headers, rendering the message unintelligible to a receiving MIME capable
program. Due to its flexibility and power, MIME is the best choice if all
parties can handle it.
Some mail and news programs present a choice between Uuencode and MIME encoding.
This is a bit misleading and confusing. The Uuencode choice usually means
to use a simple mail message (none of the MIME message headers), and to Uuencode
any attachments. The MIME choice means to use the MIME headers, and use Base64
or Quoted-Printable for attachments.
The distinguishing characteristic of a MIME message is the presence of the
MIME headers. These are normally invisible in a MIME capable reader, but
can be seen in the message source. Below are shown some typical MIME headers.
The "MIME-Version:" header is present in all messages using MIME. The others
are specific to the attachments or other contents. A MIME message may have
multiple attachments of various types.
MIME-Version: 1.0
Content-Description: "Base64 encode of a.gif by Wincode 2.7.3"
Content-Type: image/gif; name="a.gif"
Content-Transfer-Encoding: Base64
Content-Disposition: attachment; filename="a.gif"
Although the MIME name specifies "Internet Mail", the same considerations
also apply to news. And some parts of MIME are also used by Web Browsers.
In particular, the web servers use the Content-Type ("image/gif" in the above
example) to identify the type of file being sent to the browser so that the
browser can determine how to handle it. However, since the browser protocol
(http) supports binary transfers, the encoding issues don't apply there.
(For more information on Content-Type, see:
RFC
2046 and MIME
Types)
Top of page Top of
section
Base64
Base64 is the preferred encoding method for attachments in messages using
MIME. However, in some cases
Quoted-Printable is used instead. Although Base64 could
be used without MIME, this is rare.
Base64 results in a transmitted message about 37% larger than the original
file. This is typical of the encoding penalty, but slightly more efficient
than Uuencode.
Below shows how the image to the right would look if using Base64 encoding.
The MIME headers provide all the descriptive information. This includes the
file name, its type, and that Base64 encoding is used.
MIME-Version: 1.0
Content-Description: "Base64 encode of a.gif by Wincode 2.7.3"
Content-Type: image/gif; name="a.gif"
Content-Transfer-Encoding: Base64
Content-Disposition: attachment; filename="a.gif"
R0lGODlhJQAoALMAAOwASxixAP//////////////////////////////////////////////////
/////ywAAAAAJQAoAAAEVzDISau9OOvNu/9gKI5kaZ5oigIsoF6t+1bxTMWsLeWt3ge/V243FMqA
xVQQeVw1maol8UmSQp04HDarNVmn3iTt6yGDq+IxtZy2mHXwuHxOr9vv+Lx+BAA7
Top of page Top of
section
Quoted-Printable
Quoted-Printable is used to encode some attachments in messages using
MIME. Quoted-Printable leaves printable ASCII characters
alone and only encodes those characters (bytes) that might get lost or converted
in transit.
If the attachment consists mostly of printable ASCII characters, the MIME
program may automatically select quoted-printable over
Base64, since this would be much more efficient. In
the best case, Quoted-Printable results in a transmitted message only about
3% larger than the original file. However, in the worst case, the transmitted
message could be about 200% larger than the original file. So it's important
to only use this encoding method on suitable files.
Although Quoted-Printable may be used for attachments, it is more often used
for the main message text. The mail or news program may offer the option
to encode the text using Quoted-Printable. There are two advantages to this.
1) Characters outside of the normal printable ASCII can be safely transmitted.
This includes some special characters, and letters from some foreign alphabets.
2) The intended paragraph layout can be preserved. Simple text messages are
arbitrarily chopped into suitable chunks (typically 70-80 characters per
line) by the sending program. Quoted-Printable allows the logical lines to
exceed the physical line limits of the mail or news transport. It places
a hard carriage return (line break) only at the end of a paragraph. The receiving
program can then reflow the paragraph to the viewing window. Not all receiving
programs support wrapping. This may result in each paragraph being displayed
as a single line making the message difficult to read. And some programs
will wrap the text for display, but not for printing.
Some mail and news servers may automatically convert any messages that contain
8-bit characters into quoted-printable encoding as the message passes through
them.
The following sample text
This is a example of a quoted-printable text
file. This might contain some special characters such as:
equal sign =, dollar sign $, or even extended characters such as the cent
sign ¢ or foreign characters ÀÆß
is shown below as it would look if using Quoted-Printable encoding. An equal
sign "=" at the end of a line indicates a soft carriage-return. The receiving
program should remove it and flow the following line into this one. an "=20"
at the end of a line represents a Space. Normally, trailing spaces on a line
are removed in transit. This causes them to be preserved. And finally, an
equal sign followed by 2 hexadecimal characters (0-9, A-F) represent an extended
character.
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
This is a example of a quoted-printable text file. This might contain =
some special characters such as:=20
equal sign =3D, dollar sign $, or even extended characters such as the =
cent sign =A2 or foreign characters =C0=C6=DF
If the recipient's mail or news program can't handle quoted-printable (many
older ones can't), the message will look peculiar with all the equal signs
and hexadecimal encoding, but it is still largely readable.
Top of page Top of
section
Binhex
Binhex is most often used with the Macintosh. Although Binhex decoders are
available for other platforms few people have them. Binhex is a reasonable
choice for encoding if both the sender and recipient are using Macs. However,
in any other case another encoding method should be used.
Unlike most other methods, Binhex encodes the file name and other information
along with the data.
Also, unlike most other methods, Binhex has a built-in compression capability.
It's possible that a highly compressible file could result in a smaller
transmitted message than the original file. However, you will generally get
better results by compressing the file first with a standard
compression utility. For an already compressed
file, Binhex results in a transmitted message about 40% larger than the original
file. This is typical of the encoding penalty, but slightly less efficient
than Base64.
Below shows how the image to the right would look if using Binhex encoding.
The first line, rather obviously, indicates the encoding method.
(This file must be converted with BinHex 4.0)
:"@%ZCfPQ!&4&@&4YC'pc!*!&SJ#3"*!!bNG*4MJjB58!+!#c!!$X!%XBX3$rN#S
X!*!%*3!S!!!%9c$)5DZp11[0ZrpJ+)jNDCjSLJ)XS&kYqeEa6-@X,H@YhJHr9fi
h&-U!a933H9`eQDSPm8Q53Tdi($DV09QRhL6Ykb'$Uq)aYCbfQ(A`Z(a1Vp[[q,a
q"!!lU1B!!!!!:
A file encoded using Binhex often has an HQX file extension. If Binhex is
used in a MIME formatted message, if usually has a
Content-type: application/mac-binhex40. This is a departure from the
usual MIME format, in that the Content-type indicates the encoding method
rather than the type of data in the file. For more information, see
RFC
1741.
Top of page Top of
section
Other Encoding Methods
In addition to the most common encoding methods discussed above, you might
encounter several other methods of encoding attachments, or several things
that look similar to encoded attachments. The following should help you identify
what you've got.
Binary, 8-Bit, Raw
Below shows how the image to the right might look if using Binary, 8-bit,
or Raw encoding. This does not actually encode the file, but rather includes
the data without any conversion. Some mail and news programs allow you to
do this or you might be able to paste the file or concatenate it into the
message text without conversion. However, Internet mail and news transports
don't guarantee to transmit the file without alteration. It's quite possible
that the message will get truncated because some combination of characters
look like an end of message indication. It might even result in a corrupted
mail folder on the mail server or the recipient's mail program. It's unlikely
that the recipient will be able to use the file unless it was a text file
to begin with. If you receive such a file, you might as well throw it away
and ask the sender to try again.
![A 8-Bit](a8bit.gif)
BTOA
Below shows how the image to the right might look if using BTOA encoding.
This is rarely seen on the Internet today.
xbtoa5 78 a.gif Begin
7nH003FO36-igRR!:0\Y(pO)@s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!s8W-!s"<
"-M!!";F-ia5M="q]eX1^LYc+F!`.#qhPSnNu_/>-=Oqc<5\`N1ZQXkj;t=)Kr2b(.H1&:%M<RAqS,
'8WlE23#jiW2-Hj6,jjn@K<*ud[@F[mFmung:9WF@pq2%Y!':/\E
xbtoa End N 162 a2 E 26 S 3a3f R 7626cb65
BOO
Below shows how the image to the right might look if using BOO encoding.
This is rarely seen on the Internet today.
A.GIF
AdU6>3UQ9@0X0;<00>`0BaRa0?oooooooooooooooooooooooooooooooooooooooooooooooooo
ooooob`0~39@0X~215L`b4V[_CS[cK_oH2R>I6VNJ8X2;:1N[O]FlDc5[2gU[Mh7_eM^=aC:P<ED
47UL=IVZ9O59TT:M>1`fZcEIYmhTkN\QPj_R<KFL]YQel;QlCZoKkoRlOP@0>`00
ROT-13
ROT-13 is not a encoding format for attachments. It is a simple encryption
for text. It Rotates each letter of the alphabet 13 positions. "A" and "N"
are exchanged, "B" and "O" are exchanged, etc. Numbers, spaces and punctuation
are not changed. Because it is so simple, its purpose is not security. Rather,
it is used so that others don't accidentally read a message that they don't
want to. It was most often used for messages of questionable taste. Some
news readers have ROT-13 decoding built-in. It is rarely used on the Internet
today. Below is a sample of a message using ROT-13 encoding.
Guvf vf n fnzcyr bs n zrffntr rapbqrq hfvat EBG-13 rapbqvat.
Orpnhfr bs gur fvzcyr angher bs gur rapelcgvba, vgf checbfr
vf abg frphevgl ohg gb cerirag nppvqragny ernqvat.
Top of page Top of
section
MS-TNEF WINMAIL.DAT Attachments
Mail programs in the Microsoft Exchange family, which includes Windows Messaging,
Outlook97, Outlook98 and Outlook2000, will include a TNEF (Transport Neutral
Encapsulation Format) attachment named WINMAIL.DAT when the sender selects,
or defaults to, RTF (Rich Text Format). If the sender is using MIME formatting,
this attachment will have Content-Type: application/ms-tnef.
The TNEF attachment includes a Rich Text Format (e.g. bold, underline, fonts)
version of the plain text message. If the sender has included any attachments
(e.g. pictures, spreadsheets, programs), they will be embedded within the
TNEF attachment and not as separate attachments.
Most other mail programs do not know how to handle the TNEF attachments and
so Exchange family users should avoid using RTF unless they know that the
recipient has a compatible program. The sender can control the use of RTF
on a recipient by recipient basis. However, if sending via a Microsoft Exchange
server, the server can override the sender's settings. In this case the Exchange
administrator will need to make changes on the server. For more information
on this, see the following articles:
How
Message Formats Affect Internet Mail,
XCLN:
Sending Messages In Rich-Text Format,
XFOR:
Preventing WINMAIL.DAT Sent to Internet Users,
Sending
RTF with Attachment as MIME Loses Attachment,
XADM:
POP3 Users may not Receive an Attachment if Part of DL and
XFOR:
CR Receives Rich Text Format Information Unexpectedly.
Fentun
Fentun is a freeware TNEF
Attachment Extractor. It is available for the Win95/98/NT4 and Linux operating
systems. It does not show the RTF message embedded in the TNEF attachment,
but does let you see if there are any other attachments within the TNEF
attachment and let's you save them.
For Netscape Mail, Fentun can be installed as a Helper. Instructions are
at the Fentun web
site.
If the Fentun author's web site
is unavailable, a copy the the Win95/98 version, along with notes, is available
for download
here.
If you download this
MS-TNEF.REG
file, and run it on a Win95/98 system, it will create a file association
for *.TNF files to Fentun, in order to make Fentun easier to use with other
mail programs. Depending on where you install the FENTUN.EXE program, you
will need to either edit the path in the registry file before running, or
else update the path in the file association after running. For details,
see the comments in the MS-TNEF.REG file.
Users of Microsoft IE3 Internet Mail, and IE4/IE5 Outlook Express will not
see any indication that they have recieved a TNEF attachment. Apparently,
Microsoft has decided that since these programs can't handle a TNEF attachment,
it will be hidden. In order get these programs to decode the TNEF attachment
and make it available to Fentun via the above file assocation, perform the
following steps:
-
Save the whole e-mail message to an *.EML file via File, Save As, or
Drag-and-drop
-
Open the *.EML file in a text editor such as Wordpad or Notepad
-
Locate the line Content-Type: application/ms-tnef;, and change the
Content subtype to something else, such as Content-Type:
application/ms-tnefx;
-
Locate the line filename="winmail.dat" and change to
filename="winmail.tnf". You may change the winmail part as
well, if desired
-
Save the *.EML file from the text editor
-
Double click the *.EML file from the Windows File Explorer. This will open
the message in a mail window and the TNEF attachment should now be available
for saving or opening.
LS-TNEF
LS-TNEF is a Java
based TNEF Decoder. The LS-TNEF API allows one to decode the TNEF file from
the command line, via the API or by using Sun's Java Mail API.
Top of page Top of
section
HTML - Web Pages
HTML (Hyper Text Markup Language) is used to describe web pages. A web page
consits of one or more files. The main file is a text file that contains
the HTML formatting codes, usually most or all of the page text, links to
any other web pages and links to any images, animations, sound clips, etc.
Each image, animiation, sound clip, etc. is a separate file.
Some, but not all, mail and news programs can display HTML messages. Most
that can display HTML require that the message use MIME
formatting and specify Content-Type: text/html for the HTML message
portion. Many programs that create HTML messages specify Content-Type:
multipart/alternative and include two copies (attachments) of the message
text. The first is the plain text version of the message (Content-Type:
text/plain), the second is the HTML version (Content-Type:
text/html). If a receiving program understands the MIME multipart/alternative
and HTML, it will display the HTML version in the message body and hide the
plain text one. If it doesn't understand HTML, it will display the plain
text version in the message body and hide the HTML one. If it doesn't understand
multipart/alternative it may display either or both message copies as
attachments. And if it doesn't understand MIME, it will display both copies
in the message body, but the HTML version will be difficult to read because
it will be the raw HTML with all the formatting codes displayed.
Below is "A simple HTML message.":
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0059_01BEA6E2.1A467F40"
This is a multi-part message in MIME format.
------=_NextPart_000_0059_01BEA6E2.1A467F40
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
A simple HTML message.
------=_NextPart_000_0059_01BEA6E2.1A467F40
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY>
<DIV>A simple <STRONG>HTML</STRONG> message.</DIV>
<DIV> </DIV></BODY></HTML>
------=_NextPart_000_0059_01BEA6E2.1A467F40--
The HTML capabilities of mail and news programs come in 3 levels:.
-
HTML Text Only Some programs can only display HTML text and links.
They cannot display any referenced images, play sound clips, etc. Links to
images and such might just appear as a link, or not at all.
-
HTML Text and External Images Some programs can display images if
the HTML contains a link to an external source, such as a web site or a corporate
file server. If the image link is to a web site, then the recipient must
have an open Internet connection while reading the message for the image
to be displayed. If the image link is to a corporate web server, then the
recipient must have access to the web server while reading the message, and
use the same drive mappings as the sender. If the image link is to the sender's
local disk drive, then the recipient would have to have a copy of the image
file already on their own local disk drive in the corresponding directory.
Support for links to sound clips may be limited or non-existent.
-
HTML Text, External and Internal Images Some newer programs support
Content-Type: multipart/related which also allows the linked images
to be attachments in the same message as the HTML code. The advantage is
that the recipient doesn't need a live Internet connection or access to a
file server to see the images while reading the message. One disadvantage
is that the mail or news message becomes much larger in size. Additionally,
if such a message is sent to a recipient with only level 2 HTML support,
they won't see the images within the message. They may see the images as
separate attachments, or not at all.
If a message's HTML features exceed the capabiliities of the recipient's
mail or news program, it is possible to save the HTML portion of the message
to an HTML file (.HTM or .HTML file extension) and then open in the web browser.
If the message used multipart/related, the images will need to also be saved,
possibly requiring manual Decoding. The HTML file will
require editing if multipart/related was used because the links are not normal
file names. Even in other cases, some edting may be required to make the
HTML file usable. Overall, this is a lot more bother than it is probably
worth.
Top of page Top of
section
Macintosh Notes - AppleSingle and
AppleDouble
Some Macintosh files consist of two parts:
-
Resource Fork contains information about the file
-
Data Fork contains the actual file contents
A Macintosh mail or news program could encode attachments one or more of
the following ways. Some may offer a choice, some will support only one of
the following.
-
Data Fork only - This is what most non-Macintosh systems would send.
This would be the best choice for sending from a Macintosh, if all recipients
are known to be non-Macintosh users.
-
AppleSingle - This combines the Resource and Data Forks into a single
attachment. Only Macintosh users would be able to use such an attachment.
Only use this option is all recipients are known to be Macintosh users.
-
AppleDouble - This sends the Resource and Data Forks as two related
attachments. Macintosh users can use both attachments, non-Macintosh users
can ignore the first Resource attachment and just use the second Data attachment,
assuming that they have an application that supports the file format. This
would be the best choice for sending from a Macintosh if the recipients are
both Macintosh and non-Macintosh users, or their computer type is unknown.
However, some older mail and news programs may have problems with AppleDouble
and require manual decoding.
AppleSingle and AppleDouble attachments normally use MIME
formatted messages with Base64 encoding. The Data Fork
only attachments could use Base64,
Uuencode or Binhex. For example,
if the Macintosh program gives you encoding options of AppleDouble, Base64
and Binhex, the Base64 and Binhex options likely send only the Data
Fork.
When a non-Macintosh user receives an AppleDouble attachment, they will most
likely see two attachments. Both attachments might have the same name (e.g.
photo.jpg), or the first attachment (Resource Fork) might have a generated
name (e.g. att0001.dat) while the second (Data Fork) has the real name (e.g.
photo.jpg). The first attachment is usually small (less than 10 KB). They
will likely get an error if they try to open the first attachment (unknown
file type or invalid file format). They should ignore the first attachment
and just open/save the second one.
You can verify the presence of AppleSingle or AppleDouble encoding by looking
at the message source. AppleSingle will have a single attachment with a
Content-type: application/applefile. AppleDouble will have a header
with a Content-type: multipart/appledouble followed by the Resource
Fork attachment with Content-type: application/applefile followed
by the Data fork attachment with a Content-type that depends on the actual
file type (e.g. Content-type: image/jpeg). For more information, see
RFC
1740.
Top of page Top of
section
Identifying Attachment File Types
Usually the file name of an attachment indicates the type of file it is.
For example, a file named A.GIF has a file extension of GIF
which indicates that it is probably a GIF image file. Knowing the type of
file allows you to select an appropriate application program to open the
file in.
The following sites have lists of file extensions and the type of file it
could be: Joz's Extensions Base,
CKNOW.COM
File Extensions, Common
Internet File Formats,
WhatIs.com.
However, file extensions are not necessarily unique. The same file extension
may be used by different types of files. For example, a DAT file could be
just about anything. In some cases, the attachment arrives with an incorrect
file extension. It may be necessary to take a look at the contents of a file
to determine what it is. Often you can use a text or word processor, such
as the Windows Notepad or Wordpad, to look at a file.
If the file is mostly a jumble of letters and numbers, it may need manual
decoding. Comparing the file to the examples in
Uuencode, MIME,
Base64, Quoted-Printable,
Binhex, and Other sections should
allow you to identify the type of encoding used. See the
Decoding Mechanics section for how to handle these
files.
If the file appears to be mostly strange characters, there may be a few letters
in the mix that let you identify the type of file it is. For example, if
the file appears in your word processor as
![A 8-Bit](a8bit.gif)
the GIF as the first 3 characters identifies this as a GIF image file. The
identifying characters don't necessarily match the file extension and they
aren't necessarily the first 3 characters. This varies by file type.
The following is a list of some common file types and the identifying
information.
-
AU - Sun audio file has .snd as the first 4 characters of the
file
-
AVI - Windows video file has RIFF as the first 4 characters
of the file and AVI LIST about 9 characters into the file
-
BMP - Windows Bitmap image file has BM as the first 2 characters
of the file
-
EXE - DOS/Windows program has MZ as the first 2 characters
of the file
-
GIF - GIF image file has GIF as the first 3 characters of the
file
-
JPG - Jpeg image file usually has JFIF about 7 characters into
the file, although some may have Adobe there instead
-
MID - Midi music file has MThd as the first 4 characters of
the file
-
MOV - Apple Quicktime
movie file has mdat about 5 characters into the file
-
PDF - Adobe Acrobat
file has %PDF as the first 4 characters of the file
-
RA - Real Audio file has .ra as the first 3 characters of the
file
-
RMI - Midi music file has RIFF as the first 4 characters of
the file and RMIDdata about 9 characters into the file
-
TNF - MS-TNEF file has IPM.Microsoft
Mail.Note about 50 characters into the file
-
WAV - Windows Wave audio file has RIFF as the first 4 characters
of the file and WAVEfmt about 9 characters into the file
-
ZIP - ZIP compressed archive file has
PK as the first 2 characters of the file
If the file is a Microsoft Office file (Word, Excel, Access, Power Point),
the following free utilities may be useful:
Microsoft Office
Converters and Viewers
Top of page Top of
section
Compression and Message Size
Limits
Sometimes it is a good idea to compress the files before attaching. The
advantages of this are:
-
Faster transfer. Since many people have a relatively slow mail or news
connection, this could make a big difference for both the sender and recipient.
Databases, spreadsheets and word processing documents may be reduced in size
by 50% to 90%. Some image and sound files, such as BMP and WAV, may be reduced
in size by 20% to 50%. On the other hand, some image and multimedia files,
such as GIF, JPG and MPG have built-in compression. These typically get less
than 10% additional compression, and may even get slightly larger. Executable
programs may be reduced in size by 10% to 30%. However, installation programs
typically have internal compression of the components and benefit little
by further compression.
-
Many ISPs put a limit on the size of a user's server mail box. A limit of
5 to 10 MB is common. Any message larger than the limit will be rejected.
But often there is already other mail waiting in the server mail box for
the user to download. This reduces available space. Any message larger than
the available space will also get rejected. So without compression, it might
not be possible to send a large file to a person. And the limit is for the
message as sent. That includes the encoding overhead. So if the recipient's
limit is a 10 MB mail box, you'll never be able to send a file over about
7 MB.
-
The smaller file size may reduce or eliminate the need to break apart the
message into several smaller messages. Some ISPs (sender's or recipient's)
place a maximum size on each individual e-mail message or news post. This
is more common for news than mail. At one time 60 KB to 100 KB was a common
limit. Today, 256 KB to 1 MB is more common. If a message exceeds the limit,
it may be refused or truncated. Many mail and news programs have the option
to automatically break apart messages over a user specified size. However,
almost certainly, reassembling the parts will acquire some work on the
recipient's end. Reducing the number of parts, or getting the message down
to a single part is very desirable. For more information, see the Multipart
Messages topic in the Decoding Mechanics section.
-
Mail and news servers and programs are free to reformat the message text
as the message passes through them. This includes dropping trailing spaces,
converting line termination characters (carrige return and/or line feed),
converting messages with 8-bit characters to quoted-printable, or changing
text that might get interpreted as a program directive rather than data.
By compressing a file that is mostly text, this will force the sending program
to use Base64, Binhex or Uuencoding which will make the file immune to these
modifications. On the other hand, if the sending program uses no encoding,
or even quoted-printable encoding, the message text is subject to these possible
modifications.
-
Many compression methods allow combining several files into a single archive.
This may be more convenient than attaching several files to the message,
particularly if sending an entire folder or directory. Also, some ISPs or
mail programs can handle only a single attachment per message, or have
complications with multiple attachments.
-
The compression may preserve the file's original date/time stamp, which is
often lost in a normal attachment. This may be useful later in identifying
the version of the file.
However, since compression does require a little extra work on both the sender's
and recipient's part, there are times when it isn't worth the bother. If
the file size is small (e.g. less than 40 KB) or a file type that doesn't
compress well (see above) and you are only sending one or two files, I wouldn't
compress them. Also take into consideration whether the recipient will know
how to uncompress the file.
There are several compression methods
ZIP
This is the most common compression method on DOS and Windows PCs. Programs
are also readily available to handle Zip files on other platforms. This is
the best choice of a compression method for DOS and Windows, as well as
cross-platform file transfers. PKWARE
PKZIP/PKUNZIP is the standard DOS program for ZIP files. They also have versions
for Windows, OS/2 and Unix. There are also numerous DOS and Windows front-end
programs available to make the use of the DOS PKZIP easier.
Winzip is a popular Windows base Zip/Unzip
program, that also has decoding abilities.
Info-ZIP has freeware Zip
and Unzip programs for over 30 operating systems.
StuffIt - SIT
Aladdin Systems StuffIt is commonly
used on Macs. Unstuffing utilities (e.g. StuffIt Expander) are available
for DOS and Windows PCs, but few people have them. Utilities for creating
SIT files are not commonly available on these platforms. StuffIt Expander
can also uncompress ZIP files as well as decode Uuencode and Binhex.
TAR - Compress
TAR (Tape ARchive) is the standard archive for Unix systems. This is often
combined with the standard Unix utility "compress". Compressed Unix files
typically have a file name ending in ".Z". TAR and Unix "compress" compatible
utilities are available for other platforms, but few people have
them.
For ZIP and other utilities, try these sites:
ZDNET Hotfiles,
SHAREWARE.COM,
c|net Download.Com,
Filez.
Top of page Top of
section
Encoding Mechanics
Most newer mail and news programs provide automatic encoding of attachments.
You merely select the menu item or button for Attachment and then select
the file to attach. Or your operating system may provide a drag-and-drop
or other method to send a file. If your mail or news program supports more
than one encoding method, there will be an option to set the default encoding
method. There may also be the option to override the default encoding method
when composing a message. (Note: Some programs support more decoding methods
than they do encoding methods. For example, a program might always use MIME
encoding in sending, but be able to decode either MIME or Uuencoded attachments
on receipt.)
There are two cases where you might need or want to manually encode an
attachment: your program doesn't support attachments or the recipient's program
can't decode any of the encoding methods that your program supports.
Because MIME headers are integrated with the message
headers, it would be difficult, if not impossible, to manually insert a MIME
encoded attachment in an existing message such that the recipient's program
would automatically decode it. For this reason,
Uuencode would be the best choice for manual
encoding.
When you manually encode a file, the encoder program produces a plain text
file. For example, the A.GIF file might get converted to A.UUE. ".UUE" is
a common extension for Uuencoded files. However, the exact name is unimportant
since it should appear nowhere in the sent message. Once you have the encoded
file, you need to insert it as text into the body of the message. The encoded
file should appear along with your message text, as in the following
example.
Hi Bob,
Here's the image file that I promised you.
begin 644 a.gif
M1TE&.#EA)0`H`+,``.P`2QBQ`/__________________________________
M_____________________RP`````)0`H```$5S#(2:N]..O-N_]@*(YD:9YH
MB@(LH%ZM^U;Q3,6L+>6MW@>_5VXW%,J`Q500>5PUF:HE\4F20ITX'#:K-5FG
;WB3MZR?J^(QM9RVF'7PN'Q.K]OO^+Q^!``[
`
end
Some people include a line, such as "------ CUT HERE -----" before and after
the encoded text. This is unnecessary. If the recipient's program can decode
the attachment type, it won't use those lines. If the recipient has to manually
cut the encoded text for decoding, after they've done it once, it will be
obvious to them what needs to be cut.
Notes: If you are manually encoding a file, be sure to Insert
as Text and not Attach the encoded file. If you attach the encoded
file, it gets encoded a second time. Not only does it make the resulting
message larger than necessary, but defeats the purpose of manual encoding.
If the recipient could decode your attachments in the first place, there
would be no need for the manual encoding. By attaching an already encoded
file, you are forcing the recipient to double decode it.
If you manually Uuencode an attachment and insert that into a message that
is using MIME, that may allow a recipient whose program only supports Uuencode
to automatically decode it. However, if the recipient's program supports
MIME, it may not automatically decode such a message, even if that program
also supports Uuencode. That's because many programs don't expect MIME and
Uuencode to be used in the same message. They only look for Uuencoded attachments
in messages without any MIME headers.
If you are going to use compression, you compress
the original file first. Then either attach the compressed file (if using
automatic encoding) or encode the compressed file (if using manual
encoding).
Top of page Top of
section
Decoding Mechanics
Most newer mail and news programs provide automatic decoding of attachments.
However, your program might not support the encoding method used by the sender.
If your program can handle the decoding of more than one method, it will
usually automatically detect the message's method.
If your program automatically decoded an attachment, it will do one of several
things, depending on the program, your options, the type of file and/or how
it was attached.
-
Display, Play or Open the attachment. The program might automatically display
images inline, or play audio files or open other files in another application.
If you want to save the attachment for future use, your program might offer
the option to right click the image to get that option, or you might need
to change a program option (e.g. Display Attachments as Links) in order to
get the option to save the file.
-
Show an Icon for the attachment. You would then generally click on the icon
to open the file or get a menu allowing you to save the attachment.
-
Save the attachment to a directory. Some programs automatically save the
attachment to a predefined directory. There would then be a note in the message
specifying the name assigned to that attachment. You would then use your
operating system facilities to open the attachment.
You might need to manually decode an attachment. The reasons for this include:
The sender used an encoding method not supported by your mail or news program;
your mail or news server doesn't support MIME and removed some critical MIME
headers; the sender double encoded the attachment (see
Encoding Mechanics); and the original message was split
into multiple parts (see Compression and Message Size
Limits)
If your mail or news program decodes an attachment, but it needs further
decoding, use the program's save attachment feature, then use the manual
decoder on that file (for an exception, see Multipart Messages below). Otherwise
you need to save the raw message as a plain text file. Most programs have
a File, Save As option to save a message to an external file. Although they
may give the file a special extension, these are normally plain text files.
Your manual decoder program might expect that the file has a special extension,
such as ".UUE", but this is usually not necessary.
It's a good idea to look at the saved file in your word processor to see
what you've got. Comparing the file to the examples in
Uuencode, MIME,
Base64, Quoted-Printable,
Binhex, and Other sections should
allow you to identify the type of encoding used. If the file does not look
like any of the encoding formats, see the Identifying
Attachment File Types section for further help.
Depending on the manual decoder program that you use, you may need to do
some editing of the saved file before decoding. You may need to remove message
headers (e.g. From:, Subject:, etc.) and normal message text. However, MIME
decoders generally expect the message headers, and Binhex decoders expect
the "(This file must be converted with BinHex 4.0)" line. Some better decoder
programs (e.g. Wincode) do a good job of ignoring what they don't need, so
that you rarely need to edit the file before decoding.
You might also need to tell the decoder program the type of encoding used,
or select a different decoder program based on the type of encoding. Wincode
version 2.7.3 or later does a good job of determining the encoding type if
set to "AUTO-1" decoding. (However, some files use Base64 with incomplete
or no MIME headers. In that case you will need to manually strip the file
of any headers before decoding and set Wincode to decode Raw Base64.)
Multipart Messages
Because of message size limits imposed by some ISPs (see
Compression and Message Size Limits), larger
attachments may have been split into multiple messages. Since decoding is
the reverse of encoding, you must perform the steps in the reverse order.
The original file was first encoded, then split into multiple messages. So
you must first combine the multiple messages, then decode it.
Some news programs (but fewer mail programs) may automatically identify the
message parts, combine them and decode. Some others may allow you to identify
the parts and order them, then the program will decode it. However, in many
cases, you will need to manually save the parts and then decode it.
Your mail or news program may automatically decode the first message part.
However, that doesn't do you any good. There is no practical way to combine
that already decoded part with the rest of the parts. You will need to save
each part (including the first) as a plain text file (as discussed above),
then decode that. Your program may allow you to select all the parts and
save as a single text file. If not, save each message part as a separate
file. If you give the individual parts names such as FILE1.UUE, FILE2.UUE,
FILE3.UUE, etc. then tell Wincode to decode FILE1.UUE, it will automatically
find the other parts for decoding. For some decoders it may be necessary
to use your word processor (or other program) to combine the individual parts
into a single file before decoding.
For Wincode and other decoding utilities, try these sites:
ZDNET Hotfiles,
SHAREWARE.COM,
c|net Download.Com,
Filez.
Winzip also includes decoding functions.
Aladdin Systems StuffIt Expander
can also decode Uuencode and Binhex.
Top of page Top of
section
Problems and Complications
If there weren't problems and complications, you wouldn't be reading this.
Most of these are caused by incompatibilities between the sending and receiving
program. Another source of problems is the sender's lack of understanding
of encoding. One or more of the following may apply to the problem message.
-
Instead of an attachment, you see a bunch of gibberish in the message.
The sender used an encoding method that your program doesn't support, or
double encoded the file. You will need to save the message and then manually
decode it. See the Decoding Mechanics section. If this
is a mail message, it might be possible that in the future the sender could
use an encoding method common to both your programs. However, depending on
the programs used, there might not be a common method. Or this could be an
HTML message and your program doesn't support HTML or
the MIME formatting may be incorrect. This can also be
due to the message being split into multiple parts. See the next item for
more details.
-
You have an incomplete attachment. Due to message size limits imposed
by ISPs, there may be multiple parts to the message. In newsgroups, it is
not unusual for some of the parts to get lost or delayed in transit. Without
all the parts, there is no point in proceeding. If all the parts are available,
see the Multipart Messages topic in the Decoding
Mechanics section.
-
Instead of an attachment, you see some of the text of the file in the
message. If the sender is using Netscape, and attaches a file that is
mostly text (e.g. word processing document, spreadsheet, database), sometimes
Netscape will treat it as a pure text file and insert it in the message without
encoding it. The resulting file is unusable. The workaround is to have the
sender compress the file first, then attach that.
Alternately, the file may appear as an attachment, but the word processor
or other program may not be able to properly handle the file because some
binary data got lost. Similar problems can happen with other mail and news
programs due to the mail or news server reformatting the message text. The
same workaround applies.
-
The message text appears as an attachment rather than in the message
body. There are several causes for this.
-
The sender wrote the message in another program (e.g. Word Processor) and
explicitly attached it. It may be neccessary to open the attachment in a
compatible program.
-
The sender did a Forward as Attachment to a message. Some programs always
do this (e.g. AOL), others may do this by default (e.g. Netscape, but the
sender can do a "Forward Quoted" instead to avoid this). This can also happen
with Digest type messages from a mailing list. The message may include the
MIME directive "Content-Disposition: inline" which your program is ignoring.
Your program may have a View Attachments Inline option which you need to
select. Another workaround may be to view the message source.
-
The sender used 8-bit characters and some server along the way converted
the message to Quoted-Printable encoding. If the conversion
was applied to only part of the message rather than the whole message, this
can result in attachment parts. If the sender selects quoted-printable encoding
for the message text, this may avoid the problem.
-
The message uses HTML which requires
MIME, and some server along the way doesn't support MIME
and removed some of the MIME headers. This is most likely to happen with
some mail lists. This may cause the receiving program to treat the HTML version
of the message as an attachment. If the sender uses Plain Text instead of
HTML, this may avoid the problem.
-
The sender used a character set that the recipient's mail server doesn't
support. The mail server may convert the message text to an attachment (e.g.
ATT00000.TXT) which the recipient will need to view in a word processor.
This is more likely to happen with mail servers such as Microsoft Exchange
which reprocess messages rather than a simple POP3 mail server which passes
messages through largely unaltered. For some additional information, see
XFOR:
Attachment with Name of Charset. If the sender switches to a more common
character set, the problem may go away. Suggested character sets to try are
iso-8859-1 (Western Alphabet ISO) and US-ASCII.
-
Instead of an picture attachment, you see the message [Unable to display
image]. The sender used AOL, inserted the image in the message body,
and the recipient does not use AOL. Such images are only viewable by AOL
recipients. The AOL mail system removes the images and inserts the above
message instead when messages are sent to other services. The AOL sender
needs to Attach the images as files to the message rather than Insert them
in the message body in order for non-AOL recipients to get the images.
-
You see no indication of an attachment. Possibilities include:
-
The sender may have forgotten to attach the file. It happens.
-
You turned off your mail or news program's option to display the attachment
indicator. Check your program documentation or help file.
-
The sender is using an encoding method not supported by your program, or
there is an incompatibilty between the mail server and the mail client programs.
For one variation on this issue, see: MS-TNEF.
If your program has a View Message Source option you should be able to quickly
tell if there is any attachment there. If there is an attachment, or you
don't have that option, you will need to save the message and then manually
decode it. See the Decoding Mechanics section. If this
is a mail message, it might be possible that in the future the sender could
use an encoding method common to both your programs. However, depending on
the programs used, there might not be a common method.
-
The message downloads to your PC, then disappears. Some users of Microsoft
Internet Mail builds 4.70.1160 through 1162 have a problem where messages
with MIME attachments are written to the Inbox.mbx file, but the mail program
doesn't properly update the index and some other information. The problem
seems triggered by some ISP mail servers or sender's mail program. Using
Inbox Assistant seems to avoid the problem. The rules don't have to apply
to the problem messages. If you don't need to use Inbox Assistant for any
other reason, you could create a dummy rule, such as moving all mail for
(i.e. To: field contains) "ABCXYZ123" to the Deleted Items Folder. You should
never get a message with that To: field, so no messages should ever automatically
be moved to the Deleted Items folder. But having a rule, any rule, is sufficient
so that the messages will stop disappearing.
-
You get two attachments where one was expected. You may get an error
when trying to open the first attachment, but the second one is OK. The sender
may have a Macintosh and used AppleDouble. In this case just ignore the first
attachment and use the second one. For more information, see:
Macintosh Notes. This may also happen when the sender
used MIME with Binhex or Uuencode encoding. Some older MIME aware programs
may show the attachment twice, even though it is in the message only once.
Both may be identical, or the first one may be unusable whereas the second
one is OK. In this case, just use the second one.
-
Some recipients get a corrupted attachment whereas others receive it OK.
This can occur when the sender/poster used Microsoft Outlook Express with
Uuencode encoding and the recipients with the problem
are using Netscape. For details and workarounds, see the
Uuencode section.
-
You are unable to open, view, play the attachment. There are a lot
of causes to this, most of which boil down to that the attachment is not
what it claims to be. As a first step, save the attachment to a file. It
may be helpful to take a peek at the file with your word processor to see
if you can identify what you have (see the Identifying
Attachment File Types section) The specific cause of the problem may
be one, or more, of the following:
-
Your mail or news program can't handle the file type. For example, Netscape
version 3 will try to play audio files in mail or news using a plugin, but
they don't work there. You need to save the file, and then play it with another
application.
-
Your mail or news program may be incorrectly configured to invoke an external
application for the type of attachment. Not all programs have a specific
configuration for this. Some use the operating system configuration.
-
You might not have an application capable of viewing the attachment. If the
file name ends in .ZIP, .SIT or .TAR, see the
Compression and Message Size Limits section. If
the file name ends in .UUE .HQX, .MIM, .MIME, or .MME see the
Decoding Mechanics section. For the .MIM and .MIME
file names also see the AOL topic in Notes on Service
Providers. For other file names, see the Identifying
Attachment File Types section.
-
The sender saved the file in version 99 of program X, but you have version
33, or another program that can read version 33 files of program X. You'll
need to either ask the sender to save the file in the older version 33 format,
or you will need to get an updated program or conversion program to handle
version 99 files. For example,
WD97:
Cannot Open Word 97 Documents in Word 6.0 or 7.0 Also see
Microsoft Office
Converters and Viewers
-
As a variation on the above, audio, video and image files of a given type
can come in various flavors. For example, there are numerous codecs
(encoding/decoding algorithms - separate issue from attachment encoding)
used with AVI (Video for Windows) files. Your player program might not have
the particular codec that the file uses. You might need a newer player program
or some additional codecs. For example, both GIF and JPG images can come
in a normal (non-progressive) format or the newer progressive format. The
Progressive format is designed for large images downloading from a web server
into a web browser via a slow link. The beginning of the file has a low
resolution version of the image that the browser can display to the user
while the rest of the image downloads with more detail. Progressive GIF images
have been around for more than 10 years and so most, but not all, display
programs can display them. Progressive JPG images are newer and so it is
more common to have a display program that cannot handle them. If a program
cannot handle a Progressive image, it may either display a blank image or
give an error message saying that it doesn't recognize the file format.
-
The sender, or sender's program did not provide the correct MIME Content-type
for that attachment. Some programs (e.g. Netscape) pay more attention to
this than others. You may be receiving the generic "application/octet-stream"
which says that it is a binary file of unknown type. Could be anything. Saving
the file (possibly renaming it) may allow you to associate the correct
application with it. For some additional information, see the
Identifying Attachment File Types section.
-
The sender, or sender's program did not provide the correct file extension
for that attachment. Some programs (e.g. Microsoft) pay more attention to
this than others. For example, a BMP image file might have an JPG file name.
Some programs may still display the image because it recognizes the file
type from its contents, whereas other programs may report that the file is
not the proper format. Or there might not be any file extension. Some Windows
mail or news programs may make up a file extension based on the MIME Content-type
if an attachment arrives without a file extension. The file could end up
with a generic DAT file extension. Saving the file (possibly renaming it)
may allow you to associate the correct application with it. This often occurs
when sending from a Macintosh or Unix system where file extensions are less
common to a Windows or OS/2 system where almost all files have a file extension.
For some additional information, see the Identifying
Attachment File Types section.
-
The sender may have double encoded the file. For example, they may have had
an A.GIF file that they manually encoded to A2.GIF (A.UUE would have been
a more appropriate file name), then attached the A2.GIF file to the message,
which encoded it a second time. By doing this, they made more work for themselves
and you. You will need to save the A2.GIF attachment (possibly rename it
A2.UUE), then manually decode it. See the Decoding
Mechanics section. This is a far more common problem then it ought to
be.
-
The attachment is named FILE.EXT. The original file name got lost during
forwarding of the message. You will need to save the attachment, determine
its correct file type and rename it. You may need to contact the sender to
determine the correct file type. For some additional information, see the
Identifying Attachment File Types section.
-
The attachment is named WINMAIL.DAT, or the Content-Type is application/ms-tnef.
See the MS-TNEF section.
Top of page Top of
section
Notes on Mail and News Programs
Disclaimer: Information in this section is based on rumor and innuendo.
I don't use all of these programs. Program features are subject to change
without notice. Different versions of a program on the same or different
platforms may have different features. For example, the Macintosh version
might support both encoding and decoding using Binhex, while the Windows
version might support only decoding Binhex, or not support Binhex at all.
If you have more accurate or up-to-date information on these or other major
mail and news programs regarding their support for Attachments, drop
me a note.
I might even update this page with that
information.
-
Eudora Mail
-
Eudora Light (freeware) only supports MIME attachments
-
Eudora Pro supports MIME, Uuencode and Binhex attachments
-
Some versions support HTML.
-
Macintosh users can send AppleSingle or AppleDouble. See the
Macintosh Notes for more information.
-
For additional information, see: Eudora,
FAQ and
More FAQ
-
Forté Agent and Free Agent
-
Free Agent (freeware) is a news reader with limited mail sending abilities.
Agent is a news reader with full POP3/SMTP mail server support
-
Free Agent only supports Uuencode attachments
-
Agent supports both Uuencode and MIME attachments
-
For additional information, see:
Forté,
Unofficial FAQ
-
Microsoft Exchange, Windows Messaging and Outlook97/98/2000 Mail
-
Support MIME and Uuencode attachments
-
Outlook98 and newer support HTML including the
multipart/related. The older programs do not support HTML.
-
MSN Classic users are restricted to Uuencode - see: Notes
on Service Providers
-
If sending messages to users of other mail programs, do Not use RTF (Rich
Text Format). For additional information, see MS-TNEF
-
For additional information, see:
Microsoft and
Slipstick Systems Exchange
Center
-
Microsoft Internet Mail and News (IMN) - companion to Internet Explorer
version 3
-
Microsoft Outlook Express (OE) - companion to Internet Explorer version
4 and 5
-
Supports MIME and Uuencode attachments. The Macintosh version of OE supports
both encoding and decoding using Binhex. The Windows versions of IMN and
OE can decode some Binhex attachments when used with MIME. The Macintosh
version of OE 4.5 can also send AppleDouble. See the
Macintosh Notes for more information.
-
IMN supports Text only HTML. OE has full
HTML support, including the multipart/related.
-
If IMN receives an HTML message without the <BODY> tag, it will display
a blank message. Some mail and news programs (e.g. Netscape 4) do not include
the <BODY> tag by default. One work around is to view the message source.
Another is to ask the sender to use plain text. Still another is for the
Netscape 4 sender to select: Format, Page Color and Properties, Select a
Color. This causes Netscape to create a <BODY> tag since that's where
the color parameter goes.
-
Decoded attachments appear as an icon. You must click on the icon to save
or open the attachment. The operating system file associations determine
the application used to open the attachment. If the preview pane header is
turned off, you might not see any indication of an attachment unless you
Open the message by double clicking it in the list of messages.
-
These programs ignore the "Content-Disposition: inline". The only exception
is that Outlook Express will display attached images in the mail or news
window if that option is selected in Tools, Options, Read. For Digest messages
and messages Forwarded as Attachments, a workaround to speed reading may
be to look at the message source (OE short cut is Ctrl-F3).
-
IMN will not show AppleDouble attachments. Manual Decoding will be necessary.
-
If Uuencode is used with a MIME formatted message, IMN will show the attachment
twice. Although the two instances may show a different file size, either
can be used to save the attachment, and produce identical results.
-
When sending MIME formatted messages, IMN usually provides a Content-type:
application/octet-stream. OE on Windows 95 and above will use the MIME
Content-type from the Windows File Types.
-
These programs ignore the MIME Content-type for received messages with a
couple of exceptions.
-
Content-Type: application/ms-tnef attachments are not decode. For
additional information, see MS-TNEF
-
If a file arrives without a file name extension, one is made up based on
the MIME Content-type from the Windows File Types, or if no match found,
.DAT is used.
-
Uuencode should be avoided if some of the recipients may be using Netscape.
For details, see the Uuencode section.
-
Some users of Microsoft Internet Mail builds 4.70.1160 through 1162 have
a problem where messages with MIME attachments are written to the Inbox.mbx
file, but the mail program doesn't properly update the index and some other
information causing the message to disappear. The problem seems triggered
by some ISP mail servers or sender's mail program. Using Inbox Assistant
seems to avoid the problem. The rules don't have to apply to the problem
messages. If you don't need to use Inbox Assistant for any other reason,
you could create a dummy rule, such as moving all mail for (i.e. To: field
contains) "ABCXYZ123" to the Deleted Items Folder. You should never get a
message with that To: field, so no messages should ever automatically be
moved to the Deleted Items folder. But having a rule, any rule, is sufficient
so that the messages will stop disappearing.
-
For additional information, see:
Microsoft
INM, Microsoft OE,
Eric Miller's User Tips:
IMN and
OE, and
Unofficial Macintosh OE Page
-
Netscape Mail and News
-
Versions 1 to 3 always encode attachments using MIME/Base64. Version 4 also
does this by default. However, version 4 has the option to use Uuencoding
in a MIME formatted message. This should work OK where the recipient's ISP
and/or mail program only supports Uuencode. However, if the recipient's mail
program supports MIME, it may get confused by this, since the use of Uuencoding
with MIME is non-standard.
-
Can decode MIME and Uuencode. Some versions may also decode Binhex.
-
Version 3 supports display of HTML with External images,
but it cannot create HTML messages. It does not support sound. Version 4
and above have full HTML support, including the
multipart/related.
-
The View menu allows the choice of Attachments Inline or As Links. Inline
will automatically display images. As Links is recommended if you just intend
to save the attachment.
-
If Attachments Inline is selected, Netscape version 3 may attempt to play
audio attachments via a plugin. This will fail. You must save the audio
attachments, then play them via the operating system or browser.
-
If a file is attached that is mostly text (e.g. word processing document,
spreadsheet, database), sometimes Netscape will treat it as a pure text file
and insert it in the message without encoding it. The resulting file is unusable.
The workaround is to have the sender compress
the file first, then attach that.
-
If the sender used Microsoft Outlook Express and Uuencoding, Netscape may
incorrectly decode the attachment. For details and workarounds, see the
Uuencode section.
-
For additional information, see:
Netscape and
Unofficial FAQ
-
Pegasus Mail
-
Supports MIME, Uuencode and Binhex attachments
-
For additional information, see:
Pegasus
Top of page Top of
section
Notes on Service Providers
Disclaimer: Information in this section is based on rumor and innuendo.
I don't use all of these services. Service features are subject to change
without notice. Users on the same service may have different software or
versions. The service on different platforms may have different features.
If you have more accurate or up-to-date information on these or other major
services regarding their support for Attachments, drop me a note.
I might even update this page with that
information.
Some of the links below are restricted to members of the service.
-
AOL America Online
-
Users are currently generally restricted to using AOL supplied mail and news
programs with the AOL mail and news servers. A workaround is the
eNetBot AOL Mail POP3-SMTP agent.
-
Always encodes attachments using MIME. Can decode MIME and Uuencode.
-
There is a 1 MB limit per incoming message
-
When sending messags to AOL with attachments do not use HTML and do not attach
more than 1 file per message. If you do, the AOL recipient may get a single
.MIM or .MIME attachment which they will have to use Wincode or similar program
to manually decode.
-
Newer versions of AOL mail may automatically ZIP attachments when sending.
This is most often the case when the message includes multiple attachments.
If the recipient is not an AOL user, they may have to manually unzip the
attachment. For more information, see: Compression
and Message Size Limits
-
AOL users can send pictures by either inserting the picture in the message
body, or attaching as a separate file. The insert picture only works when
going to another AOL user. When sending to other services, AOL removes the
picture and replaces it with the text [Unable to display image]. When
sending to other services, AOL users must use the file attachment method
if they want the recipient to get the picture.
-
For additional information, see: AOL
-
AT&T Worldnet
-
Uses standard POP3/SMTP mail servers and NNTP news servers. Allows the use
of any standard mail or news program.
-
Originally distributed Eudora Light mail. Now distributes Netscape and Microsoft
Internet Mail and News
-
For additional information, see:
AT&T and
Users FAQ
-
CompuServe
-
Optionally uses a standard POP3/SMTP mail servers and NNTP news servers.
This allows the use of any standard mail or news program.
-
The CompuServe supplied mail program supports MIME attachments
-
CompuServe 2000 is based on AOL and the above AOL notes may apply.
-
For additional information, see:
CompuServe
-
Hotmail An e-mail only service
-
Uses a web browser to read and write mail. Microsoft Outlook Express 5 (part
of IE5) can directly access a Hotmail account. For other POP3 compatible
mail programs to access Hotmail accounts, a 3rd party program is needed such
as Relayer.
-
Maximum of 1 attachment per outgoing message with a size limit of 200 KB.
Multiple attachments per incoming message.
-
Most likely supports MIME for attachments
-
For additional information, see:
Hotmail
-
Juno An e-mail service
-
Uses proprietary mail programs. Does not support standard mail programs.
-
The original Free Juno Basic account doesn't support attachments. Might be
able to use manual encoding/decoding and copy/paste the encoded file between
the mail program and an encoder program. Uuencode would probably be the best
choice for encoding. An update to version 2.0 allows MIME attachments.
-
The Juno Gold (about $3/month) and Juno Web (about $20/month) accounts support
MIME attachments.
-
Maximum message size for sending is 3 to 5 MB depending on the version of
Juno. The incoming server mail box is limited to 4 to 10 MB depending on
the version of Juno.
-
For additional information, see: Juno
-
MSN The Microsoft Network
-
MSN Classic users are restricted to using Microsoft Exchange, Windows Messaging,
or Outlook97/98 for e-mail.
-
MSN Metro (version 2.5) adds POP3/SMTP mail server support. This allows the
use of any standard mail program if it also supports Secure Password
Authentication (e.g.
Microsoft
Internet Mail and
Outlook
Express)
-
MSN Classic users are restricted to Uuencode for attachments. MSN Metro users
can use MIME or Uuencode.
-
MSN limits mail messages to about 2 MB. The exact limit depends on the
details.
-
MSN news servers require a news reader that supports logon validation. This
includes Microsoft Internet News and Outlook Express. Reportedly a few other
news readers (Agent?) support this also. I expect that the MSN news servers
can use Uuencode or MIME for attachments, but cannot confirm this.
-
For additional information, see:
MSN
-
Prodigy Internet
-
Prodigy has two services. These notes apply to the newer Prodigy
Internet. E-mail to this service is user@prodigy.net. There is also the
older original Prodigy Classic which uses proprietary software. I
don't know what attachment encoding it supports. E-mail to this service is
user@prodigy.com.
-
Uses standard POP3/SMTP mail servers and NNTP news servers. Allows the use
of any standard mail or news program.
-
Originally distributed Netscape and Microsoft Internet Mail and News. Now
distributes Microsoft Outlook Express.
-
For additional information, see:
Prodigy
-
Yahoo Mail An e-mail only service
-
Uses a web browser to read and write mail. For POP3 compatible mail programs
to access Yahoo accounts, you must sign up for the free Yahoo! Delivers
service which sends some advertising to your mail account. Alternately, a
3rd party program may be used such as
Relayer.
-
Maximum of 3 attachments per outgoing message with a total size limit of
1.5 MB. Multiple attachments per incoming message.
-
Most likely supports MIME for attachments
-
For additional information, see: Yahoo
Mail and Mail Help
Top of page Top of
section
Visitor Count:
Last updated: 2000-08-01
Comments:
file: /Techref/net/prodigy/pages/http/michael_santovec/decode.htm, 85KB, , updated: 2017/3/27 02:09, local time: 2024/8/14 14:03,
|
| ©2024 These pages are served without commercial sponsorship. (No popup ads, etc...).Bandwidth abuse increases hosting cost forcing sponsorship or shutdown. This server aggressively defends against automated copying for any reason including offline viewing, duplication, etc... Please respect this requirement and DO NOT RIP THIS SITE. Questions? <A HREF="http://sxlist.com/techref/net/prodigy/pages/http/michael_santovec/decode.htm"> Decoding Internet Attachments - A Tutorial</A> |
Did you find what you needed?
|
.