Scott, I've seen some FP's (or possibly rather just simply legit mail)
tagged for BASE64 coming from AOL 8 (maybe others) when there is an
attachment and no text in the body of the message. I'm wondering if
this is possibly a bug in the BASE64 test, and if so, could/should it
be fixed? An example follows with the base64 stuff removed (I have
three of these in a series of communications):
From <--SNIP--> Thu Sep 18 14:18:18 2003
Received: from imo-r05.mx.aol.com [152.163.225.101] by
--SNIP-- with ESMTP
(SMTPD32-7.13) id A6E61E30048; Thu, 18 Sep 2003 14:18:14
-0400
Received: from --SNIP--
by imo-r05.mx.aol.com (mail_out_v36_r1.1.) id
t.18e.1fcf6cb4 (4254)
for <--SNIP-->; Thu, 18 Sep 2003 14:18:06 -0400
(EDT)
From: --SNIP--
Message-ID: <[EMAIL PROTECTED]>
Date: Thu, 18 Sep 2003 14:18:05 EDT
Subject: (no subject)
To: --SNIP--
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="part1_18e.1fcf6cb4.2c9b50dd_boundary"
X-Mailer: 8.0 for Windows sub 6018
X-Declude-Sender: --SNIP-- [152.163.225.101]
X-Declude-Spoolname: Df6e601e300480dfe.SMD
X-Note: This E-mail was scanned by iGaia Incorporated's E-mail
service (www.igaia.com) for spam.
X-Note: This E-mail was sent from imo-r05.mx.aol.com
([152.163.225.101]).
X-Spam-Tests-Failed: NOABUSE, NOPOSTMASTER, IPNOTINMX,
NOLEGITCONTENT, BASE64, GIBBERISH, ANTIGIBBERISH, ATTACHMENT [0]
X-RCPT-TO: <--SNIP-->
Status: U
X-UIDL: 363643585
--part1_18e.1fcf6cb4.2c9b50dd_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
--part1_18e.1fcf6cb4.2c9b50dd_boundary
Content-Type: application/zip; name="mini.ZIP"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="mini.ZIP"
YADDAYADDAYADDA/BASE64STUFF
Thanks,
Matt
|
