Service Pack 2 for Exchange 2003 is now available and offers some cool new features along with the usual bug fixes and rollups of previously released hotfixes. Included is an updated anti-spam framework which uses Sender ID to help reduce the amount of spam delivered to your user's mailboxes, the ability to turn of MAPI access to a mailbox, and mobile messaging improvements.

The release of SP2 builds on the anti-spam framework included in Exchange 2003, adding connection, content and SMTP filtering and inbound mail processing rules. Connection filtering capabilities include support for multiple real-time block list (RBL) providers, customized RBL service configuration, custom DSN response, global accept and deny lists, and a configurable exception list to override the block list.

When enabled, connection filtering checks the IP address on the incoming connection and sends a DNS query to verify whether the computer sending the message is listed on an RBL, which means it was reported as an open relay or is a known source of spam. If it is on the block list, connection filtering closes the connection down and responds to the sender with a customized message.

While connection filtering is typically less useful with backend servers, because the sending IP is that of the corporation's gateway SMTP server, service pack 2 addresses this issue by implementing a parsing algorithm that gets the originating IP from the header.

SMTP filtering monitors the SMTP sessions and functions as a real-time filter, based on rules configured by the administrator and allows both sender and recipient filtering. While previous versions of Exchange server offer some SMTP filtering capabilities, Exchange 2003 SP2 has some enhancements.

Using sender filtering, a list of senders is prohibited from sending messages. This list can be by domain or email address and the use of wildcards is supported. The administrator can configure the filter to drop the incoming connection if the sender's address matches the filter. In an effort to reduce the amount of information a malicious user can capture, you can configure sender filtering to accept the mail and delete it without notifying the sender (recommended). If necessary, you can archive these messages for review or analysis.

Recipient filtering is used only on anonymous connections, not authenticated connections used by employee, and filters inbound mail for specific recipients. Wildcard blocking is supported, which allows the administrators to use patterns to block ranges of recipients. You can use it to filter messages sent to non-existent recipients and reject these messages at the SMTP protocol level.

Because enabling filtering of non-existent recipients could allow spammers to discover the valid e-mail addresses in your organization, Exchange 2003 SP2 supports tarpitting. Tarpitting is a delay which Exchange initiates under certain conditions, that delays the SMTP response normally sent to sending servers before the server sends the message. This delay makes dictionary attacks more time consuming, causing many spammers to give up.

Support for anti-phishing screening was added to the Intelligent Message Filter (IMF). It takes into consideration the message heuristics, and entries on block and allow lists then uses this information to set a phishing confidence level (PCL) which is factored into the spam confidence level (SCL) used by the IMF.

Updates to the filter are expected to be released on a regular schedule. While Microsoft hasn't released a schedule, I expect it will settle into a fairly regular schedule in the coming months, just as the Outlook 2003 junk filter updates settled into a fairly predictable schedule.

To learn more about Exchange 2003 SP2 and to download it or order a CD, see:
Exchange 2003 SP2 overview
http://support.microsoft.com/default.aspx?scid=kb;en-us;906669&sd=rss&spid=1773

Bug fixes:
http://support.microsoft.com/default.aspx?scid=kb;en-us;906669

With Sender ID capabilities in Exchange 2003 SP2, should you enable it and reject all mail from servers without SPF records? No, while Sender ID is one tool in the anti-spam arsenal it should not be relied on as the solution to your spam problems. Once you understand how Sender ID works, you'll see why rejecting messages which fail the sender ID test is probably not in your best interest.

How it works: Sender ID is used to verify that each e-mail message is actually sent from the Internet domain from which it claims to come, based on the sending server's IP address. This will help to eliminate address and domain spoofing and should make it easier to identify and filter junk e-mail and phishing scams. But it's not fool proof, in part because it relies on administrators to create an SPF record for their mail servers.

When a mail server receives a message, it looks up the SPF record of the sending domain, which is published in the Domain Name System (DNS) record. If the sending computer's IP address matches the IP address that is published in the DNS record the message is considered legitimate and passes through.

Exchange can be configured one of three ways to deal with unmatched IP addresses. The message can be deleted and no NDR generated, the message can be rejected, or the message accepted and the Sender ID result used by IMF when it determines the spam confidence level (SCL).

Accepting the message is recommended. Deleting or rejecting email from senders that have no SPF record is useful only if you only care if the sending server has a correct SPF record and aren't concerned whether the messages are legitimate email or spam. The absence of SPF info in a TXT record doesn't implicate the sender domain or server as a spammer. Why? Because while publishing information in SPF is good, it's absolutely no guarantee that a message is or isn't junk mail. There are more spammers with SPF info published than there are legitimate domains and incorrect SPF info may be published by domain owners.

In time, as more and more sites configure Sender ID records, it might have more direct benefit, until then, it's just one tool in the fight against spam, and best used in conjunction with the IMF or other anti-spam solutions.

When it becomes available, the security feature pack for mobile devices will give administrators the capability to cause the device to lock after a specified number of incorrect password attempts. Along with locking the device after failed password attempts, the data stored in the internal memory can erased and the device reset to factory settings. Lost or misplaced devices can also be erased and reset to factory settings remotely.

The administrator will also be able to set the strength and length of the password for the device and set the inactivity time before the user needs to enter their password again. Companies will be able to establish mobile devices policies, which can be mandatory or recommended and exempt some users from the policy. Once a policy is set, they will be able to check whether a device has the latest policy settings, and force the device to download the new policy and settings or block it from syncing.

These mobile messaging features, while neat, are useful only to subscribers of specific mobile services and only with Messaging and Security Feature Pack for Windows Mobile 5.0 installed on the device. The feature pack is only available from the service providers and is specific to each device, so you'll need to contact your provider for availability.

Mobile Messaging
http://www.microsoft.com/exchange/evaluation/bettertogether/bt_mobile.mspx

Messaging & Security Feature Pack for Windows Mobile 5.0 http://www.microsoft.com/windowsmobile/business/5/default.mspx

Exchange Server 2003 SP2 adds functionality to allow the administrator to completely turn off MAPI access for a given user or grant access to a user whose Outlook is configured for cached mode but deny access otherwise. This functionality should be valuable to providers of hosting services that want their end users to connect to Exchange with Outlook Web Access but not with Outlook, using either the regular MAPI connection or RPC over HTTP.

The Exchange team explains how to use Exchange 2003 SP2's ability to block individual users from using MAPI. Because the MAPI blocking is added to the existing ProtocolSettings mechanism for blocking other protocols, you could use the same script to block multiple protocols at once. Read all about it at http://blogs.technet.com/exchange/archive/2005/07/27/408274.aspx

If you are using Small Business Server 2003, should you install Exchange SP2? While it's usually recommended you wait for the SBS service packs, you can install Exchange SP2, so that you can take advantage of larger stores and other features. You do need to be careful, as you don't want to hose your system.

To help you do it right, Vladimir Mazekv details the steps in his blog: http://www.vladville.com/articles/exchangesp2sbs2003.asp

It's October, a month with 31 days and in the US, late sunrises are signaling it's time to return to Standard time. For Outlook users, this means two things. First, because October began on a weekend day, it spans 6 weeks in the monthly calendar and Outlook doesn't handle months that span 6 weeks very well. Actually, it doesn't handle them at all, as it can only display the first 5 weeks in the monthly view, forcing users to scroll if they want to see the end of the month.

As a result, help desks can expect complaints from users on Monday that the monthly calendar has a bug. Because October began on a Saturday, using compressed weekends isn't a factor this month and everyone who views the monthly calendar will be affected.

See http://www.slipstick.com/calendar/wrongdate.htm for more information about this view anomaly.

The second calendar issue which comes up every spring and fall is set to rear it's ugly head - changing appointment times caused by incorrect daylight time settings on the computer. Fix the daylight time settings on all computers accessing the calendar and the appointment times will be correct.

Since the release of Office 2003 SP2, the number of complaints about the junk email filter not working correctly has increased. The most common complaint is that messages sent to addresses on the safe lists are being moved to the junk email folder. While this problem isn't new to service pack 2, more users appear to be affected by it after installing SP2. A second complaint is that users can't disable the junk filter. Regardless of the settings, High, Low or off, email is still moved to the Junk email folder.

If you are using another locally installed anti-spam filter, disable it or disable Outlook's filter. Running two filters can create problems when both filters try to scan the same message. Also double check the blocked senders list to verify the sender wasn't added to the list accidentally. (If you followed my advice in previous issues and have a short blocked list, you'll know with a glance if the address is on the list in error.)

If you aren't using a third party anti-spam scanner, you may have a corrupt Junk Email rule. This is a hidden message in the Inbox that tells Outlook how to filter your spam. Because the message is hidden, you need to use Outlook Spy to see it and delete it.

The short version of the instructions are as follows:

1. After installing Outlook Spy, select the Inbox.
2. Click on the IMAPIFolder button the select the Associated Contents tab.
3. Locate and delete the Junk Email Rule. It may be near the bottom of the list.
4. Close and restart Outlook.

Outlook will recreate the Junk Email filter when it's restarted and your junk email settings should not be affected.

Outlook Spy
http://www.dimastr.com/outspy/

For screenshots and a longer version of the instructions, see:
Delete the Junk Email Rule
http://www.outlook-tips.net/howto/fix_junk.htm