Anti-spam reporting for Exchange Server 2007

In recent posts I’ve written about how to configure and manage Exchange Server 2007 anti-spam features such as connection filtering, content filtering, quarantine, and directory harvest protection.

Each of these features carries a variety of advantages and disadvantages.  A consistent disadvantage across all of them is limited reporting capabilities.

Spam Reporting

Why do we need reporting for anti-spam systems?

An organization’s anti-spam solution is a critical component of the entire messaging infrastructure.  The objective of an anti-spam solution is to protect the business from malicious and unwanted emails such as spam, viruses, phishing attacks, and inappropriate material, yet still allow genuine business emails to pass through to the intended recipients.

If you read my real world example of content filtering gone wrong you will understand why the email administrators and business stakeholders need to measure the performance of the email and anti-spam systems.

What should we be reporting on to measure anti-spam performance?

Some of the key metrics to report on are:

  • How many inbound and outbound emails are sent?
  • What is the proportion of valid email to spam email determined by the anti-spam system?
  • On what basis are emails being blocked?
  • Where is the most spam coming from?
  • Who are the most targeted recipients of spam email within our organization?

Using Exchange Server 2007 anti-spam reporting

Exchange Server 2007 ships with several PowerShell scripts that can be used for reporting on anti-spam performance.  These scripts must be executed via the Exchange Management Shell and the output read as text.

The reporting scripts are located in the Scripts folder in the location you installed the Exchange Server application files on any Hub Transport server.  By default the path is C:Program FilesMicrosoftExchange ServerScripts.

The script files are named:

  • get-AntispamFilteringReport.ps1
  • get-AntispamSCLHistogram.ps1
  • get-AntispamTopBlockedSenderDomains.ps1
  • get-AntispamTopBlockedSenderIPs.ps1
  • get-AntispamTopBlockedSenders.ps1
  • get-AntispamTopRBLProviders.ps1
  • get-AntispamTopRecipients.ps1

Each of the scripts queries the appropriate agent log file and calculates the result depending on the parameters passed to the script by the administrator.  For example you can pass a start date and end date to only show results within that time period.

Example: using the get-AntispamFilterReport.ps1 script we can output the total number of blocked or quarantined messages depending on the parameters we choose.

Anti-Spam Filter Report

Example: using the get-AntispamSCLHistogram.ps1 script we can output the total number of emails that were calculated for each SCL rating (0-9, where 0 is least likely to be spam and 9 is most likely to be spam).

Example: using the get-AntispamTopBlockedSenderIPs.ps1 script we can see the top 10 IP addresses that sent spam to our Exchange servers.  As responsible email administrators we might follow up on this information by reporting the IP addresses to the ISP or net block owner, or submit them to an RBL provider.

Example: using the get-AntispamTopBlockedSenderDomains.ps1 script we can see which domains were most responsible for spam being sent to our organization.  Although this information is useful it is also often misleading due to address spoofing.  In some cases though it can be an advantage to block certain domains that are frequent sources of spam but clearly not business related (e.g. cheapviagra.com) so that spam emails are blocked based on sending domain rather than the more resource intensive content filtering.

Example: using the get-AntispamTopRBLProviders.ps1 script we can see which of the RBL providers configured for our Connection Filter agent are performing the best.  If the provider that is first used by the agent is underperforming it can be set to a lower priority in favour of a higher performing RBL provider.

Disadvantages of Exchange Server 2007 anti-spam reporting

While each of the anti-spam reporting scripts provided with Exchange Server 2007 is basically useful they are inadequate for most organizations’ reporting needs.  Although some of the key reporting metrics can be retrieved with the scripts, the output is just basic numbers suitable for email administrators but unsuitable for presentation to business stakeholders.

In the real world if I walked into a meeting and handed out a piece of paper with those figures on it I would not get a positive response at all.  If I was to go back and perform some data entry and manipulation to generate colourful charts and a trend analysis it could take a lot of time and is a completely manual process performed each time the report was requested.

Furthermore, the reporting scripts retrieve information from the local server only.  In order to get a complete organization-wide reporting view the scripts must be run on all Hub Transport servers that may have processed spam emails.

How to deliver quality anti-spam performance reports to your organization

To keep administrative costs low and business stakeholders happy an anti-spam solution that includes comprehensive reporting features should be implemented in the environment.

Some of the key features are:

  • automatic report generation (e.g. PDF files and emailed reports) including charts, tables and graphs
  • both manual and scheduled report execution
  • access for both administrators and business stakeholders without granting privileged access to production Exchange servers
  • high quality pre-canned reports along with custom report building

When considering an anti-spam solution for your organization you must consider the administrative cost and the limitations of the built-in Exchange Server 2007 anti-spam reporting.

For some more additional information you may also want to read the following blog post: http://techiefixation.blogspot.com/2008/12/fight-e-mail-spam-with-exchange-2007.html with focuses on some of the most important anti-spam features present in Exchange 2007.

Written by Paul Cunningham

Paul lives in Brisbane, Australia and works as a technical consultant for a national IT services provider, specialising in Microsoft Exchange Server and related messaging systems.

0 Comments

Leave A Reply