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, Binhex and yEnc.
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.
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.
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.
Microsoft programs largely ignore the Content-Type and give priority to the file extension (the ".gif" in the above example).
See the Notes on Mail and News Programs section for how Outlook Express deals with attachments
which arrive without a file extension.
Some other programs, such as Netscape, give priority to the Content-Type.
(For more information on Content-Type, see:
RFC 2046 and
MIME Types)
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.
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.
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.
as well as MacDisk
yEnc is a newer (2001) encoding format. It is primarily targeted to large binaries in newsgroups, although it could be used in e-mail.
Some news readers support yEnc, but not Microsoft or Netscape.
The main reason for yEnc is its low encoding overhead of about 2%. It does this by using almost all 8-bit characters. However, this
can cause some problems. Some servers can't handle the 8-bit characters, resulting in corrupted messages.
Some servers may automatically convert any messages using 8-bit characters to either
Base64 or Quoted-Printable. This would negate
any size advantage of yEnc as well as complicating the decoding for recipients. This is most likely to happen in a
MIME formatted message.
Below shows how the image to the right might look if using yEnc encoding. The first line starts with "=ybegin".
The following lines are the encoded attachment. The line length is typically 128 or 256 as specified on the
=ybegin line. The last line starts "=yend".
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.
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.
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.
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.
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 lets you save them.
For Netscape Mail, Fentun can be installed as a Helper. Instructions are at the
Fentun web site.
For instructions on using Fentun with the Pegasus Mail program, see:
Pegasus and MS-TNEF.
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, IE4+ Outlook Express, and Windows Live Mail 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.
A version of LS-TNEF for the Mac OS is available at iTools
on the public iDisk of user "jlg" (a free iTools account is required).
TNEF's Enough
Mac Development TNEF's Enough is a Macintosh specific
TNEF decoder.
WMDecode
WMDecode is a Windows specific TNEF decoder. The site also has
WinMail to Extract attachments from winmail.dat files received on the EPOC32/Psion/Symbian Operating System.
Winmail Opener
EOLSOFT Winmail Opener is a GUI and command line utility to deal
with the winmail.dat file (TNEF message), it can extract the RTF message text and any attachments.
It supports Windows 95/98/ME, Windows NT, Windows 2000 or Windows XP.
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 (e.g.
Microsoft and Netscape). Some ignore the Content-type and merely look for the <HTML> tag in the message body to decide
if to interpret the message as being HTML (e.g. Eudora). If your message displays as the raw HTML code (see the sample below)
either your program doesn't support HTML, or the Content-type was wrong. It is somewhat common for mailing lists and spam to
come with a Content-Type: text/plain even though the message contains HTML code.
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.
Some Macintosh files consist of two parts called forks:
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.
A MacBinary file (.BIN) is similar to AppleSingle in that it combines the
data and resource forks in a single file. This isn't a normal attachment encoding but rather is used when transfering Macintosh files
via another operating system as in storing on a file server or web site. There are utilities for extracting the data fork including
StuffIt Expander (see: Decoding Mechanics)
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.
Windows 95 and above may be configured to hide file extensions. This can make it difficult to identify the file type.
This may also make it impossible to change (rename) the file extension of a file in order to fix it.
To have Windows show the file extensions:
Double-click My Computer
Click on the View menu (Win95/98/NT4/Me) or Tools menu (Win2000/XP)
Click on Options (or Folder Options)
In the pop-up window, click the View tab
Then click the "Hide file extensions for known file types"
(or "Hide MS-DOS file extensions for file types that are registered") check box to clear it.
If the file extension is .ZLx (where x is 0-9 or A-Z) or .Z0 or .Z1, or contains DEFANGED-,
see the Viruses section.
However, file extensions are not necessarily unique. The same file extension may be used by different types of files. For
example, a DAT, ATT or TMP 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.
See the Notes on Mail and News Programs section for how Outlook Express deals with attachments
which arrive without a file extension.
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,
yEnc 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
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
RA - Real Audio file has .ra as the first 3 characters of the file
RAR - RAR compressed archive file has Rar! as the first 4 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
SWF - Adobe Shockwave Flash file has FSW as the first 3 characters of the file.
SWF files are normally opened via your browser (e.g. Internet Explorer, Netscape, Opera) and often don't have a file association for opening these from a
mail program. If prompted by Windows to select a program to open an SWF file, select your browser.
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
IrfanView is a free image viewer and converter that can handle most popular image types
including BMP, GIF, JPG, PCX, TIFF, etc.
Once you've determined the correct program to use with a particular file type, you will want to set the file association.
Windows uses the File Associations to select the default program to open a particular file type with. This is used when you
double-click a file to open from the Windows File Explorer or My computer. It's also used by some mail and news programs,
such as Outlook Express and Windows Live Mail. Other mail and news programs, such as Netscape, have their own configuration settings for this.
The setting/changing of the Windows File Associations varies somewhat by the version of Windows. For the specifics see:
Win95,
Win98,
WinMe or
WinMe,
WinNT4,
Win2000 or
Win2000,
WinXP.
If you need to change an option in the file association, such as Confirm Open After Download,
MIME Content-Type, or the Application Used needs a parameter
(for example opening EML or EMAIL files in Outlook Express requires that the application be:
"C:\PROGRAM FILES\OUTLOOK EXPRESS\MSIMN.EXE" /eml:%1 ) you'll need to directly access the
file associations for making the change. Many applications require the "%1" parameter to properly open files
with long file names as often happens when opening attachments from the Temporary Internet Files. As an example
see Cannot Find the File. Although that article
specifically mentions Wordpad on Win95, it applies to many applications on Win95 and newer.
Double-click My Computer
Click on the View menu (Win95/98/NT4/Me) or Tools menu (Win2000/XP)
Click on Options (or Folder Options)
In the pop-up window, click the File Types tab
Scroll down to the desired File Type
Click on EDIT (Win95/98/NT4) or CHANGE or ADVANCED (WinME/2000/XP)
Changes to Confirm Open After Download or MIME Content-Type can be made here. If you need
to change the Application Used, Select the OPEN action, then click EDIT
For Windows VISTA
click Start
enter Folder Options in the Start Search box
then click Folder Options in the Programs list
If you are prompted for an administrator password or for a confirmation, type the password, or click Continue.
click on the File Types tab, then continue as above.
You may run across a problem where you can open a saved attachment by double clicking it, but if you try to open it
from within some mail/news programs, you get an error message that there is no file association for the file type. This is due
to some security changes starting with Windows XP with SP2. Outlook Express, Windows Live Mail and the Vista Windows Mail
programs require that the Windows File Association have an
OPEN Action. Some viewer applications just install a default action such as SHOW or DISPLAY.
Adding an OPEN Action with the same settings as the default action will allow you to open the file from
within these programs rather than having to save the attachment and open that. An example of this problem is
seen with some versions of the PowerPoint Viewer. For that specific case, see:
Unable to open .PPS attachments directly from Outlook Express.
If the MIME Content-Type is missing or incorrect in the File Assocaitions, you generally won't
notice that. However, there are a few cases where it may be important to be correct
Sending attachments from Microsoft programs to non-Microsoft programs
Receiving attachments in Microsoft programs where the file extension is missing
To be able to display GIF, JPG and BMP images in Outlook Express
In the case of Windows XP, the MIME Content-Type setting is not accessible via the File Assocaitions. You need to edit the
Registry. For a REG file that fixes the Content-Type of
common image files types, see: Some types of images don't display
If you are having trouble with file associations, the
FileExtInfo utility will gather all the file association information from
the Windows registry for a specified file extension and save it to a file named FileExtInfo.txt on the desktop. This can be shared with a
technician to help diagnose the problem.
Viruses, Worms and Trojan Horses are programs designed to do things to your computer that you don't want done (e.g.
deleting files, stealing information, sending messages to others, etc.).
Although there are technical differences amongst these, for simplicity they will all be referred to here as viruses.
They are often distributed through Internet Attachments.
In order for the virus to do its damage ("infect" your computer) the instructions that make up the virus must be executed
by your computer. This is done when you Open (run, execute) the file containing the virus in an application that expects
the file to contain instructions, including macros. If you just save the file, or copy it, it won't cause any problems. (However,
you have to be careful, since operating systems make it all too easy to accidentally open a file.) Likewise,
if you open a file in an application that doesn't expect any instructions and therefore won't execute them, this is also safe.
For example, Windows Notepad expects a simple ASCII text file and wouldn't execute any instructions or macros if it found them.
Also, simple image files, such as GIF, JPG and BMP are data only. Image display programs, including browsers and mail programs,
don't look for any instructions in these either, so they are generally safe to open. (An exception occurs if the display program has a bug
whereby a carefully crafted image causes the program to crash and inadvertently execute some of the image as code. For an
example of this and the fix, see: Security Update for JPEG Processing.)
However, Word and files can contain macros, so these are risky to open in their applications. For some additional information on viruses,
including anti-virus programs, see the
Internet Security section of my Technical Help
web page.
To protect yourself from viruses
Never open an attachment unless you specifically requested that attachment from that sender. Knowing
the sender doesn't make it safe. Many viruses, once they infect a computer, send e-mails with virus attachments to people
whose e-mail addresses are found on that computer. So if any of your friends get hit with a computer virus, you likely will get an
e-mail from their computer that contains the virus. Also, many viruses, when they send an infected attachment, often include
in the message subject or body wording along the lines: Here's the file I promised or Take a look at this. Don't fall
for that trick.
Microsoft never distributes software directly via e-mail. If you receive an e-mail with an attachment claiming it's from Microsoft, it's a fake.
Microsoft Policies on Software Distribution
Set Windows to display file extensions. Often Windows is set to hide file extensions. That is risky. A common virus
trick is to send an attachment with a file name such as IMAGE.JPG.exe. That's a program, not a JPG image.
But if Windows is set to hide file extensions, you will see just IMAGE.JPG. For how to have Windows show file extensions,
see the Identifying Attachment File Types section.
If your mail or news program has the option to automatically display images, enable it. True images are safe. However,
if your program is set to display images, but it doesn't automatically display an attachment, you know it's not a true image.
Use the security and virus protection features of your mail and news program. Some things to consider:
Turn off the Preview Pane (typically in the View or Layout menu) in order to select and delete messages
from your list of messages without the mail program trying to open them. You might be able to add a button to your Toolbar to easily
toggle the Preview Pane off and on.
Block potentially unsafe attachments (those that could contain a virus) from opening. See:
Outlook Express 6
Anti-virus programs can help detect and block viruses. However, they won't catch all viruses. So you still have to be
careful with attachments. For some links to anti-virus programs, see the Internet Security
section of my Technical Help web page.
Complications
Measures taken to stop viruses can interfere with attempts to send and receive legitimate attachments.
Some mail servers are configured to block all attachments of types that are prone to viruses (e.g .EXE, .PIF, .DOC).
The server may either remove the attachment, or replace it with a .TXT attachment that contains an explanation of what was done.
Often a notice is added to the message body explaining what was done. In some cases, the entire message is blocked, or returned
to the sender. Corporate and school mail servers are more likely to be blocking attachments, than ISP mail servers. If you get a
message that this is happening or suspect that this is happening contact your mail administrator or ISP for information and
workarounds. You may be able get around this by having the sender ZIP the file before attaching or renaming to another file
extension (e.g. rename PROGRAM.EXE to PROGRAM.XYZ). The recipient will then have to either unzip or rename the file
back before use. As an example, see Hotmail.
Some mail servers are configured to rename all attachments of types that are prone to viruses (e.g .EXE, .PIF, .DOC).
This forces the recipient to save and rename the attachment before using, making it less likely the recipient will accidentally open
a virus. Corporate and school mail servers are more likely to do this than ISP mail servers. For example, some mail servers add
.WARN to a file name (e..g. PROGRAM.EXE becomes PROGRAM.EXE.WARN). The actual renaming pattern varies by mail server
(contact your mail administrator or ISP for more details). As an example of this, mail servers using
The E-mail Sanitizer for Procmail
insert 99999DEFANGED- (the 99999 is a 5 digit number that varies) just after the period in the file name, so that PROGRAM.EXE
could become PROGRAM.12345DEFANGED-EXE.
Zone Alarm's MailSafe feature quarantines attachments with a unique icon.
Also, MailSafe renames the quarantined attachment's extension to .ZL* (the * representing a number or a letter -- either 0-9 or A-Z) or .Z0 or .Z1.
See the program documentation for renaming details.
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.
7-Zip is a freeware Zip and Unzip program. It also handles TAR, RAR, AJR and some other formats.
RAR
RAR is shareware compression program available on a varietry of platforms from
RarSoft. UNRAR is a freeware uncompress program for RAR files available
from the same location.
StuffIt - SIT
Aladdin Systems StuffIt is commonly used on the Macintosh.
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, ARC and ARJ files as well as decode Uuencode and Binhex and extract
MacBinary files.
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.
Other
Other compression methods include ARC and ARJ. These are not commonly used today. Although there are programs available
to specifically uncompress these types of files, often utilites for dealing with other compression methods will also handle
these file types.
As an alternative to e-mailing large files, there are a number of web sites that let you upload your file to them and then send an
e-mail link for the file to your recipient who can then download the file when they desire. This lets you get around the message and mailbox size limits
of the sender's and recipient's ISPs, may result in faster upload and download since encoding is not required and may be more convenient for the recipient.
Such web sites include
dropload.com and
yousendit.com
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).
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,
yEnc 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.
If there weren't problems and complications, you wouldn't be reading this. Many 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. There are several causes of this:
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.
This could be an HTML message and your program doesn't support HTML or the
MIME formatting may be incorrect.
This could be a conflict between Lotus Notes and McAfee SpamKiller. For details, see the comments further down under the item
You see no indication of an attachment
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 and
XFOR: Character Set Not Supported.
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.
A MIME message has a syntax error in the Content-Type: header that confuses the receiving
program. For example Content-Type: text/plain, charset="iso-8859-1" when it should be
Content-Type: text/plain; charset="iso-8859-1". A semicolon is the correct delimiter between parameters, not the
comma.
OLEXP: Message Appears Blank and Has an ATT000XX.txt or ATT000XX.htm Attachment.
Besides the problem described in this article with temporary files, Outlook Express may have a blank message if Internet Explorer is set at View, Encoding to Auto-Select.
If so, disable the Auto-Select in Internet Explorer and choose instead Western European (ISO).
If your program has an option to read HTML messages in Plain Text, the HTML version of the message may appear as an
ATT0001.HTM attachment (the number may vary). See:
Outlook Express 6 and
Outlook 2002.
Instead of a picture attachment, you see a box with a red x as on the right. This occurs when the message includes a link to the image
but the mail or news program is unable to load the image. HTML news letters often have links to a web site for the images. If you are working
offline or do not have an open Internet connection when you read the message, the image will not be able to load. In some cases, the message has
an incorrect link (wrong web site name or file name). And in some cases, the sender intended to include the picture in the message, but did not
correctly configure their mail program to send it. As an example, see:
OLEXP: Image May Not Appear in Message Sent with Outlook Express.
For some additional information and possible causes, see
Pictures Are Not Displayed on Web Sites in Internet Explorer,
Picture Does Not Appear in E-mail Forwarded Through the Internet,
as well as the HTML section.
Instead of a 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.
Your mail server or mail client may be blocking attachments that could contain a virus.
See the Viruses section.
The sender used Lotus Notes and the recipient uses McAfee SpamKiller. Lotus Notes uses a space in
the MIME header Content-Type: multipart/alternative; boundary string. Although this is legal, few other mail programs do that. SpamKiller
when processing the message wraps the header at the space and replaces it with a tab. This causes a number of mail programs to not
recognize the boundary string when it appears later in the message. As a result, the message is not properly processed resulting in missing attachments
and/or an improperly formatted or blank message. The sender's mail program can be determined by looking at the message source or details for the
X-Mailer: or User-Agent: header. SpamKiller also adds headers indicating that it has processed the message.
Similar problems have been reported for the Freedom Anti-virus program distributed by Adelphia modifying the headers of plain text messages.
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.
Another cause of this is if a recipient is using Vodafone GPRS for their Internet connection. The GPRS compression
can replace attachments with a smaller version. For image files this may be tolerable. But for other types of attachments, such
as documents, the resulting file may be unusable and the opening application may report the file as unrecognized or corrupted.
This can also happen if the recipient is using Net Nanny or similar content filtering program and is receiving
a document file such as a PDF or DOC. The filtering software may recognize content to be filtered out and in the process corrupt the attachment.
You see the following or similar message:This message is in MIME format. Since your mail reader
does not understand this format, some or all of this message may not be legible.. This, or similar, message text is inserted
in the message body by some sending programs. If you only see this text while looking at the message source, document source,
or message properties, this is normal and there is no problem. If you see it while looking at the normal message reading window
then either your mail program doesn't support MIME, or more likely, the message headers got corrupted by passing through a
mail server or being forwarded by a mail program that doesn't support MIME. If there are attachments involved you may need to
manually decode them. See the Decoding Mechanics section.
You are unable to open, view, play the attachment. There are a lot of causes to this, many 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.
When you attempt to open an attachment you get one of the following error messages, or something similar:
Program Not Found. Windows cannot find XXXXXXX . This program is needed for opening files of type 'XXX'
or This file does not have a program associated with it for performing this action. Create an association in
My Computer by clicking View and then clicking Options or the OPEN WITH dialog box may open.
In most cases you need to create or fix the Windows File Associaiton for the type of file that you are attempting
to open. See the Identifying Attachment File Types section.
If this is a PowerPoint.PPS or .PPT file and you are using Windows XP with SP2 and
attempting to open the file from within Outlook Express or Windows Live Mail, a registry fix may be needed. See:
Unable to open .PPS attachments directly from Outlook Express.
Other file types may have similar problems. Outlook Express and Windows Live Mail require that the Windows File Association have an
OPEN Action. Some viewer applications just install a default action such as SHOW or DISPLAY.
Adding an OPEN Action with the same settings as the default action will allow you to open the file from
within Outlook Express rather than having to save attachment and open that.
See the Identifying Attachment File Types section.
When you attempt to open an attachment you get the following message: Cannot Find the File
There are several causes of this.
If the problem is with Excel (XLS) files, see:
Unable to Open an Excel Attachment.
Although this article specifically mentions Excel 97, it applies all versions of Excel 5 and newer as well
as all mail clients and versions of Windows.
Many applications require the "%1" parameter to properly open files with long file names
as often happens when opening attachments from the Temporary Internet Files. As an example
see Cannot Find the File. Although that article
specifically mentions Wordpad on Win95, it applies to many applications on Win95 and newer.
The Temporary Internet Files (TIF) may be corrupted. This is used by Outlook Express (version 5 and above)
to save a temporary copy of a file to open it from within Outlook Express. To clear the TIF, in Internet Explorer
select Tools, Internet Options, General, Temporary Internet Files, Delete Files.
In some cases you may need to use the procedure in this article:
Temporary Internet Files Use More Disk Space Than Specified
Or the application set in the Windows File Associations for this type of file might not properly be installed.
See the Identifying Attachment File Types section.
When you attempt to open an attachment you get the following message or something similar:
The file format may not be supported by any of the installed converters. Often this indicates that
you are using the wrong application to open the attachment, and need to change your File Associations.
See the Identifying Attachment File Types section. This could also mean that the file
is corrupted (as an example, see the Vodafone GPRS notes above). Or the next item below may apply.
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, C.DTF, ATT0001.DAT (the number may vary as can the DAT)
or xxxx.ATT (the xxxx varies). The original file name got lost during forwarding of the message or it was intended as an
in-line attachment with no name and the receiving mail program or a server or mail program along the way doesn't
support inline attachments and so generated a name. 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.
This could also be part of an AppleDouble attachment (see Macintosh Notes).
The attachment is named ATT0001.HTM (the number may vary). This can occur
if your program is set to read HTML messages in Plain Text. The HTML version of the message is the attachment. See:
Outlook Express 6 and
Outlook 2002
The attachment is named WINMAIL.DAT, or the Content-Type is application/ms-tnef.
See the MS-TNEF section.
The attachment is named NSMAIL.TMP (there may be some additional characters after the
NSMAIL and before the .TMP). The message came from a Netscape Mail user. You can use a word processor to
view this attachment. This could be a number of things.
A Forwarded Message. In Outlook Express, or Windows Live Mail this would be an EML file. In this case, save the attachment and
rename to an EML name (e.g. NSMAIL.EML). You can then double click it to open in Outlook Express or Windows Live Mail as a mail message.
The attachment is named MESSAGE3.TXT, MESSAGE5.TXT or MESSAGE7.TXT (the number can vary).
This can be a Forwarded Message where the proper MIME Content-Type or file extension got lost, or conflict with each other. One cuase of this is an AOL user
forwarding to a Hotmail user who forwards to someone else. The Content-Type: message/rfc822 may be correct, but the file name picks up a .TXT extension
causing a conflict. In Outlook Express or Windows Live Mail this would be an EML file. In this case, save the attachment and rename to an EML name (e.g. MESSAGE3.EML).
You can then double click it to open in Outlook Express or Windows Live Mail as a mail message.
See the Identifying Attachment File Types section for how to unhide file extensions so that you can rename them.
The file extension is .ZLx (where x is 0-9 or A-Z) or .Z0 or .Z1, or
contains DEFANGED-. See the Viruses section.
You get a PCX attachment where you expected an image such as GIF or JPG. This can happen when a Lotus Notes
user forwards a message with embedded images. The GIF or JPG images get converted to PCX image format. The PCX image format is rarely used
today and the recipient might not have a program capable of viewing it. See the Identifying Attachment File Types section
for a free image viewer. The Lotus Notes user can avoid the problem by changing the setting for messages sent to internet mail users from "Notes Rich Text Format" to "MIME".
Instead of an icon, attachments show as {EMBED Unknown} or {EMBED Outlook.FileAttach}
or {EMBED WordMailFileAttachment}. See this article.
You see the attachment file name, but are unable to select it to open it. Your mail client may be blocking attachments that could contain a virus.
See the Viruses section. This can also occur in Outlook Express if the attachment arrives without an file extension and Outlook Express is
unable to determine the correct file extension. See the Notes on Mail and News Programs section for how Outlook Express deals with attachments
which arrive without a file extension.
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
Microsoft Internet Mail and News (IMN) - companion to Internet Explorer version 3
Microsoft Outlook Express (OE) - companion to Internet Explorer version 4 and above
Windows Live Mail (WLM)
Supports MIME and Uuencode attachments. The Macintosh version of OE supports both encoding and
decoding using Binhex. The Windows versions of IMN, OE, WLM 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.
OEand WLM have 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. If the file name ends in a period, a file
name extension will not be added. This is most likely to occur for messages forwarded as attachments.
These typically use the original message's Subject as the file name. So if a message with a subject such as
Look at This ... is forwarded as an attachment, Outlook Express would not use the MIME type of
message/rfc822 to determine that this should be treated as an EML file. To access the attachment, save the
original message as an EML file (File, Save As), then edit in Notepad to remove the trailing periods in the attachment file name.
Save the edited file and then double click to open or drag-and-drop it back to an Outlook Express folder
(the original unedited message can be deleted). The attachment should now have a suitable file extension.
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.
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.
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.
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.
Uses a web browser to read and write mail. Microsoft Outlook Express 5 (part of IE5) and above and Outlook 2002 (part of Office)
can directly access a Hotmail account. For other POP3 compatible mail programs to access Hotmail accounts, a 3rd party program is needed such
as IzyMail,
Hotmail Popper or
Hotmail Add-Ons
Multiple attachments per message with a 1 MB limit. The purchase of Extra Storage can raise the limit to 3 MB.
Most likely supports MIME for attachments
Hotmail filters out the following types of attachments for both sending and receiving:
ade adp asp bas bat chm cmd com cpl crt exe hlp hta inf ins isp its js jse lnk mdb mde mdt mdw msc msi msp mst
pcd pif reg scr sct shb shs tmp url vb vbe vbs vsd vsmacros vss vst vsw ws wsc wsf wsh
Uses proprietary mail programs. Free version does not support standard mail programs, pay versions do support POP3.
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. Versions 2.0 and above allow MIME attachments.
Maximum attachment size for sending is 2 to 10 MB depending on the version of Juno. The incoming server
mail box is limited to 2 MB to 2 GB depending on the version of Juno.
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 3 MB.
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.
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.
Technical Help
page.
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.
Instead of a picture attachment, you see a box with a red x as on the right. This occurs when the message includes a link to the image
but the mail or news program is unable to load the image. HTML news letters often have links to a web site for the images. If you are working
offline or do not have an open Internet connection when you read the message, the image will not be able to load. In some cases, the message has
an incorrect link (wrong web site name or file name). And in some cases, the sender intended to include the picture in the message, but did not
correctly configure their mail program to send it. As an example, see:
OLEXP: Image May Not Appear in Message Sent with Outlook Express.
For some additional information and possible causes, see
Pictures Are Not Displayed on Web Sites in Internet Explorer,
Picture Does Not Appear in E-mail Forwarded Through the Internet,
as well as the HTML section.