base64 transfer encoding defeats rules

[Steven Kiehl]

I just received an email the other day that had mime headers including:

content-type: text/plain
content-transfer-encoding: base64

and the message was encoded in base64, but to the client, it looks like
regular text including a geocities spam message. It was only picked up by
the MIME_BASE64_TEXT rule and I have a rule that blocks geocities spam which
failed to pick up because the text was all in base64.

Is there a way to get rules to pass for both plain and base64 encoded
messages?

My current rule that failed is like this:

body IPBL_6 /geocities\.com\//i
describe IPBL_6 IPBL: Geocities is spam ...
score IPBL_6 5.5

[Loren Wilton]

Is there a way to get rules to pass for both plain and base64 encoded messages?

There are three stages or so to mail decoding:
1 The raw mail body
2 The body after undoing any compression/encoding (base64)
3 The body after any HTML rendering

'body' rules handle case 3.
Both 'full' and 'rawbody' rules handle case 1.
Nothing handles case 2.

Unfortunately all of the rules that detect HTML trickery have to run at step 2. But because rawbody runs on step 1, there is no way to run HTML-detection rules on an encoded email.

I've always considered this a problem, but it seems nobody else does.

Loren

[Theo Van Dinter]

Post by Steven Kiehl
Is there a way to get rules to pass for both plain and base64 encoded
messages?

SA handles quoted-printable and base64 encodings, so yes, already happens.

Post by Steven Kiehl
body IPBL_6 /geocities\.com\//i

Perhaps you want a uri rule instead?

[Steven Kiehl]

body and uri rules fail to work on the email. How do I get a rule to pass
on this message? Here's the message details:

Return-Path: <***@yahoo.es>
Delivered-To: ***@redacted.com
Received: (qmail 1529 invoked by uid 89); 10 Nov 2006 19:17:11 -0000
Received: by simscan 1.1.0 ppid: 1523, pid: 1524, t: 4.4114s
scanners: attach: 1.1.0 clamav: 0.88.5/m:40/d:2133 spam: 3.0.4
Received: from unknown (HELO yahoo.es) (196.200.192.131)
by redac.redacted.com with SMTP; 10 Nov 2006 19:17:07 -0000
Received-SPF: none (redac.redacted.com: domain at yahoo.es does not
designate permitted sender hosts)
Received: from mail.webhostings4u.com ([Sat, 11 Nov 2006 00:01:19 +0400])
by relay.2yahoo.com with ASMTP; Sat, 11 Nov 2006 00:01:19 +0400
Received: from [195.174.170.248] by smtp18.yenddx.com with ESMTP; Fri, 10
Nov 2006 23:44:17 +0400
Received: from unknown (134.251.157.192)
by smtp.mixedthings.net with ESMTP; Fri, 10 Nov 2006 23:31:31 +0400
Message-ID: <***@yahoo.es>
Date: Fri, 10 Nov 2006 23:27:28 +0400
From: "Sal" <***@yahoo.es>
MIME-Version: 1.0
To: "Forum-Members" <***@redacted.com>
Subject: hey redacted
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: base64
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on
redac.redacted.com
X-Spam-Level:
X-Spam-Status: No, score=0.1 required=5.0 tests=MIME_BASE64_TEXT
autolearn=no
version=3.0.4

U1RFVkUsDQpNZWRpY2FsIFJlLWZpbGwgIGlzIHJlYWR5Lg0KDQpodHRwOi8vZ2VvY2l0aWVzLnlh
aG9vLmNvbS5ici94ZXhhZzM5NTEyDQoNCiBUaGFuayB5b3UsDQpTYWwNCg==

Post by Theo Van Dinter

Post by Steven Kiehl
Is there a way to get rules to pass for both plain and base64 encoded
messages?

SA handles quoted-printable and base64 encodings, so yes, already happens.

Post by Steven Kiehl
body IPBL_6 /geocities\.com\//i

Perhaps you want a uri rule instead?
--
"Sex is like air; it's not important unless you aren't getting any."
- Zen Musings

[Theo Van Dinter]

Post by Steven Kiehl
body and uri rules fail to work on the email. How do I get a rule to pass

SA has no problem parsing that message.

Post by Steven Kiehl

Post by Steven Kiehl
body IPBL_6 /geocities\.com\//i

The host in the base64 encoded part is "geocities.yahoo.com.br" which
won't match a rule looking for "geocities.com".