On Mon, 20 Jan 2003 04:46:30 -0500 (EST), dman(_at_)nomotek(_dot_)com wrote:
=> Has anyone yet found a base-64-encoded *non-multipart*
=> message that wasn't spam?
=> :0: # 021109 () base-64-encoded html head is shrouding more than charset
=> * ^Content-Type:(.*\<)?text/(html|plain)
=> * ^Content-Transfer-Encoding:(.*\<)?base64
=> spammy
=> regularly grabs 20% of my spam and has not yet (in three months)
false-pozzed.
Unfortunately I have, but just one. It's from an
ex-vendor (manufacturer) to one of my clients. IMO, the vendor
technical staff have been intentionally ignorant of *all* email
related issues in the several years I had to handle their
incoming flow - very frustrating.
This email was mailing list generated to a *registered*
user of theirs - I've *never* known them to spam, so please don't
misread this - this email was legal and legitimate. Here's the
[edited] headers:
~~~~~
Received: from EXAMPLE.com (HELO EXAMPLE.com) (12.2.177.103) by
EDITED-OUT-SERVER with SMTP; 15 Jan 2003 18:14:02 -0000
Date: Wed, 15 Jan 2003 12:28:09 -0500
X-Priority: 1 (High)
Importance: High
From: EXAMPLE_Registered_Owner_Automailer(_at_)EXAMPLE(_dot_)com
Subject: Test Drive EXAMPLE, and You Could Win a Free EXAMPLE
Bundle!
Sensitivity:
Message-ID:
<OFCA8766BA(_dot_)D3B2FC21-ON85256CAF(_dot_)005FF60C(_at_)EXAMPLE(_dot_)com>
X-MIMETrack: Serialize by Router on
DPS-US-MAIL/DigitalProcessingSystems(Release 6.0|September
26, 2002) at 01/15/2003 01:14:02 PM
MIME-Version: 1.0
Content-type: text/plain; charset=UTF-8
Content-transfer-encoding: base64
~~~~~
It hit my spam can. Next time it comes thru, it will do
so again. My base-64 text/plai filters are still in place.
If someone can point me to a good URL explaining why
these folks shouldn't do this (you know a *third-party*
arms-length explanation), I'll pass it along.
Cheers,
- Don
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail