Subject: Re: [SAdev]  New: Certain Base64 bodys not recognized

On Tue, Feb 11, 2003 at 08:23:47AM -0800, bugzilla-daemon@hughes-family.org wrote:
> The message was 

Please _ATTACH_ the message, not cut/paste.

> Date: Sat, 08 Feb 2003 14:14:31 -0500
> MIME-Version: 1.0
> Content-Type: multipart/mixed;
> 	boundary="----=_NextPart_000_28A0_00002428.00003D93"
> ------=_NextPart_000_28A0_00002428.00003D93
> Content-Type: text/html;
> 	charset="iso-8859-1"
> Content-Transfer-Encoding: base64

However, if it actually did come in like this, the answer is simple:
the message is malformed.  There's no seperation between header and body.

Subject: Re: [SAdev]  Certain Base64 bodys not recognized

On Tue, 11 Feb 2003 the voices made bugzilla-daemon@hughes-family.org write:

> ------- Additional Comments From felicity@kluge.net  2003-02-11 08:31 -------
> Subject: Re: [SAdev]  New: Certain Base64 bodys not recognized
>
> On Tue, Feb 11, 2003 at 08:23:47AM -0800, bugzilla-daemon@hughes-family.org wrote:
> > The message was
>
> Please _ATTACH_ the message, not cut/paste.
>
> > Date: Sat, 08 Feb 2003 14:14:31 -0500
> > MIME-Version: 1.0
> > Content-Type: multipart/mixed;
> > 	boundary="----=_NextPart_000_28A0_00002428.00003D93"
> > ------=_NextPart_000_28A0_00002428.00003D93
> > Content-Type: text/html;
> > 	charset="iso-8859-1"
> > Content-Transfer-Encoding: base64
>
> However, if it actually did come in like this, the answer is simple:
> the message is malformed.  There's no seperation between header and body.

 Lately I've seen a lot of malformed MIME; first I thought that we had a new
generation of really stupid spammers (or some broken software), but maybe it's
a new trick for evading spamfilters... Anyone been bored enough to test one of
these messages in Outlook?

Subject: Re:  Certain Base64 bodys not recognized 


Thanks for this.  When I saw the attach page I tried but timed out 
repeatedly.

Anything else I could do to assist with this.  

I would love to /dev/null all malformed emails or at least score them as 
such.  Any other suggestions.  

Porn links embedded in malformed spam delivered to our sup. . . 

OK no more whining.  Any suggestions for workarounds or how else I can 
help appreciated.

Thank you SA gods/goddesses


On Tue, 11 Feb 2003 bugzilla-daemon@hughes-family.org wrote:

> http://www.hughes-family.org/bugzilla/show_bug.cgi?id=1474
> 
> 
> 
> 
> 
> ------- Additional Comments From tony@svanstrom.com  2003-02-11 08:50 -------
> Subject: Re: [SAdev]  Certain Base64 bodys not recognized
> 
> On Tue, 11 Feb 2003 the voices made bugzilla-daemon@hughes-family.org write:
> 
> > ------- Additional Comments From felicity@kluge.net  2003-02-11 08:31 -------
> > Subject: Re: [SAdev]  New: Certain Base64 bodys not recognized
> >
> > On Tue, Feb 11, 2003 at 08:23:47AM -0800, bugzilla-daemon@hughes-family.org wrote:
> > > The message was
> >
> > Please _ATTACH_ the message, not cut/paste.
> >
> > > Date: Sat, 08 Feb 2003 14:14:31 -0500
> > > MIME-Version: 1.0
> > > Content-Type: multipart/mixed;
> > > 	boundary="----=_NextPart_000_28A0_00002428.00003D93"
> > > ------=_NextPart_000_28A0_00002428.00003D93
> > > Content-Type: text/html;
> > > 	charset="iso-8859-1"
> > > Content-Transfer-Encoding: base64
> >
> > However, if it actually did come in like this, the answer is simple:
> > the message is malformed.  There's no seperation between header and body.
> 
>  Lately I've seen a lot of malformed MIME; first I thought that we had a new
> generation of really stupid spammers (or some broken software), but maybe it's
> a new trick for evading spamfilters... Anyone been bored enough to test one of
> these messages in Outlook?
> 
> 
> 
> 
> 
> 
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
> 

Hmmm.  Not sure what to do here.  What do most MUAs do?  If they typically see invalid headers (first boundary marker) and just assume it's got to be body (it's not a header), then they'll display properly.  If they assume it's a header, I guess they may look at the second set of Content-Type as what it should use, and the message will still display properly.My thought is that we ought to look for things like the invalidly formatted header, multiple Content-Type headers, etc, and flag it since no legit mailer would have those.  We should be able to do the #2 option above too (actually, it should do that...)  Actually, we do.  2.50 reports hitting HTML_60_70,HTML_FONT_BIG,HTML_FONT_COLOR_RED,HTML_FONT_COLOR_YELLOW,HTML_FONT_INVISIBLE,HTML_MESSAGE,HTML_WITH_BGCOLOR,MIME_HTML_ONLY,MIME_MISSING_BOUNDARY,NO_REAL_NAME,__CT,__CTE,__EVITE_CTYPE,__HAS_MSGID,__MIME_HTML_ONLY,__MIME_VERSION,__NEXTPART_ALL,__NEXTPART_NORMAL,__SANE_MSGID ...  So BASE64_ENC_TEXT didn't hit, but the message did get unencoded and checked. hmmm.

We already do some tests for malformed MIME irrespective of whether the
messages actually work.  If you think about it, it doesn't matter whether
the trick works.  All that matters is whether it identifies spam vs. ham.

Also, please do not CUT AND PASTE.  Use the Attachment link that's on the
bug page (once the bug has been created).

So, the only questions are:

 - whether this happens often enough to be useful
 - whether it only happens for spam (it's always possible that some
   weird circumstances and broken mailers make this happen often enough
   in ham to make the test non-useful)

I'll put this into my long-term queue.

Created attachment 733 [details]
Sample encoded SPAM

I've been noticing an increase of this form of BASE64_ENC_TEXT spam. Typically
They appear to be properly formed BUT are missing the terminating MIME boundary,
which from my reading of the RFCs in the past is allowed.

I've supplied a recent example.

As a side note, I've also noticed an increase in "short-SPAM" both encoded and
unencoded. In other words, the SPAMmers are making their messages smaller in
order to provide less data to trigger filters. This is sample is an example.

I've added six new base64 tests to HEAD for further testing.  Your sample
base64-encoded spam hits three of them:

T_MIME_BASE64_BLANKS
T_MIME_BASE64_ISO_8859
T_MIME_BASE64_WITHOUT_NAME

The attached spam now hits these rules in 2.60-cvs:

MIME_BASE64_BLANKS
MIME_BASE64_LATIN
MIME_BASE64_NO_NAME
MIME_BASE64_TEXT
MIME_HTML_ONLY

I think I've fixed the bug.  As for the original spam, I never got an
example attachment, so oh well.