A remote user works on a laptop (Dell Latitude C840, 2.0 GHz CPU, 1 GB
RAM, W2K Pro O/S, Office 2K Pro, Outlook 2000, POP3, Norton 2002
antivirus, PGP full hard disk encryption, Zone Alarm Pro Firewall).

- E-mail's came into his Outlook 2000 account where the original email
was converted to an attachment (called ATT00????.txt) and the email
itself was blank.
- This occurred about 6 months ago for about a week.  It happened
again a week ago for a three days.
- We do not know what is causing it, why it starts and stops randomly
and without any known change or intervention on the user side or the
server side.
- It only happens to him.  No one in the company has this issue.
- It only happens with emails from other company users (who have the
same domain name).
- He received an email as an attachment and then it stopped and the
next email was normal, i.e. not received as an attachment.
- Most users are setup to send HTML emails, but users may set it to
Plain Text, if desired.
- None of the emails during that "odd time" originally had attachments
- We are on Exchange 2000 email server
- This user and the others are all on Outlook 2000
- McAfee ePolicy Orchestrator 3.01 (ePO) as antivirus
- The user in question is on Symantec Norton antivirus 2002.  I just
bought him Norton AV 2004, but this latest issue occurred before I
gave him the software to upgrade.  We were an all Symantec/Norton
house for several years.  All laptops were loaded with Norton.  Later
we switched to McAfee.  Remote users can still get Norton updates
online, so many stayed with Norton.
- We called Microsoft Support, but they did not know.


I need to know:
- Why/What is causing this to happen?
- How/What do we prevent his from occurring again?
- Exactly what steps/measures can we do to fix this issue?
- Why is he the only person this person this happens to?

Here is the research I have found so far:
Internet Exchange News

This paper, by International Messaging Associates, called the Internet
Exchange News was written about IIS 4.0, but even back then they were
aware there was an IIS Exchange - antivirus attachment issue that
needed to be addressed.

http://www.ima.com/pdf/ienews/vol2no5.pdf

File attachment scanning
Since most of the virus scanning software use the filename extension
to invoke the appropriate virus scan routine, the Internet Exchange
4.0 Anti-virus Module is designed to recognize the original file
extension using information available in the message file.

For MIME attachments, the file extension is retrieved from the
internal MIME mapping table. This table stores the mapping between
Content-type and the associated file extension of the attachments. 
For non- MIME messages, the filename is retrieved in the following
sequence:
? If the attachment is UUENCODED file, the Antivirus Module will use
the filename from the "BEGIN XXX <filename>" line.
? If the attachment is a BINHEX encoded file, the filename from the
decoded BINHEX segment header will be used.
? If the "filename" parameter is present in the "Content-Disposition"
header, the Anti-virus Module will use the value of "filename"
parameter as the attachment filename.
? If the "name" parameter is present in the "ContentType" header, the
value of the "name" parameter will be used as the attachment filename.
? If the attachment cannot be determined even after the checks above,
the anti-virus module will do a lookup to find the corresponding
filename extension from the Content-type header (if it is present in
the MIME message) and assign a dummy name to the attachment.
? If all the above procedures have been performed and the file
extension still cannot be determined, the Anti-virus Module will
assign a <DEFAULT> value as the file extension. This value is
configured by the gateway administrator.

When viruses are detected, the anti-virus engine handles the message
based upon the option chosen by the Internet Exchange administrator.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I did find the ATT issue (ATT00????.txt) referenced at Symantec, but
it is mentioned in relation to Outlook.


Norton AntiVirus 2004 for Windows 2000/Me/98/XP
Email attachments sent from an Outlook 97 client are renamed by Norton
AntiVirus for Gateways 2.5 to Att00000.att
Situation:
When an email attachment from an Outlook 97 client is infected or
blocked by Norton AntiVirus for Gateways (NAVGW) 2.5, the file
normally created is Deleted#.txt. This file is not being named
correctly and will have a name similar to Att00000.att. You want to
know why this is happening.

Solution:
The renaming of infected or blocked Outlook 97 attachments when NAVGW
is scanning is a limitation of Outlook 97. Outlook 97 does not provide
NAVGW with a name field. The Deleted#.txt file is created but the not
correctly named. The name will be similar to Att00000.att.


I have found this issue mentioned on Google Groups going back six (6)
years: "...Outlook displays a blank email with the HTML message as an
attachment beginning with ATT00..." and "The 'ATT' extension indicates
that the MIME header generated by the sending client is missing some
information that Outlook needs."  1998/07/15

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`
At Microsoft I found this tantalizing bit of information:
XFOR: IMC Packages Failed Messages in ATT, DAT, or TXT
This article was previously published under Q146263 
SUMMARY
The Microsoft Exchange Internet Mail Connector (IMC) creates a file
and copies failed messages to the file. The file has an ATT, TXT, or
DAT extension. The file extension assignment is done in the following
manner:
If an inbound conversion fails, the raw message is copied to a file
with the TXT file extension. For example, the file name can be
Att00xxx.txt.

MIME messages. If a parameter is not found in the headers that can be
used as an attachment name, IMC creates a file with the ATT file
extension (either from the MIME Type configuration or Content-Type
header information). If the MIME Content-Type is configured in the
property page, the file with the ATT file extension is used. If the
Content-Type is not configured, the file with the DAT file extension
is used.

If no file name information is detected for non-MIME messages (in
X-MS-Attachment header or Begin header) and the body part is a
UUENCODED body part, IMC creates a file with the DAT file extension.
The information in this article applies to:
Microsoft Exchange Server 4.0
Last Reviewed: 10/1/2003 (3.0)  
Keywords: kbusage KB146263 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`

XIMS: Exchange Displays Message That Uses "Inline" MIME
Content-Disposition Header as Attachment
This article was previously published under Q323482 
 
SYMPTOMS
Exchange 2000 displays a message that is set to "inline" as an
attachment instead of as the message content in the main body of the
message.
 
CAUSE
This behavior occurs if the MIME Content-Disposition header of a
multipart message is set to inline and the filename= parameter is
used.
 
RESOLUTION
To resolve this issue, do not use the filename= parameter when you
compose multipart messages in which the MIME Content-Disposition
header is set to inline.
 
MORE INFORMATION
Content-Disposition is an extension to the MIME protocol that
describes the content of the message and provides instructions about
how the content is to be displayed.

When the MIME Content-Disposition header is set to inline, Exchange
2000 presents the content immediately to the user when the message is
viewed, by displaying it in the main body of the message.

When the MIME Content-Disposition header is set to inline and uses the
filename= parameter, Exchange 2000 presents the content as an
attachment that is separate from the main body of the message. To view
the attachment, the user must take more action.

For example: 
Content-Type: multipart/mixed;boundary="server-part-0000-00000001"
Content-Type: text/plain; charset=US-ASCII; name="Bdy.txt"
Content-Disposition: inline; filename="Bdy.txt"
Content-Transfer-Encoding: 7bit
"This message should be displayed immediately to the user"
--server-part-000-00000001
Content-Type: application/msword; name="Test.doc"
Content-Disposition: attachment; filename="Test.doc"
Content-Transfer-Encoding: base64 
 
This behavior is in compliance with the Request For Comments (RFC)
2803 and 1806. For more information about RFC 2183 and 1806, visit the
following Internet Engineering Task Force (IETF) Web sites:
http://www.ietf.org/rfc/rfc2183.txt
http://www.ietf.org/rfc/rfc1806.txt
The information in this article applies to:
Microsoft Exchange 2000 Server
Last Reviewed: 6/13/2003 (1.1)  
Keywords: kbprb KB323482 


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
XFOR: IMC Packages Failed Messages in ATT, DAT, or TXT
 
This article was previously published under Q146263 
 
SUMMARY
The Microsoft Exchange Internet Mail Connector (IMC) creates a file
and copies failed messages to the file. The file has an ATT, TXT, or
DAT extension. The file extension assignment is done in the following
manner:
 
- If an inbound conversion fails, the raw message is copied to a file
with the TXT file extension. For example, the file name can be
Att00xxx.txt.

 
- MIME messages: If a parameter is not found in the headers that can
be used as an attachment name, IMC creates a file with the ATT file
extension (either from the MIME Type configuration or Content-Type
header information). If the MIME Content-Type is configured in the
property page, the file with the ATT file extension is used.  If the
Content-Type is not configured, the file with the DAT file extension
is used.

- If no file name information is detected for non-MIME messages (in
X-MS-Attachment header or Begin header) and the bodypart is a
UUENCODED bodypart, IMC creates a file with the DAT file extension.
 
The information in this article applies to:
Microsoft Exchange Server 4.0
Last Reviewed: 10/1/2003 (3.0)  
Keywords: kbusage KB146263 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`
Internet Mail Message Delivered as Attached Text File
 
This article was previously published under Q161044 
 
SYMPTOMS
When you receive an e-mail message sent from Microsoft Internet Mail,
it may contain an attached file with an .att or .txt extension. In
some cases, a plain text version of the message may also be included.
 
CAUSE
This behavior occurs when any of the following conditions exist: 
You are using Microsoft Exchange with the Internet Mail information service. 
You are using the client for Microsoft Exchange Server. 
Your Internet service provider's mail server does not recognize the
content type of the Internet Mail message.
 
RESOLUTION
To work around this problem, send your mail using plain text format.
To do this on a per-message basis, follow these steps:


While you are composing a new message, click Plain Text on the Format menu. 
Click OK if you receive a message stating that you will lose the
HyperText Markup Language (HTML) information in the message you are
composing. This message is displayed if you were previously using HTML
format instead of plain text format.
 
MORE INFORMATION
This problem typically occurs when you send mail using Internet Mail's
HTML format. Many mail servers do not recognize the
Multipart/Alternative Multipurpose Internet Mail Extensions (MIME)
content type. The IMS will only send Multipart/Alternative if the
administrator checks both the HTML and the Plain Text check boxes. If
you configure the IMS to only use HTML, it will send text/HTML.

There are two parts to an Internet Mail message: a text/plain part and
a text/HTML part. Multipart/Alternative content type includes multiple
representations of the same data.

When the server or client you use to read mail receives this MIME
type, the results may vary. Some clients display the text/plain part
correctly and put the text/HTML part into an attachment. Others put
the entire message into an attachment. The name of the attachment
depends on your server and client combination.
The information in this article applies to:
Microsoft Internet Mail and News 1.0 for Windows 95
Last Reviewed: 10/2/2002 (1.0)  
Keywords: kbenv KB161044 

 
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`
XFOR: Unexpected Text Attachment in Mail Received from Internet
 
This article was previously published under Q153464 
 
SYMPTOMS
When you receive mail by way of the Internet Mail Connector (IMC),
there is a file attachment with a name such as ATT00000.txt; the
attachment contains only text.
 
CAUSE
A multipart/mixed MIME document is received that contains more than
one text section. Only the first text section appears in the message
body; all remaining text sections are interpreted as text file
attachments.
 
STATUS
Microsoft has confirmed this to be a problem in Microsoft Exchange
Server version 4.0. This problem has been corrected in the latest U.S.
Service Pack for Microsoft Exchange Server version 4.0. For
information on obtaining the Service Pack, query on the following word
in the Microsoft Knowledge Base (without the spaces):
 
S E R V P A C K

Microsoft has confirmed this to be a problem in Microsoft Exchange
Server version 5.0. This problem has been corrected in the latest U.S.
Service Pack for Microsoft Exchange Server version 5.0. For
information on obtaining the Service Pack, query on the following word
in the Microsoft Knowledge Base (without the spaces):
 
S E R V P A C K 
 
MORE INFORMATION
This happens most commonly with an Internet mail client that is
sending an attachment and also appending an auto-signature. For
example, here is a fragment of a multi-part mime message:

Content-Type: multipart/mixed; boundary=
"=====================_856378041==_" 
Content-Type: text/plain; charset="us-ascii" 

This sentence will be seen in the body of the message. 

--=====================_856378041==_ 
Content-Type: application/msword; name="WORD.DOC"; 
x-mac-type="42494E41"; x-mac-creator="4D535744" 
Content-Transfer-Encoding: base64 
Content-Disposition: attachment; filename="WORD.DOC"
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAOwADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQA
AAAAAAAAA
<Base64 MIME Encoding - Removed for Brevity> 
/v8JAAYAAAAAAAAAAAAAAAEAAAABAAAAAAAAAAAQAAACAAA= 
--=====================_856378041==_ 
Content-Type: text/plain; charset="us-ascii" 

This paragraph will be seen in the text file attachment. Frequently
this text contains the auto-signature text sent by Internet mail
clients, such as Eudora Light 3.0.

--=====================_856378041==_-- 


The information in this article applies to:
Microsoft Exchange Server 4.0 
Microsoft Exchange Server 5.0
Last Reviewed: 10/30/2003 (3.0)  
Keywords: kbbug kbfix kbusage KB153464 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`
 
I don't mind the removal of cryptographic signatures, Win32 executable
content, and ATT00*.TXT attachments from mailing lists. After an
*extremely* quick browse through the archives, I unsure of whether we
block executable content. It's probably a good idea for a non-Win32
mailing list...  ATT*.TXT attachments are usually caused by the mail
list not wanting to break the signed emails, so they can go easily
enough.
http://mail.plug.linux.org.au/pipermail/plug/2004-June/053667.html
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`
I often read this list in Outlook Express, since I still spend more
time in Windows (haven't gotten Linux to work well with my video card,
so until I upgrade...), and noticed that some messages appear blank,
but have an attachment that outlook has named ATT00###.py (where ###
is a number).

The first time I saw this, I thought it was a worm of some sort
distributing Python scripts, but when I looked at that attachment it
contained the body of the message.

In each case, the headers revealed that the mailer used was Sylpheed.
(Example message, today, from Charles A. Edwards re. Intellimouse).

I also noticed his message had the following Mime header:

:: Mime-Version: 1.0
:: Content-Type: multipart/signed; protocol="application/pgp-signature";
::  micalg="pgp-sha1";
::  boundary="Signature=_Mon__24_May_2004_22_28_18_-0400_EG0sF5HbG3/RPIn1"

Anyway, I thought this might be of interest, since Outlook is such a
popular mailer, and it's probably desirable to have messages readable
there.

Any ideas what's causing this? (The short answer is probably
Microsoft's broken mailer, but...)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~