Created attachment 1906 [details]
uuencoded message

here is an example from march..  i see more of these messages that i would
think.	 when people call, i guesss you tell them we no longer support their
mail client

in this case, the email was sent with an old 95 exchange mailer of some kind.

oh well :)

Subject: Re:  New: SA doesn't ignore UUEncoded attachments in message body

On Sat, Apr 17, 2004 at 02:24:45AM -0700, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> SA ignores and strips out binary MIME attachments.

Well, SA ignores them.

> However, it doesn't do the same thing for UUEncodeed binary files.

Of course not, we don't alter the message when processing.

MIME attachments are attachments, and can be ignored appropriately.
UUencoded blocks are part of the text section of the message content
and would require altering the message.  How's this for UUencode?

begin 600 spam.txt
M_____________BUY_VIAGRA_FROM_ME_____________________________
M___VISIT_WWW.MYVIAGRA.NET_TODAY_____________________________
end


... not to mention the fact I can send you any kind of encoding I want
in the text part.  Should we strip this out?

YmVnaW4gNjAwIHNwYW0udHh0Ck1fX19fX19fX19fX19fQlVZX1ZJQUdSQV9GUk9NX01FX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KTV9fX1ZJU0lUX1dXVy5NWVZJQUdSQS5ORVRf
VE9EQVlfX19fX19fX19fX19fX19fX19fX19fX19fX19fXwplbmQK

we don't alter message content...

What you showed isn't UUEncoding, it is message content.

UUEncoding is easily recognizable as such.  Virtually all MTAs in existance are 
capable of recognizing it and showing it as an attachment.

Admittedly some may recognize certain forms of UUE file name (such as .doc) and 
show it as part of the message body.  But there are MTAs that take Theo's 
attached text file replies and show them directly as the message body rather 
than an attachment.  I know of no mailers that recognize UUEncoding that will 
show a UUEncoded zip file as part of the message body.

Since I've seen comments that SA is supposed to work like common MTAs, then it 
is violating that rule/guideline/whatever by treating an obvious attachment as 
body text when few other MTAs would do so.

Yes, UUE is not a mimepart, since it predates the MIME RFCs.  It is nonetheless 
a recognizable encoded attachment.  If you don't want to delete the body text 
(even if it is an executable) then you should at least decode it first, as you 
do with Base-64.

Since however, the purpose of SA is to detect spam by the application of RE 
rules, I can't see why you would deliberately adopt a policy that negated those 
very rules by generating FPs on valid ham.  

I'm sure you will claim that if you strip UUE that a spammer could use it to 
hide a message.  This is so.  It is also true that a spammer can hide a message 
in a base-64 encoded gif file, and yet you strip those out rather than applying 
the body rules to the base-64 encoded gif image.  

If you don't want to either strip out or decode UUE parts of a message, then 
you should apply the same rules to other binary attachments, and run the body 
rules on them too without decoding.  Otherwise you are being inconsistant and 
saying that body rules should be applied to some encoded non-text message parts 
but not others, even though a typical MTA would not handle the message that way 
for presentation.

Modification to my last post:

I said what you had in the message was hex in the message body and not a valid 
UUEncoded body, which was easily recognizable.

I see now I was wrong, you had both.

The problem was that my MTA (Outlook Depress in this case) recognized the UUE 
as an attachment and presented it to me as an attachment, removed from the 
message body.  Thus I didn't see the UUE header, trailer, nor body, and the 
spam attempt failed since I didn't notice the attachment and open it.

Subject: Re:  SA doesn't ignore UUEncoded attachments in message body

On Sat, Apr 17, 2004 at 02:24:02PM -0700, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> UUEncoding is easily recognizable as such.  Virtually all MTAs in existance are 
> capable of recognizing it and showing it as an attachment.

Well, MTAs won't, MUAs might.  But most don't.

> I'm sure you will claim that if you strip UUE that a spammer could use it to 
> hide a message.  This is so.  It is also true that a spammer can hide a message 
> in a base-64 encoded gif file, and yet you strip those out rather than applying 
> the body rules to the base-64 encoded gif image.  

Well, we don't scan graphics at all, so there's nothing lost there.  There are
tons of spam graphics that we don't scan.

I'm more worried about spammers hiding in the text uuencode than I am
in the binary graphic -- they have to make the graphic viewed somehow,
which we catch since it's text/html...

> If you don't want to either strip out or decode UUE parts of a message, then 
> you should apply the same rules to other binary attachments, and run the body 
> rules on them too without decoding.  Otherwise you are being inconsistant and 
> saying that body rules should be applied to some encoded non-text message parts 
> but not others, even though a typical MTA would not handle the message that way 
> for presentation.

No...  uuencode is non-encoded text (as far as the message is concerned).
base64 is encoded binary (in the case of a graphic anyway).  mime
attachments can specify type, uuencoded inserts can not.  we don't ignore
base64 encoded text parts, how would we do that with uuencoded sections?
do we add in an attachment node for uuencode stuff?  if so, what type
of attachment is it?  do we have to decode it first, then attempt to
figure out what kind of file is enclosed?

To reverse your argument: those MUAs which may see uuencoded as an
attachment can't send as uuencoded, they'll send as MIME attachments.
uuencoded files are deprecated by MIME at this point.

> Thus I didn't see the UUE header, trailer, nor body, and the 
> spam attempt failed since I didn't notice the attachment and open it.

most MUAs will not do that though.  mine, for instance, shows me the uuencoded 
section, so the spam attempt succeeded.

people sending uuencoded files these days are few and far between, I'm not going 
to break our policy of "don't edit the message content" unless there's some 
serious need to do so.

Created attachment 1908 [details]
OE Display of message containing "spam" UUE part

This shows the display of felicity's reply containing the UUEncoded "spam",
showing that OE deleted the UUE from the message body and displayed it as a
text-file attachment.  Thus OE at least (and I also know Outlook) treat a UUE
part as a attachment and NOT as part of the body text.

Today I had a false positive because of this, and it listed:

X-Spam-Report:
        *  0.0 NO_REAL_NAME From: does not include a real name
        *  1.3 SUBJ_HAS_UNIQ_ID Subject contains a unique ID
        * -0.5 ALL_TRUSTED Did not pass through any untrusted hosts
        *  3.1 OBSCURED_EMAIL BODY: Message seems to contain rot13ed address
        *  2.8 UNWANTED_LANGUAGE_BODY BODY: Message written in an undesired lang
uage
        *  0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60%
        *      [score: 0.4951]
        *  0.0 UPPERCASE_50_75 message body is 50-75% uppercase

The "OBSCURED_EMAIL BODY", "UNWANTED_LANGUAGE_BODY BODY" and "UPPERCASE_50_75"
are all caused by matches in the uuencoded part, I think.

SpamAssassin should first decode the uuencoded part (as it does with base64
encoded text) before it attempts to scan patterns in it.  The raw uuencoded data
just contains too many spam-like properties.

Probably only the relative rareness of uuencoding these days alleviates the
problem caused by the nonhandling of it.