Although the Cisco IronPort appliance is pretty efficient in Spam catching making use of the Cisco IronPort SenderBase Reputation Service and message scanning by the Cisco IronPort’s Context Adaptive Scanning Engine (CASE), it still CAN happen that one or the other message passes through and reaches users inboxes. For some this is a no go and the mind goes crazy on why this can happen as the IronPort should have caught it.
There can be numbers of reasons why Spam passes through the appliance and certain checks help to identify if it is a configuration based issue or if 
CASE simply missed the messages due to missing rules. The very first that needs to be done is to check if CASE is updated with current rules. If that is ok use message tracking or the text mail log file to check if the message did not hit a policy where Anti-Spam scanning is disabled. If it did, then the issue is clear and the IronPort has nothing to do with it, but the adminstrator configuring such a policy. What also happens is that the action for positve Spam is set to deliver, instead drop or quarantine.
Another way of verification is by checking the headers and see if the X-IronPort-Anti-Spam-Filtered: true header is present. If it is not, the message was never touched by CASE. Now things start to become more complex as the header can also be missing when the message size exceeds the 'never scan size'. Said that, the message was actually seen by CASE but not touched, because the message size was too big. The 'always scan size' and 'never scan size' has been introduced from version 7.5 onwards where I will be focusing on here. If the Spam message was indeed Anti-Spam scanned then check the message size and compare it with the scan sizes.
Time to get Cisco involved
If the message size is lower then the 'always scan' size then we can be certain that CASE had no rules in place to identify this message as Spam. That is the point where our Cisco IronPort Spam analysts would be happy to get a copy of that Spam message in order to update CASE, pushing out new rules availabe for download to all Cisco IronPort appliances worldwide. Especially submissions by individuals are most appreciated, as they are in most cases more accurate than submissions by scanners only.
Sending a copy sounds easy, but unfortunately it can be beome a headache in the wild forest of Email clients as the Cisco Anti-Spam analysts needs it forwarded RFC822 MIME formated. Why is that? Because the system receiving Spam submissions requires it and if a mail is simply forwarded from Outlook or Entourage, all important headers for analyzis are damaged and unusable. The RFC822 format is the complete email in text format containing all relevant information to fully analyze the message, especially the X-IronPort-Anti-Spam headers. A simple forward in most cases will not create the desired format, so it would be good to check out the knowledge base which provides good amount of information about that topic. If you like reading click on the links below to find out how to send RFC822 MIME formatted samples to our Anti-Spam analysts. You prefer the quick way? Then simply use the security plug-in which does everything for you. You only need to download and install it. Select the Spam message and click the Spam button. Done. The Cisco IronPort security plug-in is availabe for download on cisco.com.
How do I report IronPort Anti-Spam false positives or missed spam?
How do I create RFC-822 MIME encoded attachments?
To make things a bit more clear for one who never had to deal with RFC822 format, here is a sample Email that also has an attachment, showing up in the inbox.
At this point we cannot talk about an email in RFC822 format. This just shows how the mail client renders the message. The mail client used in this example offers an option to save the email as .eml file on the disc. Not many have that option unfortunately. Once saved, the .eml file, which is in RFC822 format, can be opened in any text editor and shows the full message including all headers and attachments in text format. That is what is needed and makes the Spam submission valid. Check the attachment which is in RFC822 format. (The attachment on the bottom only shows up if this blog is fully displayed. Click on the blog title for full display)
Scan size and IPAS score
Messages under the defined 'always scan' size are completely scanned by CASE and messages larger then the 'never scan' size are not scanned. For messages larger than the always scan size and smaller than the never scan size, CASE performs a limited and faster scan.
The recommended value for the always scan size is 512 Kb or less and for the never scan size 10 MB or less. It is advised not to exceed 3 MB for the always scan message size and 10 MB for the never scan message size. A larger value may result in decreased performance.
Important to know is also the score a message gets, as customer support receives lot of cases where users think they have a missed Spam message in their inbox, but in fact it is only suspected Spam - a gray area of messages that are suspiciously similar to spam, but also share some traits with legitimate messages. These type of message are by default flagged as suspected in the Subject. Messages returning a score between 90 and 100 are considered to be positively identified as spam. You can change the positively identified spam threshold to a value between 75 (most aggressive) and 99 (most conservative). Recommended is the default which is 90 for Spam and 50 for suspected Spam.
What you can do
In most cases the default configuration for Anti-Spam works quite well. However, it is worth checking the configuration and make small adjustments here and there to get the best out of it. There is an excellent knowledge base article which will guide you through the process.
IronPort Anti-Spam Efficacy Checklist
What else?
Another common reason for junk in the inbox is completely new type of Spam never seen before by any human being nor an Anti-Spam scanning system. These type of messages usually have a very low IPAS score passing through without being identified. Submit the message preferably using the plug-in and relax. It just happens. Like a chameleon, Spam changes its appearance all the time.
As the Cisco Global Threat Report says, the 2011 takedown of botnet Rustock, combined with multiple spam botnet takedowns in 2010, had a positive impact on overall spam volume. Interestingly, while the takedown efforts had the most positive impact on spam originating from the United States and Russia, spam originating from other countries is rapidly increasing. In fact, at the moment since March 2014 Spam is again increasing globally to the point that spam is now at its highest level since late 2010. From June 2013 to January 2014, spam was averaging between 50-100 billion messages per month, but as of March 2014 volumes were peaking above 200 billion messages per month--more than a 2X increase above normal. Click here for more details.
The vast majority of spam comes from home computers that have been compromised by hackers, and commandeered into a botnet. The traditional way of spamming is decreasing though and in the eye of a Spammer social networks are more interesting. The number of messages that spread malware or that are more targeted attempts to phish usernames and passwords and other personal information is increasing. Here is where the Outbreak Filter helps in identifying such threats and is able to rewrite URL's that appear to be suspicious, leading the user to the cloud where a warning page is displayed, or the website is even blocked if it is malicious. It is worth enabling Outbreak Filters from version 7.5 onwards and the attached Whitepaper explains it in more detail how it works. (The attachment on the bottom only shows up if this blog is fully displayed. Click on the blog title for full display)
