Re: Image spams getting thru
Logan Shaw wrote: [snip] And there's also an easy way around it. Simply add noise to the image. There are a number of techniques, but an obvious one to use with GIF is to assign two palette entries to two nearly (but not quite) identical colors. For example, put 0xff and 0xfffeff in your palette. Then, for every white pixel in the original image, choose at random whether it gets represented by a 0xff or 0xfffeff pixel. There will be virtually no discernable difference to the eye, but the files will completely different, especially since GIF uses LZW compression on the pixel data. There are similar methods for other formats: with JPEG, you can just change the quality settings, causing the JPEG decoder itself to add noise to your image. (And perfectly legit noise, too, since the quality parameters vary on legit images.) And of course you can just add noise to the least significant bit in any generic format as well. - Logan If I could revisit this issue and be less sinister in doing so, I'm trying to look at ways to generate a fingerprint from GIF stock spams that could be used to filter them. I'll need to reduce a large number of spam (no, I don't need any extra, so don't bother forwarding them ;-)... and then do a stochastic analysis of those parameters. In the meantime, a couple of questions and observations... First, CPAN seems to come up short on modules to parse and decompose (and render!) GIF or PNG file formats. Most disappointing. I finally decided on the now stagnant and unsupported Image::Info module (sigh), but it doesn't decompress that data once it deconstructs the GIF data stream into its component parts. I tried to use Compress::LZW to decompress the stream, but that only seems to work on 12 or 16 bit minimum codesize, whereas GIF images are routinely 4, 6, or 8 bits long. Does anyone have a handle on what Perl modules to use for dissecting GIF objects? Thanks, -Philip
Re: Image spams getting thru
Rob Mangiafico wrote: Anyone else find this to be a good rule to catch these image stock spams without too much collateral damage? After writing this I did some checks on the SA public corpus. The rule didn't hit on any of the hard ham. It didn't hit much of the spam either since very little of that is image spam. Regarding SARE it has SARE_GIF_ATTACH which matches on any email that has an attached image. My rule only matches on email that has an attached image that is referenced in the HTML. Hi, a friend of mine is using outlook stationary with a logo. This would hit the rule ... I am not sure whether many senders do that, however Wolfgang Hamann I'm finding it to be very successful and am interested in what others find. Derek
Re: Image spams getting thru
[EMAIL PROTECTED] wrote: Hi, a friend of mine is using outlook stationary with a logo. This would hit the rule ... I am not sure whether many senders do that, however Stationery and image sig files are the two main false positives that I can think of. However I think those uses are fairly rare. Derek
Re: Image spams getting thru
From: Derek Harding [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Hi,
a friend of mine is using outlook stationary with a logo.
This would hit the rule ... I am not sure whether many senders do that, however
Stationery and image sig files are the two main false positives that I
can think of. However I think those uses are fairly rare.
I wish.
{o.o}
Re: Image spams getting thru
On Aug 2, 2006, at 12:25 AM, jdow wrote:
From: Derek Harding [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Hi,
a friend of mine is using outlook stationary with a logo.
This would hit the rule ... I am not sure whether many senders do
that, however
Stationery and image sig files are the two main false positives that
I can think of. However I think those uses are fairly rare.
I wish.
{o.o}
I wish too. But, you know, if suddenly all stationary and image sig
files disappeared off of the internet because anti-spam engines were
flagging them as spam... I would NOT regret it.
I might even quietly pay off the few vocal idio... users in my domain
who would complain about it.
Re: Image spams getting thru
John D. Hardin wrote: On Tue, 1 Aug 2006, Theo Van Dinter wrote: Except now you've also delayed your valid mail by 30 minutes or an hour which sucks (and is sometimes completely unacceptable). Repeat after me: Email is a non-guaranteed, Best Attempt delivery mechanism. There may be delays. Just because thats what it was designed to be, doesnt mean that it is. Email is whatever people use it for. Its an instant messenger utility, its a file transfer mechanism, or even a replacement for the telephone or snail mail. Many people have gotten used to the fact that email these days is usually freakin quick and to suddenly have that changed is unacceptable. Imagine if car companies suddenly started making all vehicles with 4 cylinder engines to help solve the current gasoline crisis. It *would* help the problem and many people would embrace it, but for many others, its simply unacceptable. -Jim
Re: Image spams getting thru
I installed Derek's test rule last night and it has caught every one of the stock promotion emails and nothing else. I set it 1.5 for testing. I have received about 5 of these in the last 12 hours on 2 different accounts out of a total of about 100 emails. Also, I did receive some emails with that were both HTML and text WITH images and they came through perfect without hitting the rule. I will be keeping a close eye on this one as these have seemed to elude every other method. If I see more success, I will be increasing the score. Thanks Derek! -- Here to serve, Dave Augustus Ingrafted Software Inc. c(817) 371-0585 o(817) 741-1288 PO Box 1040 Newark TX 76071
RE: Image spams getting thru
I'm using your rule here with a low score and in addition: rawbody INLINE_IMAGE2/src\s*=\s*[']cid:image001\.gif/i describe INLINE_IMAGE2 Inline Image image001.gif score INLINE_IMAGE2 5.0 I know, I should have used a meta rule intead of duplicating the pattern. Will work wonders till they change the filename. It's already happened. I just received some image spams each with the different attachment names: name=masterpiece.gif name=righteously.gif name=locket.gif
Re: Image spams getting thru
On Aug 2, 2006, at 5:21 AM, Jim Maul wrote: John D. Hardin wrote: On Tue, 1 Aug 2006, Theo Van Dinter wrote: Except now you've also delayed your valid mail by 30 minutes or an hour which sucks (and is sometimes completely unacceptable). Repeat after me: Email is a non-guaranteed, Best Attempt delivery mechanism. There may be delays. Just because thats what it was designed to be, doesnt mean that it is. Email is whatever people use it for. Its an instant messenger utility, its a file transfer mechanism, or even a replacement for the telephone or snail mail. Many people have gotten used to the fact that email these days is usually freakin quick and to suddenly have that changed is unacceptable. Yes, but no matter how much lipstick and lace you put on a pig, it's still a pig. It never suddenly becomes a human woman. And if you take it to a restaurant, you can talk about how dressed up it is, but people are still going to see a pig slopping at the table. And they're still going to give you funny looks for DATING A PIG. People who think Email is an IM, a file sharing tool, or a replacement for a fast, secure, guaranteed courier service ... are dating pigs. Treat them like it.
Re: Image spams getting thru
On Wed, Aug 02, 2006 at 11:17:35AM +0100, Randal, Phil wrote: rawbody INLINE_IMAGE2/src\s*=\s*[']cid:image001\.gif/i describe INLINE_IMAGE2 Inline Image image001.gif score INLINE_IMAGE2 5.0 fwiw, that hits on any outlook message which references an included gif. Will work wonders till they change the filename. It looks like they've generated the message using Outlook and then sent it out -- with one non-Outlook issue in the header. FWIW, I put in a rule via sa-update yesterday to address these mails, which as you say will work until they change the filename. We could do with a Spamassassin plugin to match inline/attached file names, to make it easy to score attached/embedded images by name. MIMEHeader ? Been there for ages. :) -- Randomly Generated Tagline: Stop searching. Happiness is right next to you. Now, if they'd only take a bath ... pgpKDx2NkmptI.pgp Description: PGP signature
RE: Image spams getting thru
Rob Mangiafico wrote: Anyone else find this to be a good rule to catch these image stock spams without too much collateral damage? After writing this I did some checks on the SA public corpus. The rule didn't hit on any of the hard ham. It didn't hit much of the spam either since very little of that is image spam. Regarding SARE it has SARE_GIF_ATTACH which matches on any email that has an attached image. My rule only matches on email that has an attached image that is referenced in the HTML. Hi, a friend of mine is using outlook stationary with a logo. This would hit the rule ... I am not sure whether many senders do that, however Yeah, much to my amazement, many of our users do this as well. Bret
RE: Image spams getting thru
I'm using your rule here with a low score and in addition: rawbody INLINE_IMAGE2/src\s*=\s*[']cid:image001\.gif/i describe INLINE_IMAGE2 Inline Image image001.gif score INLINE_IMAGE2 5.0 I know, I should have used a meta rule intead of duplicating the pattern. How about a meta with a rule that excludes commonly-generated Outlook inline image names? Bret
Re: Image spams getting thru
On Wed, Aug 02, 2006 at 08:06:02AM -0700, Bret Miller wrote: How about a meta with a rule that excludes commonly-generated Outlook inline image names? such as image001.gif, image002.gif, etc? :) -- Randomly Generated Tagline: See, you not only have to be a good coder to create a system like Linux, you have to be a sneaky bastard too ;-) - Linus Torvalds pgpJ6xJrPyG8B.pgp Description: PGP signature
Re: Image spams getting thru
On 2 Aug 2006 [EMAIL PROTECTED] wrote: Regarding SARE it has SARE_GIF_ATTACH which matches on any email that has an attached image. My rule only matches on email that has an attached image that is referenced in the HTML. a friend of mine is using outlook stationary with a logo. That's why such a rule should only contribute a few points to the score. Try to convince your correspondent of the inherent evil of stationery images in email... :) -- John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Look at the people at the top of both efforts. Linus Torvalds is a university graduate with a CS degree. Bill Gates is a university dropout who bragged about dumpster-diving and using other peoples' garbage code as the basis for his code. Maybe that has something to do with the difference in quality/security between Linux and Windows.-- anytwofiveelevenis on Y! SCOX ---
Re: Image spams getting thru
On Tue, 1 Aug 2006, Derek Harding wrote: Stationery and image sig files are the two main false positives that I can think of. However I think those uses are fairly rare. False positives? I think they are *wonderful* indicators of cluelessness. (Elitist? Me?) -- John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Look at the people at the top of both efforts. Linus Torvalds is a university graduate with a CS degree. Bill Gates is a university dropout who bragged about dumpster-diving and using other peoples' garbage code as the basis for his code. Maybe that has something to do with the difference in quality/security between Linux and Windows.-- anytwofiveelevenis on Y! SCOX ---
Re: Image spams getting thru
Will work wonders till they change the filename. It's already happened. I just received some image spams each with the different attachment names: name=masterpiece.gif name=righteously.gif name=locket.gif I guess you people get different spams than I do. I've been seeing that random name selection on stock spam gifs for probably 5 months. In fact I've never seen two that used the same file name. Loren
RE: Image spams getting thru
Title: RE: Image spams getting thru -Original Message- From: Loren Wilton [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 02, 2006 3:17 PM To: users@spamassassin.apache.org Subject: Re: Image spams getting thru Will work wonders till they change the filename. It's already happened. I just received some image spams each with the different attachment names: name=masterpiece.gif name=righteously.gif name=locket.gif I guess you people get different spams than I do. I've been seeing that random name selection on stock spam gifs for probably 5 months. In fact I've never seen two that used the same file name. Loren I have the same random pattern here Loren. --Chris
Re: Image spams getting thru
jdow wrote: One that made it through here had no URLs in the body, a LOT of HTML formatting, and hit HTML_IMAGE_RATIO_06, a very low scoring rule. The HTML formatting is excessive use of this long string for individually formatting small chunks of text which are then covered by the enclosed Base64 image: p class=3DMsoNormalfont size=3D2 face=3DArial span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Arial' That can probably lead to some tests. I also noticed here that HTML_IMAGE_RATIO_06 hit 0.3 percent spam and 0.0 percent ham, here. So I bumped its score up a little. I expect that to be safe here. YMMV. That is the only spam that has broken through in a VERY long time. Yes, if we're talking about the same spam, the one with that string started only recently here. They score between 7 and 15 points due to network-tests, but are since an hour ago being discarded because luckily they contain several unique strings.. Regards Menno van Bennekom -- View this message in context: http://www.nabble.com/Image-spams-getting-thru-tf2014839.html#a5589996 Sent from the SpamAssassin - Users forum at Nabble.com.
Re: Image spams getting thru
How about sending 450 Please Try later to ever mail with an inline image and then somehow verify if it really comes back. (Obviously not my original idea :-) ) How many spams would really comeback. max 20% .. those which are routed thru zombies Thanks Ram
Re: Image spams getting thru
On Tue, 1 Aug 2006, Ramprasad wrote: How about sending 450 Please Try later to ever mail with an inline image and then somehow verify if it really comes back. (Obviously not my original idea :-) ) The problem there, again, is that you've already used the bandwidth and system resources needed to receive and scan the message. Why explicitly say please re-send the message later, I'd like to use my bandwidth and CPU resources to process it again? Would the benefit outweigh the cost? Then add in the infrastructure and long-term resources needed to determine whether you've seen the message before and make a decision based on that data. How many spams would really comeback. max 20% There is a much lighter-weight and more global way to achieve that: standard greylisting. If some spammer MTAs are going to only try delivery once, why expend heavy resources on your end (a full SA scan) to decide whether to TMPFAIL the message just to see if they do? Just install milter-greylist and lose *all* of the lazy-spammer traffic regardless of whether or not it is multi-image-only format. -- John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- It may be possible to start a programme of weapon registration as a first step towards the physical collection phase. ... Assurances must be provided, and met, that the process of registration will not lead to immediate weapons seizures by security forces. -- the UN, who doesn't want to confiscate guns ---
Re: Image spams getting thru
John D. Hardin wrote: On Tue, 1 Aug 2006, Ramprasad wrote: How about sending 450 Please Try later to ever mail with an inline image and then somehow verify if it really comes back. (Obviously not my original idea :-) ) The problem there, again, is that you've already used the bandwidth and system resources needed to receive and scan the message. Why explicitly say please re-send the message later, I'd like to use my bandwidth and CPU resources to process it again? Would the benefit outweigh the cost? Then add in the infrastructure and long-term resources needed to determine whether you've seen the message before and make a decision based on that data. How many spams would really comeback. max 20% There is a much lighter-weight and more global way to achieve that: standard greylisting. Im curious how many organizations that arent ISPs are using some sort of greylisting. Do your users complain when the email they sent to a fellow employee 17 seconds ago didnt arrive yet? We hear all sorts of shit when things like that happen. Try explaining greylisting and spam to some ICU nurse who really doesnt care. All she knows is that we didnt have this problem when we paid to outsource our email. For us, and im sure many others as well, greylisting is just not realistic. -Jim
Re: Image spams getting thru
On Tue, Aug 01, 2006 at 09:24:55AM -0700, John D. Hardin wrote: How many spams would really comeback. max 20% There is a much lighter-weight and more global way to achieve that: standard greylisting. Well, until greylisting becomes enough of a problem that the spammers change their software to queue and retry, thereby eliminating the benefit completely. -- Randomly Generated Tagline: First learn computer science and all the theory. Next develop a programming style. Then forget all that and just hack. - George Carrette pgpbx25u2FuGU.pgp Description: PGP signature
Re: Image spams getting thru
Jim Maul wrote: John D. Hardin wrote: On Tue, 1 Aug 2006, Ramprasad wrote: How about sending 450 Please Try later to ever mail with an inline image and then somehow verify if it really comes back. (Obviously not my original idea :-) ) The problem there, again, is that you've already used the bandwidth and system resources needed to receive and scan the message. Why explicitly say please re-send the message later, I'd like to use my bandwidth and CPU resources to process it again? Would the benefit outweigh the cost? Then add in the infrastructure and long-term resources needed to determine whether you've seen the message before and make a decision based on that data. How many spams would really comeback. max 20% There is a much lighter-weight and more global way to achieve that: standard greylisting. Im curious how many organizations that arent ISPs are using some sort of greylisting. Do your users complain when the email they sent to a fellow employee 17 seconds ago didnt arrive yet? We hear all sorts of shit when things like that happen. Try explaining greylisting and spam to some ICU nurse who really doesnt care. All she knows is that we didnt have this problem when we paid to outsource our email. For us, and im sure many others as well, greylisting is just not realistic. Well, you don't have to use it on internal mail. That's just a configuration issue. Ken Pacific.Net -Jim
Re: Image spams getting thru
Ken A wrote: Jim Maul wrote: John D. Hardin wrote: On Tue, 1 Aug 2006, Ramprasad wrote: How about sending 450 Please Try later to ever mail with an inline image and then somehow verify if it really comes back. (Obviously not my original idea :-) ) The problem there, again, is that you've already used the bandwidth and system resources needed to receive and scan the message. Why explicitly say please re-send the message later, I'd like to use my bandwidth and CPU resources to process it again? Would the benefit outweigh the cost? Then add in the infrastructure and long-term resources needed to determine whether you've seen the message before and make a decision based on that data. How many spams would really comeback. max 20% There is a much lighter-weight and more global way to achieve that: standard greylisting. Im curious how many organizations that arent ISPs are using some sort of greylisting. Do your users complain when the email they sent to a fellow employee 17 seconds ago didnt arrive yet? We hear all sorts of shit when things like that happen. Try explaining greylisting and spam to some ICU nurse who really doesnt care. All she knows is that we didnt have this problem when we paid to outsource our email. For us, and im sure many others as well, greylisting is just not realistic. Well, you don't have to use it on internal mail. That's just a configuration issue. Ken Pacific.Net True, and we would if we chose to use it at all. My example was a little too generic I suppose. We regularly have employees that use email as an instant messenger type of service with insurance companies, patients, doctors offices, etc. For them, and ultimately us, the delay is simply not an option. -Jim
Re: Image spams getting thru
- Original Message - From: Jim Maul [EMAIL PROTECTED] John D. Hardin wrote: On Tue, 1 Aug 2006, Ramprasad wrote: How about sending 450 Please Try later to ever mail with an inline image and then somehow verify if it really comes back. (Obviously not my original idea :-) ) The problem there, again, is that you've already used the bandwidth and system resources needed to receive and scan the message. Why explicitly say please re-send the message later, I'd like to use my bandwidth and CPU resources to process it again? Would the benefit outweigh the cost? Then add in the infrastructure and long-term resources needed to determine whether you've seen the message before and make a decision based on that data. How many spams would really comeback. max 20% There is a much lighter-weight and more global way to achieve that: standard greylisting. Im curious how many organizations that arent ISPs are using some sort of greylisting. Do your users complain when the email they sent to a fellow employee 17 seconds ago didnt arrive yet? We hear all sorts of shit when things like that happen. Try explaining greylisting and spam to some ICU nurse who really doesnt care. All she knows is that we didnt have this problem when we paid to outsource our email. For us, and im sure many others as well, greylisting is just not realistic. Hmmm, strange, all of our customers are healthcare (hospitals, clinics, payers, specialists, etc.), and they love our service. We have been using greylisting for about 1.5 years now, and it has dramatically decreased our spam filtering and virus scanning load. Bill
Re: Image spams getting thru
On Tue, 1 Aug 2006, Jim Maul wrote: There is a much lighter-weight and more global way to achieve that: standard greylisting. Im curious how many organizations that arent ISPs are using some sort of greylisting. Do your users complain when the email they sent to a fellow employee 17 seconds ago didnt arrive yet? I wouldn't greylist local mail. And if people complain about *external* mail, I give them my email-is-only-best-effort speech. We hear all sorts of shit when things like that happen. Try explaining greylisting and spam to some ICU nurse who really doesnt care. All she knows is that we didnt have this problem when we paid to outsource our email. For us, and im sure many others as well, greylisting is just not realistic. That's where having an intelligent administrator comes in. If you regularly exchange mail with known sites and can't afford delays in communicating with them, then tell your systems that you trust them - put them in the greylist exclusion list, add them to the list of sites that can send you executable attachments, and so forth. Reserve your maximum paranoia for the Great Unwashed Internet. -- John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- It may be possible to start a programme of weapon registration as a first step towards the physical collection phase. ... Assurances must be provided, and met, that the process of registration will not lead to immediate weapons seizures by security forces. -- the UN, who doesn't want to confiscate guns ---
Re: Image spams getting thru
On Tue, 1 Aug 2006, Theo Van Dinter wrote: On Tue, Aug 01, 2006 at 09:24:55AM -0700, John D. Hardin wrote: How many spams would really comeback. max 20% There is a much lighter-weight and more global way to achieve that: standard greylisting. Well, until greylisting becomes enough of a problem that the spammers change their software to queue and retry, thereby eliminating the benefit completely. Granted. -- John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- It may be possible to start a programme of weapon registration as a first step towards the physical collection phase. ... Assurances must be provided, and met, that the process of registration will not lead to immediate weapons seizures by security forces. -- the UN, who doesn't want to confiscate guns ---
Re: Image spams getting thru
On Aug 1, 2006, at 9:53 AM, Theo Van Dinter wrote: On Tue, Aug 01, 2006 at 09:24:55AM -0700, John D. Hardin wrote: How many spams would really comeback. max 20% There is a much lighter-weight and more global way to achieve that: standard greylisting. Well, until greylisting becomes enough of a problem that the spammers change their software to queue and retry, thereby eliminating the benefit completely. They don't really even have to queue. They just have to retry. I started doing a tempfail on any host that doesn't have reverse dns (tempfail instead of hardfail in case it's a transient DNS issue). The other day I got 2500 attempts from one such host. I'm willing to bet they were doing something like this: 1) run through my list of recipients a) if I get to deliver, take that recipient off the list b) if I get a permanent failure, take that recipient off of the list b) otherwise, keep them on the list but move on to the next recipient 2) when I get to the end of the list, go through the list again with my smaller list of recipients that got tempfailed the first time No queue of messages. Just retry everyone who tempfailed, over and over again until you get past the greylist. Only, I'm not greylisting, so I just got hit over and over again. It's a lightweight solution to getting around greylisting. It might need some refinement though, but I wont say here what that refinement is. (though, I suppose you could say that's a queue of recipients, but I tend to think of queue in the email sense as a queue of messages ... which I don't expect to ever be a successful spam strategy for zombied PC's -- it will use too many resources, and thus be too likely to attract the attention of the user/owner) Luckily, I do this check early enough in the SMTP session that it didn't really tie up much of the actual system resources. (I do it in MIMEDefang, in filter_sender, so right after the mail from: stage of the SMTP session)
Re: Image spams getting thru
On Tue, 1 Aug 2006, John Rudd wrote: They don't really even have to queue. They just have to retry. ... It's a lightweight solution to getting around greylisting. Crap. That's good. I suppose one way around it might be to hardfail if the far end is retrying too quickly or too many times during the greylist TMPFAIL period. There doesn't appear to be an option to do that presently. This would require some careful configuration, though; the danger of rejecting legitimate mail due to an overly-aggressive retry schedule appears great. -- John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- There is no doubt in my mind that millions of lives could have been saved if the people were not brainwashed about gun ownership and had been well armed. ... Gun haters always want to forget the Warsaw Ghetto uprising, which is a perfect example of how a ragtag, half-starved group of Jews took 10 handguns and made asses out of the Nazis. -- Theodore Haas, Dachau Survivor ---
Re: Image spams getting thru
On Tue, 1 Aug 2006, John D. Hardin wrote: On Tue, 1 Aug 2006, Ramprasad wrote: How about sending 450 Please Try later to ever mail with an inline image and then somehow verify if it really comes back. If some spammer MTAs are going to only try delivery once, why expend heavy resources on your end (a full SA scan) to decide whether to TMPFAIL the message just to see if they do? Just install milter-greylist and lose *all* of the lazy-spammer traffic regardless of whether or not it is multi-image-only format. The two approaches have different costs but also different benefits. Content scan before tempfail has the benefit that it reduces the set of messages for which there is a delay. Pure greylist has the benefit that it saves the work of doing content scans. Basically, doing a content scan before tempfail gives you some extra benefits but has some extra costs. Whether it's an appropriate solution depends on whether those benefits (reduced chances of a legit message being delayed) are worth the cost in CPU time and network bandwidth. And that depends on your situation. If you are a small organization with an underutilized server (say, a modern machine that handles only 5000 messages a day), you might be willing to use double or triple the CPU time and double or triple the bandwidth to improve your spam detection accuracy from (say) 97% to 99%. If you are a large ISP with servers that keep up with their load but don't have much resources to spare, it might be important to you to reduce the load on your servers. - Logan
Re: Image spams getting thru
On Tue, 01 Aug 2006, Theo Van Dinter wrote: On Tue, Aug 01, 2006 at 09:24:55AM -0700, John D. Hardin wrote: ... Well, until greylisting becomes enough of a problem that the spammers change their software to queue and retry, thereby eliminating the benefit completely. Or even simply send spam unconditionally twice or thrice just to be sure to get through the greylist. It just needs knowledge how fast you have to give the same combination of envelope-addresses to the same zombie again. And THIS would explain why I get lots of spams more than once, but in 'chunks' of 3 to 6 times the same thing in a few minutes and then pausing for a long while. So just by re-arranging the (spam-)address-lists and sending at least twice the amount of spam, greylisting may be circumvented. Just an idea, because we currently/suddenly get over 20% more spams for the last few days. Stucki -- Christoph von Stuckrad * * |nickname |[EMAIL PROTECTED] \ Freie Universitaet Berlin |/_*|'stucki' |Tel(days):+49 30 838-5 57 78| Mathematik Informatik EDV |\ *|if online|Tel(else):+49 30 77 39 66 00| Arnimallee 6 / 14195 Berlin * * |on IRCnet|Fax(alle):+49 30 838-75 454/
Re: Image spams getting thru
On Tue, 1 Aug 2006, John D. Hardin wrote: On Tue, 1 Aug 2006, John Rudd wrote: They don't really even have to queue. They just have to retry. It's a lightweight solution to getting around greylisting. Crap. That's good. Yeah, it would be a very simple way of getting around greylisting. However, don't assume that it kills the benefit of greylisting completely: if you can delay processing that questionable message for 30 minutes or an hour, that greatly increases the chances it will end up on a realtime blacklist of some type. Basically, even though this reduces the effectiveness of greylisting, greylisting will take away the element of surprise, which could be valuable. Now, thinking of realtime blacklists in combination with greylisting has got me thinking of a strange concept. Might be new or might not be, but I'll mention it just in case. When a spammer sends out spam, each computer they're using to send it (whether zombie, open relay, or whatever) will be sending out zillions of messages. And greylisting at an individual site tracks sources of messages, but only tracks based on traffic at an individual site. So here's the idea: what if a greylist server filed a report in a distributed database every time it saw a message from an unknown sender (and tempfailed it)? So, for example, a spammer's zombie at 1.2.3.4 sends to acme.com. acme.com greylists it since it doesn't know 1.2.3.4 and files a report with the realtime distributed database. Then foo.com also receives a message from 1.2.3.4. It's also an unknown source for foo.com, so it files a report with the same database. More and more sites keep getting connections from 1.2.3.4, and all the ones that don't recognize 1.2.3.4 as having a history with them all file reports of suspicious activity. Then the spammer goes for a second pass through the list to try to defeat greylisting. The servers that had greylisted the messages will receive it again but will check the distributed database. The distributed database will have a zillion reports of suspicious activity from that IP address. That won't absolutely indicate that the message is spam, but it might be worth adding a score of 1 or 2 points. Like dcc, this would sometimes penalize legitimate bulk mail (whenever a new server appears on the internet and starts sending en masse immediately, it would be penalized). But if it's part of a larger strategy, could it be useful? It seems like it would do a fairly good job of automatically detecting bulk senders. For what it's worth, the distributed database could also keep track of IP addresses that the individual sites' greylists *did* recognize, so that something would only be considered spam if (say) 95% of the sites reporting on that address didn't recognize it. - Logan
Re: Image spams getting thru
On Tue, Aug 01, 2006 at 04:33:39PM -0500, Logan Shaw wrote: However, don't assume that it kills the benefit of greylisting completely: if you can delay processing that questionable message for 30 minutes or an hour, that greatly increases the chances it will end up on a realtime blacklist of some type. Except now you've also delayed your valid mail by 30 minutes or an hour which sucks (and is sometimes completely unacceptable). Then the spammer goes for a second pass through the list to try to defeat greylisting. The servers that had greylisted the messages will receive it again but will check the distributed database. The distributed database will have a zillion reports of suspicious activity from that IP address. That won't absolutely indicate that the message is spam, but it might be worth adding a score of 1 or 2 points. Or it's the first time the service sees insert legit newsletter sender sending out their newsletters. ;) -- Randomly Generated Tagline: It's stupid to slap a table ... - Prof. Long pgp8HuXONqpSb.pgp Description: PGP signature
Re: Image spams getting thru
On Tue, 2006-08-01 at 17:49 -0400, Theo Van Dinter wrote: Except now you've also delayed your valid mail by 30 minutes or an hour which sucks (and is sometimes completely unacceptable). True though it would be more accurate to say that you've delayed some of your valid mail by 30 minutes to an hour. How much this sucks and how unacceptable it is is going to vary enormously. Having run greylisting for a couple of years now I have to say that for me, for the most part, it's not even noticeable since the majority of my email turns up immediately. Derek
Re: Image spams getting thru
On Tue, 2006-08-01 at 17:49 -0400, Theo Van Dinter wrote: Except now you've also delayed your valid mail by 30 minutes or an hour which sucks (and is sometimes completely unacceptable). True though it would be more accurate to say that you've delayed some of your valid mail by 30 minutes to an hour. How much this sucks and how unacceptable it is is going to vary enormously. In a business setting greylisting is generally unacceptable. Managers believe that someone, somewhere on the globe, would send a request for a million dollar conract, and the first to answer (the site not using greylist) would win. If said manager works an avarage 8 hours a day, the probability to lose same contract due to time zone differences would be based on 16 hours, where greylist is at most one hour But managers understand only the statistics that an excel sheet displays :) Wolfgang Hamann Having run greylisting for a couple of years now I have to say that for me, for the most part, it's not even noticeable since the majority of my email turns up immediately. Derek
Re: Image spams getting thru
On Mon, 31 Jul 2006, Derek Harding wrote: rawbody INLINE_IMAGE/src\s*=\s*[']cid:/i describe INLINE_IMAGE Inline Images score INLINE_IMAGE 1.5 I haven't tested this against the SA corpus so YMMV. Anyone else find this to be a good rule to catch these image stock spams without too much collateral damage? Rob
Re: Image spams getting thru
From: Rob Mangiafico [EMAIL PROTECTED]
On Mon, 31 Jul 2006, Derek Harding wrote:
rawbody INLINE_IMAGE/src\s*=\s*[']cid:/i
describe INLINE_IMAGE Inline Images
score INLINE_IMAGE 1.5
I haven't tested this against the SA corpus so YMMV.
Anyone else find this to be a good rule to catch these image stock spams
without too much collateral damage?
Unless it is hidden in SARE rules some place I have not tried it. That
would likely detect ANY embedded image, which would be bad.
{^_^}
Re: Image spams getting thru
On Tue, 1 Aug 2006, Theo Van Dinter wrote: Except now you've also delayed your valid mail by 30 minutes or an hour which sucks (and is sometimes completely unacceptable). Repeat after me: Email is a non-guaranteed, Best Attempt delivery mechanism. There may be delays. -- John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- [Small arms] are fundamentally dangerous and their removal from the equation either by control, neutralisation or removal is essential. The first step is to gain information on their numbers and whereabouts. -- the UN, who doesn't want to confiscate guns ---
Re: Image spams getting thru
On Tue, 2006-08-01 at 18:02 -0700, jdow wrote: From: Rob Mangiafico [EMAIL PROTECTED] On Mon, 31 Jul 2006, Derek Harding wrote: rawbody INLINE_IMAGE/src\s*=\s*[']cid:/i describe INLINE_IMAGE Inline Images score INLINE_IMAGE 1.5 I haven't tested this against the SA corpus so YMMV. Anyone else find this to be a good rule to catch these image stock spams without too much collateral damage? Unless it is hidden in SARE rules some place I have not tried it. That would likely detect ANY embedded image, which would be bad. One thing I've noticed with most of the image spam is that there's a TAB character after the Date: string of the Date header, e.g.: Date:tabWed, 2 Aug 2006 01:42:58 -0900 I haven't seen this in other emails (usually, it's a space character). It may not be safe to use by itself, but in combination with other rules may be helpful. -Bill
Re: Image spams getting thru
Rob Mangiafico wrote: Anyone else find this to be a good rule to catch these image stock spams without too much collateral damage? After writing this I did some checks on the SA public corpus. The rule didn't hit on any of the hard ham. It didn't hit much of the spam either since very little of that is image spam. Regarding SARE it has SARE_GIF_ATTACH which matches on any email that has an attached image. My rule only matches on email that has an attached image that is referenced in the HTML. I'm finding it to be very successful and am interested in what others find. Derek
Re: Image spams getting thru
On Sat, 29 Jul 2006, John D. Hardin wrote:
On Sat, 29 Jul 2006, Loren Wilton wrote:
From: Rory [mailto:[EMAIL PROTECTED]
From: Barbra [mailto:[EMAIL PROTECTED]
Something like
header FROMFROM=~ /[A-Z]\w+ \[mailto\: \w+\.\w+\@/
There is a way to be more specific, but it costs considerably
more.
Namely:
header FROM_REPEAT From =~ /\b(\w{1,20})\.\1\@/
Incorrect results returned quickly are useless.
Adding a test for a single-word unquoted display name would reduce the
cost as the RE engine wouldn't get to the expensive backreference
Ironically, and somewhat amusingly, the spammer has probably
made the backreference less expensive by marking the boundary
between the repeated strings with a period. If the (relevant
part of the) addresses the spammer generated had looked
like this:
cardiaccardiac
adjudgeadjudge
that would have been more annoying to match than what they
actually used:
cardiac.cardiac
adjudge.adjudge
The reason is that you know exactly where the repeated string
(if it exists) must start, so all that is necessary is for the
regex engine is to collect everything up until the period,
then do a single check to see if there is a match (a check
that will usually fail on the very first character when the
engine is replaying its tape of the backreferenced string).
And that's O(N) (where N is the number of characters) in the
worst case, so not bad at all.
Actually, even without the period marking the spot where the
repeat will start it is easy in theory to efficiently match
these strings: the repeat must start exactly in the middle
(since if a string is repeated, the repeat will be the same
length as the first occurrence). If you have a string which is
2*N characters long and you want to see if the last N characters
are a repeat of the first N characters, you start by comparing
character 0 with character N, then compare character 1 with
character N+1, etc. But, whether the regex machine would
ever use that technique is doubtful. So, even though it's
possible in theory to match it efficiently without the . as
a marker, the spammer has chosen a format that's relatively
easy to recognize.
- Logan
Re: Image spams getting thru
On Sat, 2006-07-29 at 18:22 +, [EMAIL PROTECTED] wrote: Does DCC, RAZOR, PYZOR, or any other signature algorithms work with the image spams? It's not apparent from reading the man pages. It seems to me that one could compare the signatures of attachments instead of the whole e-mail and provide additional detection. Thanks, Tim Hi Tim, it seems to be fairly easy to modify images programatically in ways that changes chechsums but not appearance ... so this would just block less sophisticated spammers anyway Wolfgang Hamann So if the spammer keeps generating different images for every spam mail then DCC RAZOR etc would be useless right ? Thanks Ram
Re: Image spams getting thru
On Mon, Jul 31, 2006 at 01:57:52PM +0530, Ramprasad wrote: So if the spammer keeps generating different images for every spam mail then DCC RAZOR etc would be useless right ? An image is just content - much like text or HTML. How useful DCC/RAZOR/etc. would be depends highly on how they are used and on how sophisticated the spammer is. What I suggested is not the end-it-all solution for spam detection but another tool to add to the spamassassin toolbox. Also, generating new images potentially is computationally expensive enough that most spammers wouldn't try it. Over 50% of my false negatives this week would have been properly identified by IDing the image. YMMV. Tim
Re: Image spams getting thru
| Another idea was to check the images for correctness. Some spammers seem | to use slightly modified copies of a master image. These copies are | displayed correctly by the usual MUAs but they do contain errors that show | up when using Image::Info or something. | | Dirk I don't know much about Image::info. I'm assuming we could use it to test images with a low score until we know more. Do you have details?
Re: Image spams getting thru
These image spams have recognizable strings, but normally not in the header. Just collect a few of them and compare (e.g. cat|sort the lines, you will always find similarities (sometimes only in the Mime-part but even that can work nicely and safe enough). You could then make a Spamassassin rule for it (check them on your HAM first). The strings I'm sure enough about are not configured in SA but in Postfix with body_checks, if needed first I put them on HOLD to check the result a few days in the hold-queue then I put them on DISCARD so it is thrown away unnoticed. One of these newer checks 'HOLDED' 170 spams this weekend without FP's, not a big absolute number but there's not a lot of spam coming in anyway because of ip-blocks, RBL's etc in postfix. Only trouble is after some time they change the spam, but then already hundreds of spams are stopped. And finding a new string/regexp can be an entertaining puzzle. But some spam is just used over and over again so some rules still get hit after 2 years, very kind of the spammers.. I check the spam (archived by SA/Amavisd) every morning and if I see more spam than normal and a lot of spam of the same size I know there's work to do ;-) Regards Menno van Bennekom -- View this message in context: http://www.nabble.com/Image-spams-getting-thru-tf2014839.html#a5577751 Sent from the SpamAssassin - Users forum at Nabble.com.
Re: Image spams getting thru
From: MennovB [EMAIL PROTECTED]
These image spams have recognizable strings, but normally not in the header.
Just collect a few of them and compare (e.g. cat|sort the lines, you will
always find similarities (sometimes only in the Mime-part but even that can
work nicely and safe enough).
You could then make a Spamassassin rule for it (check them on your HAM
first).
The strings I'm sure enough about are not configured in SA but in Postfix
with body_checks, if needed first I put them on HOLD to check the result a
few days in the hold-queue then I put them on DISCARD so it is thrown away
unnoticed. One of these newer checks 'HOLDED' 170 spams this weekend without
FP's, not a big absolute number but there's not a lot of spam coming in
anyway because of ip-blocks, RBL's etc in postfix.
Only trouble is after some time they change the spam, but then already
hundreds of spams are stopped.
And finding a new string/regexp can be an entertaining puzzle. But some spam
is just used over and over again so some rules still get hit after 2 years,
very kind of the spammers..
I check the spam (archived by SA/Amavisd) every morning and if I see more
spam than normal and a lot of spam of the same size I know there's work to
do ;-)
One that made it through here had no URLs in the body, a LOT of HTML
formatting, and hit HTML_IMAGE_RATIO_06, a very low scoring rule.
The HTML formatting is excessive use of this long string for
individually formatting small chunks of text which are then covered
by the enclosed Base64 image:
p class=3DMsoNormalfont size=3D2 face=3DArial
span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Arial'
That can probably lead to some tests.
I also noticed here that HTML_IMAGE_RATIO_06 hit 0.3 percent spam
and 0.0 percent ham, here. So I bumped its score up a little. I expect
that to be safe here. YMMV.
That is the only spam that has broken through in a VERY long time.
{^_^}
Re: Image spams getting thru
From: [EMAIL PROTECTED]
On Mon, Jul 31, 2006 at 01:57:52PM +0530, Ramprasad wrote:
So if the spammer keeps generating different images for every spam mail
then DCC RAZOR etc would be useless right ?
An image is just content - much like text or HTML. How useful
DCC/RAZOR/etc. would be depends highly on how they are used and
on how sophisticated the spammer is. What I suggested is not the
end-it-all solution for spam detection but another tool to add to
the spamassassin toolbox.
Also, generating new images potentially is computationally expensive
enough that most spammers wouldn't try it.
Over 50% of my false negatives this week would have been properly
identified by IDing the image. YMMV.
Tim
A few months ago I played around with a plugin that computed MD5 hashes
from images contained in a mail and compared that sum to a RBL-like
DNS-based database maintained by Will Stearns.
Results were somewhat disappointing. If Will still feeds the zone I can
post the code somewhere
Another idea was to check the images for correctness. Some spammers seem
to use slightly modified copies of a master image. These copies are
displayed correctly by the usual MUAs but they do contain errors that show
up when using Image::Info or something.
Dirk
Hi,
this should be possible to detect, but at least gif format can be modified easily
without
introducing errors: just play with unused colormap entries.
An algorithm that actually renders the image (eg converts it to pbm) before the
md5
would recognize images as the same while plain md5 will consider them different
Break the image into pieces. If too many pieces match on MD5 sum then
you score it higher than if lots of the image is different. But that
can get tedious to say the least.
{^_^}
Re: Image spams getting thru
On Mon, 31 Jul 2006, jdow wrote: Break the image into pieces. If too many pieces match on MD5 sum then you score it higher than if lots of the image is different. But that can get tedious to say the least. And there's also an easy way around it. Simply add noise to the image. There are a number of techniques, but an obvious one to use with GIF is to assign two palette entries to two nearly (but not quite) identical colors. For example, put 0xff and 0xfffeff in your palette. Then, for every white pixel in the original image, choose at random whether it gets represented by a 0xff or 0xfffeff pixel. There will be virtually no discernable difference to the eye, but the files will completely different, especially since GIF uses LZW compression on the pixel data. There are similar methods for other formats: with JPEG, you can just change the quality settings, causing the JPEG decoder itself to add noise to your image. (And perfectly legit noise, too, since the quality parameters vary on legit images.) And of course you can just add noise to the least significant bit in any generic format as well. - Logan
Re: Image spams getting thru
From: Logan Shaw [EMAIL PROTECTED]
On Mon, 31 Jul 2006, jdow wrote:
Break the image into pieces. If too many pieces match on MD5 sum then
you score it higher than if lots of the image is different. But that
can get tedious to say the least.
And there's also an easy way around it. Simply add noise to
the image. There are a number of techniques, but an obvious
one to use with GIF is to assign two palette entries to
two nearly (but not quite) identical colors. For example,
put 0xff and 0xfffeff in your palette. Then, for every
white pixel in the original image, choose at random whether it
gets represented by a 0xff or 0xfffeff pixel. There will
be virtually no discernable difference to the eye, but the
files will completely different, especially since GIF uses
LZW compression on the pixel data.
There are similar methods for other formats: with JPEG, you
can just change the quality settings, causing the JPEG decoder
itself to add noise to your image. (And perfectly legit noise,
too, since the quality parameters vary on legit images.)
And of course you can just add noise to the least significant
bit in any generic format as well.
Yup, steganography with random data. Of course, you could feed them
to the FBI and say you suspect this is steganographic terrorist
planning or something. I betcha they or the CIA can find the source
of the spam if they buy into that idea
{^_-}
Re: Image spams getting thru
On Mon, Jul 31, 2006 at 03:45:05PM -0500, Logan Shaw wrote: On Mon, 31 Jul 2006, jdow wrote: Break the image into pieces. If too many pieces match on MD5 sum then you score it higher than if lots of the image is different. But that can get tedious to say the least. And there's also an easy way around it. Simply add noise to the image. Then start using techniques that compare similarities of images. There is probably not ever going to be a technique that can completely defeat spam without drastically changing the way e-mail and Internet works. All we can do is to try to stay ahead of the spammers. If that wasn't the case, there would never be new rules coming out for SpamAssassin. But I find it amusing that people here are more interested in telling spammers how they can defeat an algorithm instead of the other way around. 99% of the techniques in SpamAssassins hvae an easy workaround - does that stop anybody from using them? Tim
Re: Image spams getting thru
On Mon, Jul 31, 2006 at 04:57:49PM -0700, Derek Harding wrote: At my (small) site we receive very few legitimate emails that have attached images that are referenced in the HTML of the message. It's basically only a few droolers who decided to use an image as their sig. Thus testing for /src\s*=\s*[']cid:/i in the rawbody of the message is working very nicely against image spams. False positives on those people with image sigs are prevented by AWL, Bayes and not scoring the test too highly. Is that positive enough? Thanks for the tip. That sounds pretty effective, actually. Care to share your rule? You just gave me an idea though. I think I am going to set up a maybe-spam folder and put your rules in it. That'll keep most of these away from my INBOX and also me from deleting my spam folder without looking. Thanks, Tim
Re: Image spams getting thru
From: Rory [mailto:[EMAIL PROTECTED] From: Barbra [mailto:[EMAIL PROTECTED] Something like header FROMFROM=~ /[A-Z]\w+ \[mailto\: \w+\.\w+\@/ There is a way to be more specific, but it costs considerably more. I'd try this first. Loren
Re: Image spams getting thru
Does DCC, RAZOR, PYZOR, or any other signature algorithms work with the image spams? It's not apparent from reading the man pages. It seems to me that one could compare the signatures of attachments instead of the whole e-mail and provide additional detection. Thanks, Tim
Re: Image spams getting thru
On Sat, 29 Jul 2006, Loren Wilton wrote:
From: Rory [mailto:[EMAIL PROTECTED]
From: Barbra [mailto:[EMAIL PROTECTED]
Something like
header FROMFROM=~ /[A-Z]\w+ \[mailto\: \w+\.\w+\@/
There is a way to be more specific, but it costs considerably
more.
Namely:
header FROM_REPEAT From =~ /\b(\w{1,20})\.\1\@/
Incorrect results returned quickly are useless.
Adding a test for a single-word unquoted display name would reduce the
cost as the RE engine wouldn't get to the expensive backreference
unless there was a single-word unquoted display name:
header FROM_REPEAT From =~ /^\w{1,20}\s(\w{1,20})\.\1\@/
I'd try this first.
It won't work. [A-Z] without the case-insensitive flag won't match the
samples provided. You should also have a beginning-of-line anchor to
ensure it only hits on single-word display names. And the samples
don't have a space after the colon.
Also (and primarily), the [mailto:...]; cruft is likely a
Winders-MUA-specific display-only mangle coded by somebody who is only
familiar with HTML and who should have stuck to browser programming.
If that's actually IN the raw From: message header then it makes an
excellent spam sign by itself as it is a URI format, NOT a valid email
mail address format per RFC-2822.
describe FROM_URI Browser Hammer syndrome
header FROM_URI From =~ /\[mailto:/i
scoreFROM_URI 5000
(...is my hatred of that too obvious?)
The loose version would be:
header FROM_REPEAT From =~ /^\w{1,20}\s\w{1,20}\.\w{1,20}\@/
...but don't score it too high (above, say, 0.5) because it would hit
on possibly legitimate senders like:
From: BillG [EMAIL PROTECTED]
From: ChairMaster [EMAIL PROTECTED]
(whew. My blood sugar is low this morning, I'm cranky...)
--
John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/
[EMAIL PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED]
key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
---
The problem is when people look at Yahoo, slashdot, or groklaw and
jump from obvious and correct observations like Oh my God, this
place is teeming with utter morons to incorrect conclusions like
there's nothing of value here.-- Al Petrofsky, in Y! SCOX
---
Re: Image spams getting thru
On Sat, 29 Jul 2006, John D. Hardin wrote: header FROMFROM=~ /[A-Z]\w+ \[mailto\: \w+\.\w+\@/ It won't work. [A-Z] without the case-insensitive flag won't match the samples provided. Whoops! Comment retracted! -- John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- The problem is when people look at Yahoo, slashdot, or groklaw and jump from obvious and correct observations like Oh my God, this place is teeming with utter morons to incorrect conclusions like there's nothing of value here.-- Al Petrofsky, in Y! SCOX ---
Re: Image spams getting thru
Does DCC, RAZOR, PYZOR, or any other signature algorithms work with the image spams? It's not apparent from reading the man pages. It seems to me that one could compare the signatures of attachments instead of the whole e-mail and provide additional detection. Thanks, Tim Hi Tim, it seems to be fairly easy to modify images programatically in ways that changes chechsums but not appearance ... so this would just block less sophisticated spammers anyway Wolfgang Hamann
Re: Image spams getting thru
On Saturday 29 July 2006 10:22, [EMAIL PROTECTED] wrote: Does DCC, RAZOR, PYZOR, or any other signature algorithms work with the image spams? It's not apparent from reading the man pages. It seems to me that one could compare the signatures of attachments instead of the whole e-mail and provide additional detection. Thanks, Tim Hi Tim, it seems to be fairly easy to modify images programatically in ways that changes chechsums but not appearance ... so this would just block less sophisticated spammers anyway Wolfgang Hamann First: changing images programmatically makes it necessary for them to send individual images rather than one image to 30,000 recipients. That alone would slow them down. Second: If Razor can work for pure text (far easier to manipulate and create minor variations), then it should have the same capability for binaries. So your dismissal of razor is overly broad, and if taken to its logical conclusion would suggest razor is totally useless. -- _ John Andersen pgpB4NY7Zofu5.pgp Description: PGP signature
Image spams getting thru
I am suddenly facing a lot of image spams from a pretty effiecient spammer now . The Ips he is using are not listed anywhere All spams advertising stocks of HLUN.PK Am I alone facing this problem. Also I found that the From header in all mails is a typical repeated string Like these From: Rory [mailto:[EMAIL PROTECTED] From: Barbra [mailto:[EMAIL PROTECTED] From: Ada [mailto:[EMAIL PROTECTED] From: Hattie [mailto:[EMAIL PROTECTED] From: Stacy [mailto:[EMAIL PROTECTED] From: Lynne [mailto:[EMAIL PROTECTED] From: Juliet [mailto:[EMAIL PROTECTED] From: Genevieve [mailto:[EMAIL PROTECTED] From: Aisha [mailto:[EMAIL PROTECTED] From: Monique [mailto:[EMAIL PROTECTED] From: Kirsten [mailto:[EMAIL PROTECTED] From: Pablo [mailto:[EMAIL PROTECTED] From: Sadie [mailto:[EMAIL PROTECTED] Can I write a ruleset to hit these froms Thanks Ram
Re: Image spams getting thru
Hi! All spams advertising stocks of HLUN.PK Am I alone facing this problem. Also I found that the From header in all mails is a typical repeated string No this is seen all over. Anyone a nice rule? Bye, Raymond.
Re: Image spams getting thru
On Fri, July 28, 2006 13:14, Ramprasad wrote: From: Rory [mailto:[EMAIL PROTECTED] From: Barbra [mailto:[EMAIL PROTECTED] Can I write a ruleset to hit these froms yes attached a rule for this -- Benny# header TWO_SUBJS ALL =~ /(?:^|\n)Subject:.*\nSubject:/s # header DOUBLE_SUBJECT ALL =~ /\nSubject: *\nSubject:.\s+\S/m # # So this is what it boils down to, tested: # # headerL_DOUBLE_SUBJECTALL =~ /^Subject:.*^Subject:/smi # describe L_DOUBLE_SUBJECTrfc forbids two subject lines # score L_DOUBLE_SUBJECT0.9 # headerL_DOUBLE_FROM ALL =~ /^From:.*^From:/smi # describe L_DOUBLE_FROM rfc forbids two from lines # score L_DOUBLE_FROM 0.9 # # Thanks to both of you, Justin and Loren. # # Mark # header __DOUBLE_SUBJ ALL =~ /^Subject:.*^Subject:/smi header __DOUBLE_FROM ALL =~ /^From:.*^From:/smi meta DOUBLE_SUBJ_OR_FROM __DOUBLE_SUBJ || __DOUBLE_FROM describe DOUBLE_SUBJ_OR_FROM Contains more than one Subject or From header score DOUBLE_SUBJ_OR_FROM 2.0
Re: Image spams getting thru
Oops they were single from headers , but from different mails On Fri, 2006-07-28 at 16:50 +0200, Benny Pedersen wrote: On Fri, July 28, 2006 13:14, Ramprasad wrote: From: Rory [mailto:[EMAIL PROTECTED] From: Barbra [mailto:[EMAIL PROTECTED] Can I write a ruleset to hit these froms yes attached a rule for this -- Benny
Re: Image spams getting thru
From: Benny Pedersen [EMAIL PROTECTED]
On Fri, July 28, 2006 13:14, Ramprasad wrote:
From: Rory [mailto:[EMAIL PROTECTED]
From: Barbra [mailto:[EMAIL PROTECTED]
Can I write a ruleset to hit these froms
yes
attached a rule for this
I think he meant the cardiac.cardiac and adjudge.adjudge part
of the From line. Your rule simply prevents more than 1 Subject:
header line and more than 1 From: header line.
{^_^}
