If you are unsure about approaching this issue please call our helpdesk as you can irreversibly damage your PC if you are not careful
It is best to stop messages before they are processed. Exchange 2007 improves on the groundwork that Exchange 2003 laid in this regard and provides a multi-layer filter to minimize both the amount of spam that reaches the mailboxes and the amount of processing needed to protect those mailboxes. To see the filtering agents, load the Exchange Management Console and look at the Anti-Spam tab in the Organization, Hub Transport section of the interface.
These are the technologies used in Exchange 2007 annti-spam filters:
Connection Filtering—Blocks servers attempting to connect by checking a connecting server’s IP address against IP Allow and Block lists. These lists include both locally configured lists of IPs and lists maintained by third parties, otherwise known as Real-time Blackhole Lists, or RBLs. This is the first agent involved in evaluating an incoming connection.
Sender Filtering—The next agent to handle an incoming message checks the e-mail address of the sender against a list of e-mail addresses and source domains that has been configured. The agent is configured to reject any message whose sender matches one of the list entries, but there is an option to configure it to merely stamp the message with metadata that tracks the fact that it was sent by a blocked sender. This will raise the Spam Confidence Level (or SCL) value of the message, and may cause it to be quarantined or deleted later by the Content Filter. By default, messages from blank senders are blocked.
Recipient Filtering—This agent checks the message’s intended recipient against a list of recipients who are barred from receiving mail and rejects the message if it finds a match. It also rejects addresses that do not exist in the Global Address List. Note that this agent only acts on inbound mail. You cannot specify addresses in this list in order to block outbound mail generated by internal users from going to them.
SenderID—Using a DNS query to ascertain the identity of a remote mail server, this agent protects against spoofed originating domains and phishing scams. Sender ID attempts to verify that each incoming e-mail actually originated from the domain from which it claims to have been sent. To do this, it queries the DNS servers for the remote domain looking for a Sender Policy Framework (normally known as SPF) record, which lists the names of servers authorized to send mail for that domain. Although many mail servers have SPF records set up, many more do not, as it has not been universally implemented yet. Because of this, the default setting for Sender ID is to stamp it with the query result for the purpose of later determining SCL and then allowing it through. To manually check the SPF record of a remote domain like microsoft.com, open up a command prompt and type nslookup -q=TXT microsoft.com
A good source to setup a SPF record for your domain is http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/
Content Filtering—Exchange 2007 improved the Internet Mail Filter that came with Exchange 2003. With the content filter agent, each message is evaluated based on its textual content and then assigned an SCL rating based on what it finds. If the message has been stamped with information by earlier agents in the pipeline, that metadata plays into the rating assigned. This rating is stamped on the message as additional metadata. The content filter is updated at regular intervals to keep up with the evolving tactics of spammers.
The content filter agent also determines what happens to messages whose SCL ratings are high. Messages with an SCL as high as 9 are almost assuredly spam, whereas messages with a value of 4 or 5 might be legitimate. Most legitimate messages have an SCL of 0 or 1. By default, SBS 2008 is configured to reject messages with an SCL rating of 7 or higher.
Sender Reputation—This is actually Microsoft’s own version of a blacklist. Microsoft maintains a database of known spam-sending IP addresses, and the SBS 2008 Server regularly downloads an updated list to apply against inbound connections. Normally this is only available to Exchange Enterprise customers, but it has been included in SBS 2008.
The native Exchange 2007 anti-spam features include three kinds of regularly updated definition files, as follows:
Content Filter Spam Signatures Sender/IP Reputation
If your server is not configured for Automatic Updates, these files will be included in the list of available downloads at the Windows Update site for you to manually download and install. SBS 2008 relies on the Microsoft Exchange Anti-Spam Update Service. All Exchange 2007 anti-spam features function in the context of a transport pipeline, in which each piece of mail has to progress through different layers of analysis and processing. Because these technologies are applied in a synchronous fashion, one after the other, the order in which the filters are applied is important for efficiency reasons. Because some filters require higher levels of processing than others, they are arranged in such a way as to eliminate as much spam as possible before it gets to those “expensive” filters and drains system resources. A good example is the difference between connection filtering and content filtering. Connection filtering drops a conversation with a remote mail-host before even accepting the spam from it. Therefore, no time has to be spent processing it. If it’s possible to block a spamming server’s communication before it can feed your server a few hundred mail items, it’s worth doing. Once messages arrive at the content-filtering stage, the contents of each e-mail have to be examined by the server to determine the likelihood of their being spam, and that’s potentially process-expensive.
Preventing the Reverse NDR Attack
A reverse NDR attack occurs when a spammer or other malicious individual sends a flood of e-mail messages to a server with bad recipient addresses and bad return addresses. In normal Exchange operations, these messages are received by the SMTP server and passed on to Exchange for processing. Only when Exchange attempts to put the message in the message store does the process recognize that the addresses are invalid. At that point, Exchange generates an NDR and sends it back to the faked sender.
This is where the invalid return address comes into play. When Exchange attempts to deliver the NDR back to the sender, it gets hung in the outgoing mail queue while Exchange goes through its normal process of attempting to send the message. By default, Exchange attempts delivery for 48 hours before deleting the message. When thousands upon thousands of these undeliverable NDRs begin filing up the queue, however, not only does the Exchange/SMTP process slow down, but it can slow down the entire server. In addition, server disk space is used up quickly for the storage of these messages that can never be delivered. The best way to prevent an NDR attack is to simply refuse delivery of messages with invalid mail addresses at the SMTP server level so that no NDR is generated within Exchange. If Exchange is not configured this way, the pain inflicted by a reverse NDR attack can be sudden and severe. By default, SBS 2008 uses recipient filtering to block these messages, but disabling that filter could make you vulnerable to this sort of attack.
Configuring Recipient Filtering
To check the recipient-filtering configuration, do the following:
1. Open up the Advanced Management Console and go to the Exchange section.
2. Expand it and then expand the Organization Configuration section.
3. Select Hub Transport from the list and go to the Anti-Spam tab.
4. Open up Recipient Filtering and go to the Blocked Recipients tab.
In the past, if a mail server administrator was using recipient filtering as described previously, spammers would use this as a way to obtain valid e-mail addresses by running scripts against the server’s SMTP service, looking for valid addresses. The spammer would use the immediate rejection as a sign that the address was not valid and would continue to try names until it got to addresses that did not trigger a rejection. These valid addresses were then sold to other spammers and bulk mailers. Fortunately, SMTP tarpitting is a measure that was created to combat this practice. This anti-spam feature intentionally slows down the response speed of the Exchange server’s 5.1.1 user unknown reply to a remote mail server. This delay forces any spamming server using a dictionary of possible names to spend more time communicating with the server, and most spamming servers will switch to another target rather than continue to wait to verify whether its names are active. This feature makes it “too expensive” for spammers to use directory harvesting techniques against the server. By default, the tarpitting timeout is set to five seconds, and there is usually no need to change it. If you did need to change it to troubleshoot a problem with connection delays, you would do so with these PowerShell cmdlets. A cmdlet is a very short but powerful script that is accessible using the Exchange Management Console.
TIP To utilize a PowerShell cmdlet, open the Exchange Management Console by locating it in the Start menu, within the Microsoft Exchange Server 2007 folder. Once the EMS window opens to display a command line, you can use the cmdlets outlined in the following text. Note that the “pipe” character is frequently used in PowerShell scripts and can by created using the Shift+backslash key.
First, get the name of the Receive Connectors and display their settings:
Get-ReceiveConnector | select name, tarpitinterval
Then use this command, using the name of the connector, usually “Default Servername”:
set-ReceiveConnector “Receive Connector Name– -tarpitinterval 00:00:05
The preceding command sets the interval to 5 seconds, but you could remove tarpitting by setting it to 00:00:00 or raise it to 10 seconds by setting it to 00:00:10
Hosted Anti-Spam Solutions
A significant trend in spam management is to use a third party to filter the mail prior to delivery to your server. Typically, this involves changing your public MX record to direct mail to the hosted anti-spam service and configuring their server as your smart host for your own outbound. The service processes the mail through several types of anti-virus engines and then uses a variety of methods to sift legitimate mail out of the inbound stream and deliver it to your server. Microsoft Exchange Hosted Services provides an offering of this type, and some other well-established vendors of this service are MXLogic, Postini, MessageLabs, Symantec, and Exchange Defender. The advantages of using a hosted anti-spam solution are significant, and include the following:
No physical installation required, and thus no potentially problematic conflicts on the software or local networking level. Bandwidth is preserved because spam traffic never touches the private Internet connection. Most hosted solutions also provide several days of queuing in the event that your Internet connection or server go offline, and the queued mail is accessible via web interface. Consistently current spam and anti-virus definition updates and RBLs that are continuously optimized by experts. Redundancy is a standard feature of hosted services, which is not something that a small business can duplicate at the same level, due to cost