Re: "application/octet-stream" Content-Type used to obfuscate terse .RTF spam

[Karsten Bräckelmann <gu...@rudersport.de>]

On Sun, 2009-05-31 at 14:55 -0700, John Hardin wrote:
> On Sun, 31 May 2009, Chip M. wrote:
> 
> > All had a main header Content-Type of "multipart/mixed" with
> > exactly one actual Part with a Content-Type of
> > "application/octet-stream" containing a "name" with the file
> > extension ".rtf".
> 
> Does this catch it?
> 
> mimeheader __UNSPEC_BINARY_ATTACH     Content-Type =~ /application\/octet-stream/i
> meta     MIME_BINARY_ONLY (__CTYPE_MULTIPART_MXD && __UNSPEC_BINARY_ATTACH && !__ANY_TEXT_ATTACH)

Should, IIRC. Have seen em, too, not yet countered, since they scored
appropriately without it. They do look exactly like the previous image
only spams. Just a different attachment.

NOTE:  The above works only, if the previous meta sub-rules for the
image only spam are incorporated locally as well.


Since that RTF crap is pretty plain text, it shouldn't be too hard to
decode the attachment and treat it as a text/* MIME part, with the words
fed to Bayes and the URL harvested for BL lookups. I don't expect that
crap to last for long. If they do, it should be quite easy to stop them
dead.


-- 
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}