Re: Image spam and failing rule
On Sun, 26 Apr 2009, Theo Van Dinter wrote: It's already been mentioned, but mimeheader is the right way to look at the headers of MIME parts. Look more closely at my rule. It is checking for TWO headers, one after the other (separated by \n), identifying a gif with no name. full /Content-Type: image\/gif;\n[^a-z]+name=/ But yes, I will be keeping 'mimeheader' in mind for tests like the simple 'DS[LC]' png check. :) - Charles
Re: Image spam and failing rule
Theo Van Dinter wrote: It's already been mentioned, but mimeheader is the right way to look at the headers of MIME parts. Charles Gregory wrote: Look more closely at my rule. It is checking for TWO headers, one after the other (separated by \n), identifying a gif with no name. full /Content-Type: image\/gif;\n[^a-z]+name=/ I think you’ll find that’s one header on two lines, and mimeheader copes with it. Hope this helps, James. -- E-mail: james@ | “As for Nitel, the state telephone monopoly, the less aprilcottage.co.uk | said the better, which might well be the company’s | motto.” | -- The Economist, about Nigeria
Re: [sa-list] Re: Image spam and failing rule
On Sun, Apr 26, 2009 at 04:11:10PM -0400, Dan Mahoney, System Admin wrote: On Sat, 25 Apr 2009, John Hardin wrote: On Sat, 25 Apr 2009, Gary Forrest wrote: We are receiving the same image spam many times, random text within the body. FuzzyOCR. It seems Spammers are trying image spam again, after giving up on it for a year or so. Is there a version of FuzzyOCR that's actually supported with the current SA release? Or under active development at all? As I said on the other post, there were no significant image spam for years. Why would anyone want to waste time on developing it? Mostly that stuff comes from botnets anyway, which you can easily block even at MTA. The author (decoder) read this list, maybe he will reply if he has any thoughts.. if image spam is coming to another wave, maybe the developement and mailing list will be refreshed.
Re: Image spam and failing rule
While you are at it, you can also scan for full /Content-Type: image\/gif;\n[^a-z]+name=/ It's already been mentioned, but mimeheader is the right way to look at the headers of MIME parts. How about multiline Content-Types? I tried without success: mimeheader NAMELESSGIF_ATTACHMENT Content-Type =~ /image\/gif;\n[^a-z]+name=/ But this seems to work: mimeheader NAMELESSGIF_ATTACHMENT Content-Type =~ /image\/gif;\s*(\n\s+)?name=/ Whadya think? Thx, Andy.
Re: Image spam and failing rule
On Mon, 2009-04-27 at 12:16 +0200, Andy Spiegl wrote:
It's already been mentioned, but mimeheader is the right way to look
at the headers of MIME parts.
How about multiline Content-Types?
They appear to be wrapped.
$ grep -A 1 image/ dsl.png.msg
Content-Type: image/png;
name=DSL9020.png
$ spamassassin -D
--cf=mimeheader TEST Content-Type =~ m~image/png; name=~
dsl.png.msg 21 | grep 'eval rule TEST'
[4719] dbg: rules: ran eval rule TEST == got hit (1)
I tried without success:
mimeheader NAMELESSGIF_ATTACHMENT Content-Type =~
/image\/gif;\n[^a-z]+name=/
But this seems to work:
mimeheader NAMELESSGIF_ATTACHMENT Content-Type =~
/image\/gif;\s*(\n\s+)?name=/
^^^
The \s* matches a single space. The optional part does not match
anything. :)
--
char *t=\10pse\0r\0dtu...@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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Image spam and failing rule
On Sat, 25 Apr 2009, Gary Forrest wrote:
We are receiving the same image spam many times, random text within the
body. The only common thing is a image attachment, with the filename in
the following format
DSL1234.png
I have made the following ' RAWBODY ' rule
/dsl[0-9]{4}\.png/i
You need to use a 'full' rule to scan attachment names.
While you are at it, you can also scan for
full /Content-Type: image\/gif;\n[^a-z]+name=/
As this seems to be the next evolution of the spam. Nameless gifs :)
Enjoy!
- Charles
Re: Image spam and failing rule
It's already been mentioned, but mimeheader is the right way to look
at the headers of MIME parts.
The rule of thumb is if you are using 'full' you're probably doing it
wrong. :)
On Sun, Apr 26, 2009 at 11:57 AM, Charles Gregory cgreg...@hwcn.org wrote:
On Sat, 25 Apr 2009, Gary Forrest wrote:
We are receiving the same image spam many times, random text within the
body. The only common thing is a image attachment, with the filename in the
following format
DSL1234.png
I have made the following ' RAWBODY ' rule
/dsl[0-9]{4}\.png/i
You need to use a 'full' rule to scan attachment names.
While you are at it, you can also scan for
full /Content-Type: image\/gif;\n[^a-z]+name=/
As this seems to be the next evolution of the spam. Nameless gifs :)
Enjoy!
- Charles
Re: [sa-list] Re: Image spam and failing rule
On Sat, 25 Apr 2009, John Hardin wrote: On Sat, 25 Apr 2009, Gary Forrest wrote: We are receiving the same image spam many times, random text within the body. FuzzyOCR. It seems Spammers are trying image spam again, after giving up on it for a year or so. Is there a version of FuzzyOCR that's actually supported with the current SA release? Or under active development at all? -Dan -- Man, this is such a trip -Dan Mahoney, October 25, 1997 Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org ---
Re: Image spam and failing rule
Gary Forrest wrote:
Hi All
We are receiving the same image spam many times, random text within the
body.
The only common thing is a image attachment, with the filename in the
following format
DSL1234.png
I have made the following ' RAWBODY ' rule
/dsl[0-9]{4}\.png/i
This rule works if the text appears in the body, when testing with a
hand telnet to port 25, but fails in practice.
I think this is because the RAWBODY rule does not search the text of a
attachment.
example text of a spam
--=_NextPart_000_0075_01C9C5DF.A7950570
Content-Type: image/png;
name=DSL6672.png
Content-Transfer-Encoding: base64
Content-ID: a0ff8910$101f730d$6c822ecf
Content-Disposition: inline
Any ideas ?
mimeheader LOCAL_DSL_ATTACHMENT Content-Type =~ /name=dsl[0-9]{4}\.png/i
(Untested.)
Hope this helps,
James.
--
E-mail: james@ | top! to bottom from or backwards read not do I, post top
aprilcottage.co.uk | not do Please
| -- Jeff Vian
Re: Image spam and failing rule
On Sat, 25 Apr 2009, Gary Forrest wrote: We are receiving the same image spam many times, random text within the body. FuzzyOCR. It seems Spammers are trying image spam again, after giving up on it for a year or so. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
Re: Image spam and failing rule
On Sat, Apr 25, 2009 at 02:09:05PM -0700, John Hardin wrote: On Sat, 25 Apr 2009, Gary Forrest wrote: We are receiving the same image spam many times, random text within the body. FuzzyOCR. It seems Spammers are trying image spam again, after giving up on it for a year or so. Why did spammers give up on it, seems like a good idea?
Re: Image spam and failing rule
On Sat, 25 Apr 2009 16:10:41 -0500 Igor Chudov i...@chudov.com wrote: On Sat, Apr 25, 2009 at 02:09:05PM -0700, John Hardin wrote: On Sat, 25 Apr 2009, Gary Forrest wrote: FuzzyOCR. It seems Spammers are trying image spam again, after giving up on it for a year or so. Why did spammers give up on it, seems like a good idea? There are probably many reasons, but I suspect that fundamentally it doesn't make good spam. I think that most spam needs one of two things, either it should look like a legitimate email, or it should have a clickable link. Before image spams, spammers experimented with fragmented urls, but it never really caught-on. If people wont reassemble urls with cut-and-paste, they're even less likely to type them in from captcha-style text.
