Filtering Spam encoded as base 64

[Light Speed]

I receive one or two spams a day that have Content-Transfer-Encoding: base64.

They have the source body code all jumbled up so I cannot use a body filter on these spams. Is base 64 a type of encoding that does this jumbling? It seems that I have never had a normal email arrive encoded this way only spam.
I have a Cpanel account so I am using the email filter built into cpanel and before I try to block all Content-Transfer-Encoding: base64 emails I wanted to ask if anybody here would recommend against it. Who elso outside of spammers would encode an email this way?

Here is a sample of this spam

WARNING: don't click any of the links

Body viewed in email client:
====================================
The ultimate digital cable filter

The filter will allow you to receive all the channels that you order with your remove control!

payperviews, adult movies,sport events,special events! see now! <http://ipsilateral:froze@<a href="ht...nutritious</a>>

<http://tradesman:jupiter@<a href="ht...mmunicable</a>>

====================================


Source of same email:
====================================
Return-path: <31usbexp@aol.com>
Envelope-to: Removed for Privacy
Delivery-date: Sun, 26 Oct 2003 23:25:31 -0500
Received: from [66.24.28.127] (helo=bgm-66-24-28-127.stny.rr.com)
by cpanel3.nocspeed.com with smtp (Exim 4.24)
id 1ADywc-0006HZ-I7
for Removed for Privacy; Sun, 26 Oct 2003 23:25:30 -0500
Received: from [9.51.24.176] by bgm-66-24-28-127.stny.rr.com with SMTP; Mon, 27 Oct 2003 02:18:46 -0200
Message-ID: <qb8760p4cb8lln4m5@74hu9>
From: "Kristin Robinson" <31usbexp@aol.com>
Reply-To: "Kristin Robinson" <31usbexp@aol.com>
To: Removed for Privacy
Subject: Re: discovering these treasures rv adxwqxjn h
Date: Mon, 27 Oct 2003 02:18:46 -0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="587F66A23AA4F_..3D"


--587F66A23AA4F_..3D
Content-Type: text/html;
Content-Transfer-Encoding: base64

PGJvZHk+PGdrbmFkZHRicWVldG4gDQprYWxtbXN0cCBqamF2IG 4gcmtvdnlrag0KIGZhIGFt
az4NCjxwPlQ8L2Zsb3V0PmhlIHVsPC9rYXJvbD50aW1hdGUgZG lnaTwvY3J5c3RhbGxvZ3Jh
cGh5PnRhbCANCmNhYjwvcmFkaW9hc3Ryb25vbXk+bGUgZmk8L3 JlY3VzZT5sdGVyPC9wPg0K
PHA+VGg8L2ZhYT5lIDxpbnB1dCByenlqa3FodiB3ZiBxIHp5cm 8gIHR5cGU9ImhpZGRlbiIg
DQp2YWx1ZT0ic2RhdHN6cA0KdmNvZXl4d2N2bSAgcyAgcnAgb2 5penZ6b210d2h2cGh5dmxu
IGsNCnZ5IHRzY3p1bnANCml2am1rZ3QgcHEiPmZpPC96b3VuZH M+bHRlciB3PC9hbnRpdGhl
dGljPmlsbCBhbDwvZXF1aXA+bG93IA0KeW88L2F6aW11dGhhbD 51IHQ8L21pbm5vdz5vIHJl
PC9hbGlzdGFpcj5jZWl2ZSBhbDwvYmFwdGlzdGVyeT5sIA0KdD wvc2F1dGVybmU+aGUgY2hh
PC9hbnRvbj5ubmVscyB0aDwvdHdvPmF0IHk8L2Rlc2VjcmF0ZT 5vdQ0Kb3I8L3N3aW5nYWJs
ZT5kZXIgd2k8L21hcmxpbj50aCB5bzwvYXVndXN0YT51ciByZW 1vPC9pY29zYWhlZHJhbD52
ZSANCmNvbjwvcmVtb3JzZT50cm9sITwvc29kaXVtPjwvcD4NCj xwPnBheTwvbmVvY29uc2Vy
dmF0aXZlPnBlcnZpZXdzLCBhZHU8L2Jyb3duaWU+bHQgbW88L2 JlZGZvcmQ+dmllcyxzcG88
L3RlYWt3b29kPnJ0IA0KZXY8L3dheGVuPmVudHMsc3BlPC9iYW Nrc2NhdHRlcj5jaWFsIDxp
bnB1dCBjZHkgIHppIHZqZ2prbHRmYW1peQ0Kd3h5emxpIHB3Yn ANCmlsZWQgbXhzb3ZiIG0g
YmsgICB6Z2wNCmxjIGVhDQpqb3ZxYw0KaHZ3ZiB0eXBlPSJoaW RkZW4iIA0KdmFsdWU9Imxh
cmhobmtjdyBnY3drbmkgDQogaW96a2UiPmV2PC9waWV6b2VsZW N0cmljPmVudHMhPGEgaHJl
Zj0iaHR0cDovL2lwc2lsYXRlcmFsOmZyb3plQHd3dy5laG9zdH p6Lm9yZy9jYWJsZS8/bnV0
cml0aW91cyI+DQpzZTxidXJndW5kaWFuPmUgbm88L2JldG9rZW 4+dyE8L2E+PC9wPjxwIGxr
d2Fyc3RvdHVrdWx6cWdqIHYgDQpvaWwgempoY3V6a253IA0KYn VzdmFzbCBleWRsIHdmZ3Fz
IGZiDQp1ICBiciBiZWd6am1ocXYgeSBoeWd2Z3NyZXdibiBqdT 48YSBlcmNkZSB2DQogZ3pq
ZXUNCm8geHBoeg0KbyBoZCANCnBkbiAgenRtdiBocXhrZHJydH h6aWogY2txZXB1IGx3eCAg
Z2JldCBzdHB0ICANCmhyZWY9Imh0dHA6Ly90cmFkZXNtYW46an VwaXRlckB3d3cuZWhvc3R6
ei5vcmcvY2FibGUvP2NvbW11bmljYWJsZSI+PGlucHV0IG9uZW x6eWl6DQppZHQgYm93bHkN
CmENCnVyaG5meWZvIA0KdHlwZT0iaGlkZGVuIiB2YWx1ZT0iZy Bwa3l3ZyBubXBsIHJhempv
Y29ldWV4eXpwZA0KaGtjcW9ydiANCmwgZ2piIG92DQpobXkgZ2 R1cm0gcGRrIHBpaW52YnRi
eQ0KIHZ5dWsgDQptbXp4b2t4YW9hZGRrZw0KbiAiPjxpbWcgb2 hiYXN3IGhqeGVkZGRkcnJ0
YWhhaGxlbSAgZXAgaWFieWVjbA0KY2ppZiBuaHR4cWh6YyBpd3 B6IGQga2ZjYiBtIHYgdHRv
YmVidHVsdXRjbXRuanJ4cmkgYm9yZGVyPSIwIiANCnNyYz0iaH R0cDovL3d3dy5laG9zdHp6
Lm9yZy9maXRlcjEuanBnIj48L2E+PC9wPg0KPC92bGppdSB0eC BrcyB1bmN3cHFwZnRjdXBz
cWxoICBlYXF0cW1wYWp2YWNxcWtsZWF0bHBpcWV4bW1hcXIgdX VtYXFqbg0KDQpxbGZzcXh3
aHNhamlwcGpoYW56aWtpPjwvYm9keT54eW9jZGFhICA=



--587F66A23AA4F_..3D--

====================================

Base64 is an industry-standard MIME encoding--virtually every file attachment sent through e-mail uses it, spam included, so there's nothing in the least unusual about it. Content-Transfer-Encoding is legitimate and laid out in RFC 1521.

Actually, I just re-read it and it is, technically, completely normal. Any e-mail with an attachment, HTML or other, will look similar.

[Light Speed]

Thanks Alex

I'm glad I asked because I have only been routinely checking source on spam and not my legit emails and most of the spam was 7bit or 8bit encoded and I didn't make the connection that 64 was for attachments. DOH!

Looks like I won't be filtering that

I guess there isn't a way to filter these specific spams then as the sender is spoofed and I didn't really want to start filtering IP blocks. If it gets bad I may have to do that.