I’ve been dealing with spam for a long time now, and even though we see changes every year in the major threats and new techniques that spammers come up with, one of the things that never seems to change are the myths about spam that people still cling to.

Here are a few of my favourites.

Spam Isn’t a Problem Anymore

Every now and then a journalist will write a column declaring that spam is no longer a problem for the internet.  Their argument is usually based on their own individual experience, and usually includes a description of a complex series of forwarding addresses through multiple services and add-ons before a message actually arrives in their inbox.

Then they add a caveat like “And for the handful that do slip through…”

Unfortunately for businesses a complex solution that can’t scale is no option at all, especially one that still lets the spam through despite all that effort.

I Don’t Give Out My Email Address

This myth usually lasts as long as it takes for the first spam email to arrive at that email address, which is quickly followed by shock and outrage (and wild accusations that their ISP “sold” the address to a spammer). Continue reading 5 Top Spam Myths that Still Haven’t Changed»

Blacklists (or block lists) are a spam prevention technique that uses lists of IP addresses or domain names that are associated with spamming to determine whether to block or allow a particular email transmission.

Although the technique falls under one general description, there are many different implementations of block lists that can be used to make different determinations about whether an email is spam or not.

Some of the different techniques include:

• URI lists – these are lists of domain names and IP addresses that have been used as hyperlinks in emails that lead a victim to a malicious website, for example a bank phishing scam
• Open Relay lists – these are lists of mail server IP addresses that have been discovered as open relays and can be (or have been) used by spammers to send emails
• IP lists – aside from open relays an IP address that has directly been a source of spam, or is highly likely to be a source of spam (eg an ISP’s customer IP blocks)

The mechanism for each is basically the same – the mail server inspects the SMTP connection, or email message, that it is receiving.  It then queries one of these block list providers with the URIs or IP addresses, and if it registers a hit it then takes the configured action (usually to drop the email).

With so many different block list providers and different techniques the obvious question is whether more than one provider should be configured on the email server that is responsible for blocking spam in your organization.  Naturally this depends on the specific organization and which services are being used. Continue reading Should You Use More than One Blacklist to Prevent Spam?»

I had an interesting discussion with some Exchange administrators a few days ago.  Their solution to spam was to simply configure the Exchange anti-spam settings to send everything over a certain SCL score to the user’s Junk Email folder of their mailbox, and let the user sort it out from there.

That’s an interesting approach, definitely the least administrative effort in the sense that they never have to hunt down why an email was blocked, or retrieve it from quarantine for an end user.

But like many “quick fix” solutions it adds other problems to the mix, because the Junk Email folder is part of the user’s mailbox stored on the Exchange server.

First let’s think about what we know about the volume of spam on the internet today.  Most reports put it at 90-95% of total email traffic.  My own customers’ stats back that up, so let’s just assume for now that 90% is a good estimate.

I also often find when planning Exchange deployments that incoming external email accounts for about 20% of total email traffic.

So in an organization with 100Gb of mailbox databases, 20Gb of that could be email that was received from outside of the organization.  If that 20Gb only represented 10% of total incoming mail (i.e. 90% is spam), then the organization could receive as much as 200Gb of email instead of 20Gb by allowing all of spam to reach the Exchange server.

So at this point of the demonstration, we’ve got an Exchange server now hosting twice as much email data than it otherwise would because it is being allowed to receive and store all of the spam emails as well. Continue reading Keep Spam Out of Exchange Server»

With all of the attention paid to spam prevention sometimes we forget that viruses and malware remain a strong threat to our business networks.

Although in many cases spam and viruses go hand in hand, there are still some viruses that have no spam-like characteristics and therefore must be defended by genuine antivirus measures.  I recently worked with a customer who was surprised that their server-level antivirus was finding viruses in emails that had already passed through an external hosted filtering service.

Aside from email-borne viruses there are also non-email vectors for viruses and malware to attack an Exchange server.  Once the malware is on a server or computer on the network it can be used to attack other devices or even send out spam itself.

So with all of that in mind here are some strategies for protecting your Exchange environment from virus infection.

Hosted or Gateway Filtering

The best place to stop an email-borne virus is before it reaches your Exchange servers.  To do this requires either an externally hosted service that all of your email is routed through, or a server that sits in front of the Exchange servers (for example in the DMZ or as an edge/gateway device) to check all mail as it arrives.

A benefit of filtering email before it arrives on the Exchange server is that the resource-intensive virus scanning can occur on a dedicated device without impacting the performance of Exchange. Continue reading Antivirus Protection for Exchange Server 2010»

There is a lot of attention paid to preventing spam and other malicious email content from entering our networks.  But there is a lesser amount of attention given to preventing internal abuse of email systems.

The risk of internal email abuse may seem low but for some organizations the risk is actually quite significant.

For example, schools have a duty of care to protect their students from harassment and bullying from other students, not just from people outside the network.  Similarly, some global organizations find that cultural differences between staff in different parts of the world open up the possibility of someone taking offense to what is written in an email.

Very few products exist to prevent these problems, and those that do are not always easy to implement in a complex network.  Placing a filtering system in between every possible sender and recipient on the network would be complex and costly.  And routing all email through one centralized filtering system would introduce delays and the risk of a single point of failure.

Even Exchange Server’s own anti-spam filtering can’t help.  If you recall from my previous post on how the Exchange anti-spam SCL works, any email between mailboxes in the same organization is given an SCL of -1, meaning “trusted”.  So no SCL-based filtering decisions can be made.

However Exchange Server 2010 does make it possible to filter certain email content using Transport Rules.  The benefit of this feature is that it is organization-wide, meaning you configure it centrally, but the configuration takes effect on all Hub Transport servers in the organization, meaning it operates in an efficient, distributed manner. Continue reading Preventing Internal Email Abuse with Exchange Server 2010»

If you have looked at Exchange Server’s anti-spam features or taken a peek at the headers of an email sent through an Exchange server you have probably encountered the term SCL before.

SCL stands for Spam Confidence Level.  It is the “score” that Exchange Server anti-spam assigns to an email based on the email’s contents.  This score is then used to make decisions as to how to handle suspected spam based on the thresholds that the Exchange administrator configures.

The SCL score is calculated and assigned by the Content Filter Agent, which examines all of the content within an email message to look for patterns that indicate spam.  Once the SCL score has been calculated it is added to the message header.

In this snippet of an example message header you can see the SCL score of 7 has been applied.

X-MS-Exchange-Organization-SCL: 7

How the SCL is Used by Exchange Server

The SCL score can then trigger certain actions to take place.  The Exchange server can take the following actions based on the SCL:

• Delete – the message is deleted with no notification to the sender or recipient.
• Reject – the message is rejected with a notification to the sender but not the recipient.
• Quarantine – the message is quarantined in a specified mailbox with no notification to the sender or recipient.  Typically only email administrators can access the quarantine mailbox.
• Junk – the message is delivered to the recipient’s Junk Email folder.

SCL scores range from 0-9 with 0 meaning not likely to be spam, and 9 meaning very likely to be spam.  There is also a -1 score for trusted email messages.  A -1 SCL would apply to email messages sent between recipients of the same Exchange organization, or messages from external senders that have been whitelisted in some way.

The SCL threshold is then configured for each of the actions.  However it is important to understand that the actions are assessed in a certain order. Continue reading Understanding the Spam Confidence Level in Exchange Server»

Some organizations wish to deploy complete end to end redundancy for their Exchange environment, including the outgoing routes to the internet.

To achieve this most organizations will simply provision a backup internet connection for their network.  This connection can either be activated during an outage of their primary link, or be configured as a secondary route that will be automatically used if the primary route is down.

Although this seems like a simple win it can cause problems with email delivery because of IP reputation issues.

You need to be sending email fairly consistently from an IP address in order to maintain a decent reputation for that mail source. If you treat a second location as a cold standby, only used when your main ISP breaks, expect to see serious delivery problems as you migrate across to it.

In other words unless you are continually sending email out both of your email routes you might create new problems for yourself when you start using the backup connection.  So what is the solution?

Better to spread load across both locations, to keep both sets of addresses “warm”

Load Balancing Outgoing Email with Exchange Server

A common misconception is that outbound email can be load-balanced for Exchange simply by provisioning two equal cost Send Connectors, either using DNS to route directly or routing via a smart host for each Send Connector. Continue reading Avoiding IP Reputation Problems with Redundant Mail Paths»

When the Exchange Server 2010 anti-spam features are enabled and configured they take effect for all mailboxes within the organization.  But sometimes it is necessary to customize the settings for specific mailbox users.

Organization-Wide Anti-Spam Settings

At the organization level there are several anti-spam settings that can be applied.

SCLJunkThreshold – This is the Sender Confidence Level (SCL) score that will cause an email to be delivered to the Junk Email folder of a mailbox instead of the Inbox.  SCL is scored from 0-9 with 9 being the most likely to be spam.  By default the SCLJunkThreshold is set to 4.

[PS] C:\>Get-OrganizationConfig | fl SCLJunkThreshold

SCLJunkThreshold : 4

There are also a series of SCL thresholds configured on the Content Filter Agent.

[PS] C:\>Get-ContentFilterConfig | fl *SCL*

SCLRejectThreshold     : 7
SCLRejectEnabled       : True
SCLDeleteThreshold     : 9
SCLDeleteEnabled       : False
SCLQuarantineThreshold : 9
SCLQuarantineEnabled   : False

With the default settings shown above a spam message that scores an SCL higher than 7 will be rejected by the Transport server.  A spam message that scores an SCL higher than 4 but not more than 7 will be sent to the mailbox Junk Email folder.

Mailbox-Level Anti-Spam Settings

These anti-spam settings can also be configured on a per-mailbox basis.

[PS] C:\>get-mailbox Alan.Reid | fl *spam*,*SCL

AntispamBypassEnabled  : False
SCLDeleteThreshold     :
SCLDeleteEnabled       :
SCLRejectThreshold     :
SCLRejectEnabled       :
SCLQuarantineThreshold :
SCLQuarantineEnabled   :
SCLJunkThreshold       :
SCLJunkEnabled         :

When configured at the mailbox level the settings take precedence over the organization-wide settings. Continue reading Configuring Exchange Server 2010 Anti-Spam Settings for Individual Mailboxes»

Ever since the first email viruses appeared the risk of file attachments in emails has been an important one for businesses to take seriously. To make it possible to manage this risk Exchange Server 2010 includes the feature to block file attachments in emails at the server level.

The attachment filter is available in the Edge Transport server role for Exchange Server 2010. The Edge Transport server is designed to be an internet-facing email gateway, usually located in the DMZ of a corporate network. It allows an organization to block spam and viruses, as well as make filtering decisions based on content and other message attributes.

The attachment filter agent is installed and enabled by default on Edge Transport servers.

[PS] C:\>Get-TransportAgent

Identity                                           Enabled         Priority
--------                                           -------         --------
Connection Filtering Agent                         True            1
Address Rewriting Inbound Agent                    True            2
Edge Rule Agent                                    True            3
Content Filter Agent                               True            4
Sender Id Agent                                    True            5
Sender Filter Agent                                True            6
Recipient Filter Agent                             True            7
Protocol Analysis Agent                            True            8
Attachment Filtering Agent                         True            9
Address Rewriting Outbound Agent                   True            10

You’ll notice it is one of the lowest priority filtering agents on the server. This is because other agents such as the Connection Filtering agent can detect and block spam using more efficient decision making criteria such as the IP address of the sending server. Continue reading How to Block Dangerous File Attachments with Exchange Server 2010»

A “catch all” email address is a mailbox that is configured to receive any emails that are sent to addresses that do not match a real, valid recipient.

Catch all addresses are popular in a few different scenarios and for a few different reasons.

Common Uses of Catch All Email Addresses

Small businesses often use a catch all email address rather than configure separate sales@, service@, news@ and other common email addresses.

Similarly, many businesses use a catch all as a means to avoid missing potential sales opportunities if someone was to email a non-existent address.

Catch alls are also sometimes used to prevent email sent to misspelled email addresses from being rejected.

Why You Should Not Use Catch All Email Addresses

Catch all email addresses also have some downsides.  A catch all mailbox is going to receive a lot of multi-purpose email such as sales enquiries and support requests, and so it may become difficult to sort and prioritise new emails.

The catch all mailbox will also naturally receive email that may be private correspondence to an individual within the organization, but that had a misspelled email address.  Instead of privacy or confidentiality being maintained by rejecting the misspelled email address so that the sender is made aware of their error, it is instead delivered to the catch all mailbox which may cause an information leak. Continue reading Why You Should Not Use a Catch All Email Address»