<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic GIF based spam in Email Security</title>
    <link>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507192#M331</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I agree that Brightmail should be catching these at this point and from what I am seeing, they  are letting a large number through; however, I will point out that some of them are coming through with text not just the gifs.  They almost always are scoming in with blank html.  We are working on a filter to catch them here and are going to archive for a few days to see if we have one that won't block legitimate mail.  &lt;BR /&gt;&lt;BR /&gt;P.S. Forward every last one of them that gets past brightmail to them so they know they have a problem.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Wed, 26 Apr 2006 01:37:05 GMT</pubDate>
    <dc:creator>shannon.hagan</dc:creator>
    <dc:date>2006-04-26T01:37:05Z</dc:date>
    <item>
      <title>new spam types</title>
      <link>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507175#M314</link>
      <description>&lt;P&gt;Hi - are other people seeing two new types of spam which are currently evading Brightmail?&lt;BR /&gt;&lt;BR /&gt;The first is usually pushing stocks - it consists of a standard subject, a random haiku of words and a GIF image with a randomised filename. Despite getting heaps of these into our probe accounts Brightmail is yet to positively identify it as spam (although it is labelled as suspect). They are usually botnet spammed at about 1 message per IP per hour.&lt;BR /&gt;&lt;BR /&gt;This one is quite scary in that all the info is contained in the GIF. I'm not sure whether there are any serious anti-spam filters that look inside GIF images. Luckily they weren't very smart and the GIF image appears to be identical - if they were smarter, they would use a JPEG and randomise the compression to make each message fully unique. IP reputation doesn't hinder it as they slow spam them with a large number of IPs - nor does DHAP prevention.&lt;BR /&gt;&lt;BR /&gt;The second is usually watches or online pharmacy - the email is crafted to look like a reply or a forward from someone else "who" recommends the product in question. The words are usually spammily mispelt.&lt;/P&gt;</description>
      <pubDate>Mon, 30 Jan 2006 06:17:12 GMT</pubDate>
      <guid>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507175#M314</guid>
      <dc:creator>tminchin_ironport</dc:creator>
      <dc:date>2006-01-30T06:17:12Z</dc:date>
    </item>
    <item>
      <title>Re: new spam types</title>
      <link>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507176#M315</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;&lt;PRE __jive_macro_name="quote" class="jive_text_macro jive_macro_quote"&gt;The first is usually pushing stocks - it consists of a standard subject, a random haiku of words and a GIF image with a randomised filename.&lt;/PRE&gt;&lt;BR /&gt;&lt;BR /&gt;I'm seeing lots of these, too.  I'm quite disappointed that these are getting past Brightmail.&lt;BR /&gt;&lt;BR /&gt;I've noticed that the GIF images look like faxes with the original inserted at an angle, so the text lines are all slanted slightly.  I suppose this is an anti-OCR measure, but I don't know if anyone is actually trying to use OCR to detect spam images.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 02 Feb 2006 04:05:31 GMT</pubDate>
      <guid>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507176#M315</guid>
      <dc:creator>Donald Nash</dc:creator>
      <dc:date>2006-02-02T04:05:31Z</dc:date>
    </item>
    <item>
      <title>Re: new spam types</title>
      <link>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507177#M316</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Yeah, we're seeing them too. Although, they seem to have slowed down for me. They were really bad in Nov/Dec of '05.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 02 Feb 2006 06:32:29 GMT</pubDate>
      <guid>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507177#M316</guid>
      <dc:creator>Corey_ironport</dc:creator>
      <dc:date>2006-02-02T06:32:29Z</dc:date>
    </item>
    <item>
      <title>Re: new spam types</title>
      <link>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507178#M317</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I've not been happy with Brightmail's spam filtering, period.  We run all mail that makes it past our IronPort Gateway through another box that runs it through SpamAssassin.  Not only does this catch messages like those, but it also allows us to include secondary virus scanning with clamAV which identifies phishing attempts.  Because SpamAssassin is not the "black box" that Brightmail is, we are able to tailor the filters to our needs and wind up blocking thousands of additional messages every day that aren't even flagged as "supected spam" by Brightmail.&lt;BR /&gt;&lt;BR /&gt;Often the crap that makes it past Brightmail is suprising - but of course there is no way to tell what criteria it used to determine its spam score, so there's no way to "tweak" it.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 17 Feb 2006 09:08:45 GMT</pubDate>
      <guid>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507178#M317</guid>
      <dc:creator>NtroP_ironport</dc:creator>
      <dc:date>2006-02-17T09:08:45Z</dc:date>
    </item>
    <item>
      <title>Re: new spam types</title>
      <link>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507179#M318</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;&lt;PRE __jive_macro_name="quote" class="jive_text_macro jive_macro_quote"&gt;Often the crap that makes it past Brightmail is suprising - but of course there is no way to tell what criteria it used to determine its spam score, so there's no way to "tweak" it.&lt;/PRE&gt;&lt;BR /&gt;&lt;BR /&gt;I have to defend Brightmail on this one.  Keeping their rules secret is part of their defense. Spammers know how SpamAssassin works, and have been in a constant arms race against it since day one. And because spammers know how SA works, they can tailor their messages to play to its weaknesses. The fact that Bm's rules are secret means the spammers have a much harder time trying to game them.&lt;BR /&gt;&lt;BR /&gt;Another point is that Bm is deliberately hands-off as a selling point: "We worry about tweaking the rules so you don't have to." That's one of the things that sold us on Bm in the first place: we don't have to devote nearly as much manpower to the spam wars. Essentially, we've outsourced that task to Bm. I just wish they'd pick up the slack a little.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 17 Feb 2006 12:50:01 GMT</pubDate>
      <guid>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507179#M318</guid>
      <dc:creator>Donald Nash</dc:creator>
      <dc:date>2006-02-17T12:50:01Z</dc:date>
    </item>
    <item>
      <title>Re: new spam types</title>
      <link>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507180#M319</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I can definitely understand their thinking on that, but you'd think they'd actually be better at blocking spam than Spamassassin then - this has not been my experience.  I've found SA to have a much better track record of false-positives and a much better track record of catching spam - including phishing emails that have not been added to the clamAV signature database yet.&lt;BR /&gt;&lt;BR /&gt;Of course, this is not with the "stock" SA configuration, I've sellected other addons from the community which allow it to more accurately reflect our environment.  We catch a lot of those "gif" spams that the GP was complaining about in SA - they ALL made it through BM.&lt;BR /&gt;&lt;BR /&gt;I agree that as a spammer, I'd rather be up against a system that I can see the rules so that I can learn to game them,  but it would be nice if BM actually used their "closed" nature more to their advantage because SA seems to still come out way ahead. Although, to be fair it only has to work on messages that made it through BM.  If SA was exposed to the entire load of spam - It's results may be entirely different.  &lt;BR /&gt;&lt;BR /&gt;I'm happy using both, as they give me the best of both worlds - heck, I'd throw a third one in there if I thought it would help ;-).  Right now, if you disregard internal email, we average about 97% spam from the outside world - which we block - and I still get complaints from my users about "so much spam"   :?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sat, 18 Feb 2006 02:22:35 GMT</pubDate>
      <guid>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507180#M319</guid>
      <dc:creator>NtroP_ironport</dc:creator>
      <dc:date>2006-02-18T02:22:35Z</dc:date>
    </item>
    <item>
      <title>Re: new spam types</title>
      <link>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507181#M320</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;&lt;PRE __jive_macro_name="quote" class="jive_text_macro jive_macro_quote"&gt;I can definitely understand their thinking on that, but you'd think they'd actually be better at blocking spam than Spamassassin then&lt;/PRE&gt;&lt;BR /&gt;&lt;BR /&gt;Brightmail also has their "one in a million" false positive promise to worry about. That makes the more conservative.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sat, 18 Feb 2006 03:01:22 GMT</pubDate>
      <guid>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507181#M320</guid>
      <dc:creator>Donald Nash</dc:creator>
      <dc:date>2006-02-18T03:01:22Z</dc:date>
    </item>
    <item>
      <title>Re: new spam types</title>
      <link>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507182#M321</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I can see about keeping the rules a secret; however, if they get a false positive and they refuse to adjust their rules or tell you what is causing the problem then I have an issue.  We recently had an issue where official company mail got marked as suspect spam and many at the company thought it was an insult that it got marked as suspect spam.  At first we were told a reason why that I could not bring to my management and eventually they did change the rule set; however, it wasn't easy convincing them that they needed to make a change.&lt;BR /&gt;&lt;BR /&gt;&lt;PRE __jive_macro_name="quote" class="jive_text_macro jive_macro_quote"&gt;&lt;PRE __jive_macro_name="quote" class="jive_text_macro jive_macro_quote"&gt;Often the crap that makes it past Brightmail is suprising - but of course there is no way to tell what criteria it used to determine its spam score, so there's no way to "tweak" it.&lt;/PRE&gt;&lt;BR /&gt;&lt;BR /&gt;I have to defend Brightmail on this one.  Keeping their rules secret is part of their defense. Spammers know how SpamAssassin works, and have been in a constant arms race against it since day one. And because spammers know how SA works, they can tailor their messages to play to its weaknesses. The fact that Bm's rules are secret means the spammers have a much harder time trying to game them.&lt;BR /&gt;&lt;BR /&gt;Another point is that Bm is deliberately hands-off as a selling point: "We worry about tweaking the rules so you don't have to." That's one of the things that sold us on Bm in the first place: we don't have to devote nearly as much manpower to the spam wars. Essentially, we've outsourced that task to Bm. I just wish they'd pick up the slack a little.&lt;/PRE&gt;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sat, 18 Feb 2006 07:00:38 GMT</pubDate>
      <guid>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507182#M321</guid>
      <dc:creator>shannon.hagan</dc:creator>
      <dc:date>2006-02-18T07:00:38Z</dc:date>
    </item>
    <item>
      <title>Re: new spam types</title>
      <link>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507183#M322</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;We really haven't seen many false positive issues.  In over two years I can still count them on one hand.  I don't consider "suspect spam" to be a false positive, mainly because we don't use it very aggressively - almost not at all.&lt;BR /&gt;&lt;BR /&gt;One of my concerns it the fact BM seems to be getting weaker at catching spam and slower at creating new rule sets.  I mean the cycle time from when a new spam variant hits until they have new rules, seems over 5 days when it used to be under 2.&lt;BR /&gt;&lt;BR /&gt;A second concern is every new BM engine upgrade really brings a lot more system load.  I don't know exactly how much 6.0.2 added, but it noticeably lowered our overall through put.  Now 6.0.3 clams to be adding 20% additional system load!  This kind of lack of performance tuning on Symantec's part will drive us to spend the time to really compare IronPort's Anti-Spam engine.  In two years with IronPorts in our environment the worst critical impact I've had to email delivery was directly due to a Brightmail definition which apparently did not get performance checked and caused a HUGE processing delay on all emails until they got the definition removed.  (NOTE: This was back in May of 2004).&lt;BR /&gt;&lt;BR /&gt;Overall I am still pleased with the Brightmail product, but the past 6 months my impression of it has gone down.  And the idea of no tracking on missed spam or false positive submissions is just inexcusable.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sat, 18 Feb 2006 10:34:46 GMT</pubDate>
      <guid>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507183#M322</guid>
      <dc:creator>Erich_ironport</dc:creator>
      <dc:date>2006-02-18T10:34:46Z</dc:date>
    </item>
    <item>
      <title>Re: new spam types</title>
      <link>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507184#M323</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I totally agree with Erich.  The performance of brightmail has steadily declined to a critical point.&lt;BR /&gt;&lt;BR /&gt;In our environment we are looking at alternatives as well.  We are very happy with Ironport, but the Antispam process is eating to much CPU... causing mail delays.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 20 Feb 2006 21:58:41 GMT</pubDate>
      <guid>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507184#M323</guid>
      <dc:creator>MikeK_ironport</dc:creator>
      <dc:date>2006-02-20T21:58:41Z</dc:date>
    </item>
    <item>
      <title>Re: new spam types</title>
      <link>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507185#M324</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Does CPU usage improve when Suspect Spam detection is turned off?&lt;BR /&gt;&lt;BR /&gt;We don't have much throughput (about 6000/hour per C60) so our CPU is about 20% with 6.0.3&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 21 Feb 2006 11:00:57 GMT</pubDate>
      <guid>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507185#M324</guid>
      <dc:creator>tminchin_ironport</dc:creator>
      <dc:date>2006-02-21T11:00:57Z</dc:date>
    </item>
    <item>
      <title>Re: new spam types</title>
      <link>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507186#M325</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;&lt;PRE __jive_macro_name="quote" class="jive_text_macro jive_macro_quote"&gt;Does CPU usage improve when Suspect Spam detection is turned off?&lt;/PRE&gt;&lt;BR /&gt;&lt;BR /&gt;Someone from IronPort will correct me if I'm wrong, but I'm 99% sure the answer is "no." Brightmail assigns a score 1 - 100 to a message. Anything &amp;gt;= 90 is definitely spam. You get to set the threshold for suspected spam. Since the message is already scored, you're not going to save any significant resources by turning this off.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 21 Feb 2006 23:23:33 GMT</pubDate>
      <guid>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507186#M325</guid>
      <dc:creator>Donald Nash</dc:creator>
      <dc:date>2006-02-21T23:23:33Z</dc:date>
    </item>
    <item>
      <title>Re: new spam types</title>
      <link>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507187#M326</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I also agree with Erich. We hardly use the Suspect Spam piece at all. We're also seeing a decline in Brightmail's shine that we used to like so much about it. The one thing that I would like to add is that reputation filtering is key to us. It's where we block most of our SPAM/malware. By the time our Brightmail license runs out, the IronPort AntiSPAM engine should be a bit more mature. We'll certainly give it a good look at that time.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 23 Feb 2006 00:47:57 GMT</pubDate>
      <guid>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507187#M326</guid>
      <dc:creator>Corey_ironport</dc:creator>
      <dc:date>2006-02-23T00:47:57Z</dc:date>
    </item>
    <item>
      <title>Re: new spam types</title>
      <link>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507188#M327</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;&lt;PRE __jive_macro_name="quote" class="jive_text_macro jive_macro_quote"&gt;We're also seeing a decline in Brightmail's shine that we used to like so much about it.&lt;/PRE&gt;&lt;BR /&gt;Same here.  I have to wonder if the acquisition by Symantec had anything to do with it?&lt;BR /&gt;&lt;BR /&gt;&lt;PRE __jive_macro_name="quote" class="jive_text_macro jive_macro_quote"&gt;By the time our Brightmail license runs out, the IronPort AntiSPAM engine should be a bit more mature. We'll certainly give it a good look at that time.&lt;/PRE&gt;&lt;BR /&gt;I'm already talking with my superiors about scheduling a field test.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 23 Feb 2006 04:11:57 GMT</pubDate>
      <guid>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507188#M327</guid>
      <dc:creator>Donald Nash</dc:creator>
      <dc:date>2006-02-23T04:11:57Z</dc:date>
    </item>
    <item>
      <title>From the symantec knowledge base (Note: Ironport uses 6.0.x)</title>
      <link>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507189#M328</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;An increase of large messages results in an unexpected decrease in scanner performance&lt;BR /&gt;&lt;BR /&gt;Situation:&lt;BR /&gt;&lt;BR /&gt;An influx of messages scanned by the Symantec Brightmail product very slowly. The messages are large and some and a check reveals some are not valid email. The scanner becomes backed up. The messages are queued for processing or pass through unfiltered.&lt;BR /&gt;&lt;BR /&gt;One of the following versions is installed:&lt;BR /&gt;--Symantec Brightmail AntiSpam 6.0.x&lt;BR /&gt;--Symantec Brightmail 6.0&lt;BR /&gt;--Brightmail 5.5&lt;BR /&gt;--Brightmail 4.0&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;Solution:&lt;BR /&gt;This mostly affects Windows and Openwave mail transport authorities (MTA's), as sendmail and postfix both have an MTA limitation that prevents this from happening. What is occurring is that a sender is sending a message with an extremely large number of headers-- 1000's of them. This could be a spammer attempting a denial of service (DoS) attack. The Scanner software attempts to scan all of the headers and takes a long time doing so, tying up the CPU.&lt;BR /&gt;&lt;BR /&gt;Symantec is working on this problem. Patches will be made available for Brightmail 4.0 and Symantec Brightmail AntiSpam 6.0.x.&lt;BR /&gt;&lt;BR /&gt;Workaround&lt;BR /&gt;When you can determine where the messages are coming from, block the sender of any email that is not legitimate.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sat, 25 Feb 2006 03:45:08 GMT</pubDate>
      <guid>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507189#M328</guid>
      <dc:creator>shannon.hagan</dc:creator>
      <dc:date>2006-02-25T03:45:08Z</dc:date>
    </item>
    <item>
      <title>Big increase in GIF Stox spam</title>
      <link>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507190#M329</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Wow,  we are seeing a huge increase in the last couple of days of the "GIF STOX SPAM".  They blow right by our IronPort/BrightMail gateway without even slowing down!&lt;BR /&gt;&lt;BR /&gt;I have to say, it's a good thing we run all of our "clean" messages through SpamAssassin before delivering it on to clients - we are blocking thousands of these things with SA which would normally go straight on through to the end user! &lt;BR /&gt;&lt;BR /&gt;Here's what SA says about an average GIF spam message:&lt;BR /&gt;&lt;BR /&gt;Content analysis details: (12.7 points, 3.0 required)&lt;BR /&gt;&lt;BR /&gt; pts rule name description&lt;BR /&gt;---- ---------------------- --------------------------------------------------&lt;BR /&gt; 1.1 EXTRA_MPART_TYPE Header has extraneous Content-type:...type= entry&lt;BR /&gt; 0.1 HTML_90_100 BODY: Message is 90% to 100% HTML&lt;BR /&gt; 1.0 BAYES_60 BODY: Bayesian spam probability is 60 to 80%&lt;BR /&gt;                            [score: 0.7936]&lt;BR /&gt; 1.1 MIME_HTML_MOSTLY BODY: Multipart message mostly text/html MIME&lt;BR /&gt; 0.0 HTML_MESSAGE BODY: HTML included in message&lt;BR /&gt; 3.1 HTML_IMAGE_ONLY_08 BODY: HTML: images with 400-800 bytes of words&lt;BR /&gt; 0.8 SARE_GIF_ATTACH FULL: Email has a inline gif&lt;BR /&gt; 3.9 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL&lt;BR /&gt;                            [201.247.223.216 listed in sbl-xbl.spamhaus.org]&lt;BR /&gt; 1.7 SARE_GIF_STOX Inline Gif with little HTML&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;You'd think that after all these months of the same sort of spam comming in.  Has anyone found IronPort's Spam filter to be more reliable than BrightMail?  How's the comparison's comming?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 20 Apr 2006 08:33:52 GMT</pubDate>
      <guid>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507190#M329</guid>
      <dc:creator>NtroP_ironport</dc:creator>
      <dc:date>2006-04-20T08:33:52Z</dc:date>
    </item>
    <item>
      <title>Re: new spam types</title>
      <link>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507191#M330</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;So we are still seeing these spams and Brightmail is still unable to detect them, after months of exposure to the problem.&lt;BR /&gt;&lt;BR /&gt;Can Ironport put any pressure on Brightmail to increase the spam score for emails which only send an image? Or is it best practice to run the mail through SA or similar to detect spam mail missed on the Ironport/Brightmail...&lt;BR /&gt;&lt;BR /&gt;The Senderbase scores I've seen for these spams are generally 0 to -1. This is above the range we block (-7 or lower) or warn about suspect spam (using a filter that tags the subject line if Senderbase score &amp;lt; -2).&lt;BR /&gt;&lt;BR /&gt;Would it be possible to create a filter to block "image only" emails? Can anyone suggest what the filter would actually be to detect mails with only an image attachment? (maybe combined with the Senderbase score to only apply the rule if the score is "none" or &amp;lt;0). Even if we don't reject such mail we can tag the subject line to say it is suspect spam.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Tue, 25 Apr 2006 16:54:43 GMT</pubDate>
      <guid>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507191#M330</guid>
      <dc:creator>ian_ironport</dc:creator>
      <dc:date>2006-04-25T16:54:43Z</dc:date>
    </item>
    <item>
      <title>GIF based spam</title>
      <link>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507192#M331</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I agree that Brightmail should be catching these at this point and from what I am seeing, they  are letting a large number through; however, I will point out that some of them are coming through with text not just the gifs.  They almost always are scoming in with blank html.  We are working on a filter to catch them here and are going to archive for a few days to see if we have one that won't block legitimate mail.  &lt;BR /&gt;&lt;BR /&gt;P.S. Forward every last one of them that gets past brightmail to them so they know they have a problem.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 26 Apr 2006 01:37:05 GMT</pubDate>
      <guid>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507192#M331</guid>
      <dc:creator>shannon.hagan</dc:creator>
      <dc:date>2006-04-26T01:37:05Z</dc:date>
    </item>
    <item>
      <title>Re: new spam types</title>
      <link>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507193#M332</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I am seeing these come through as well.&lt;BR /&gt;&lt;BR /&gt;Let me know if you get a filter written.  I am going to try and write one as well...&lt;BR /&gt;&lt;BR /&gt;Thanks!&lt;BR /&gt;Mike&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 27 Apr 2006 20:28:33 GMT</pubDate>
      <guid>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507193#M332</guid>
      <dc:creator>MikeK_ironport</dc:creator>
      <dc:date>2006-04-27T20:28:33Z</dc:date>
    </item>
    <item>
      <title>SPAM GIFs</title>
      <link>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507194#M333</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Here is what I came up with.  It does catch a few valid messages so I decided to archive them so I could go through and find the few valid messages if I needed to. &lt;BR /&gt;&lt;BR /&gt;spam-gifs: if  (rcpt-count == 1) AND (attachment-filename == "(?i)\\.gif") AND (attachment-size &amp;gt;= 45000) and  (attachment-size &amp;lt;= 50000) and (reputation &amp;lt; 0) and (body-contains("(?i)windows-1252")) &lt;BR /&gt;{&lt;BR /&gt;log("spam-gifs");&lt;BR /&gt;drop();&lt;BR /&gt;}&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sun, 30 Apr 2006 05:55:36 GMT</pubDate>
      <guid>https://community.cisco.com/t5/email-security/new-spam-types/m-p/507194#M333</guid>
      <dc:creator>shannon.hagan</dc:creator>
      <dc:date>2006-04-30T05:55:36Z</dc:date>
    </item>
  </channel>
</rss>

