I'm trying out a hosted anti-spam solution. This service works by becoming my public-facing mail server (DNS MX record), and relaying non-spam mail to the mail server in my office.

Due to a configuration error, I lost about 15 hours of email--the host wasn't relaying for my domain. Email was bouncing with the message "553 Relaying is not supported".

Lesson learned (with thanks to Ezra Herman):  before switching DNS, use Telnet to test the connection to the host and make sure it is accepting email for my domain. Here's how to do it:

XFOR: Telnet to Port 25 to Test SMTP Communication
http://support.microsoft.com/kb/153119

The configuration is fixed, I sent myself an email using a Telnet session to the anti-spam host, so now I can update my DNS!

A short while ago I changed the IP address configuration on my Small Business Server 2003 SP2 machine. The main reason for the change was to choose an oddball local LAN address that would not conflict when I establish a VPN connection from an external network (e.g. a wireless network). I also took the opportunity to consolidate the three IP addresses I had been using on the single NIC down to the more standard (for SBS) single IP address

Bad Night at the Movies

What I neglected to check until today was Windows Media Services. I run WMS so I can stream short videos from my web site. Today I uploaded a new video and it wouldn't play due to a network error. So I fired up Administrative Tools > Windows Media Services on the server.

First I tried the default test. In WMS, I went to Server > Getting Started and clicked on "Test my server". The test window tried to play "mms://MyServer/encoder_av.wmv" but failed with the error "Windows Media Player Windows Media Player cannot play the file because a network error occurred. The server might not be available. Verifiy that you are connected to the network and that your proxy settings are correct." Well I'm running this test on the server, so I think the server is available! In fact, the file plays fine if I open it directly in Windows Media Player, so this is definitely a WMS problem.

After considerable poking around, in WMS, I went to Server > Properties tab > Control Protocol and noticed that all three protocols were Disabled. When I tried to enable the WMS MMS Server Control Protocol, I got the message:

"Error Description:  The requested address is not valid in this context.
Error Code:  0x80072741" 

Not All IP Addresses Are in the Registry

When I changed IP addresses, I carefully checked the registry for occurrences of the old IP addresses to make sure I hadn't missed any configuration changes. However, it turns out that WMS stores its configuration information in an XML file:

C:\WINNT\system32\windows media\server\ServerNamespace.xml

Sure enough, when I opened that file, I found a reference to a now-defunct IP address. Once I realized that was the problem, the solution was easy:  in WMS, I went to Server > Properties tab > Control protocol > WMS MMS Server Control Protocol, right-clicked, selected Properties, and changed the IP addresses to "Allow all IP addresses to use this protocol." I made the same change to the other two protocols while I was at it. Once I re-enabled the MMS protocol and restarted Windows Media Services, my server streamed movies again!

One of the features built in to Exchange 2003 SP2 is Intelligent Message Filtering. While this is a major step forward in blocking incoming spam, IMF does have its limitations. The limitation that I have encountered most frequently is the misclassification of some email as spam, and the inability to "whitelist" certain senders without implementing third-party workarounds.

Recently, a contributor to a Yahoo group suggested that it might be possible to use IMF's built-in Custom Weight List (CWL) functionality to whitelist senders. The theory was that if the CWL's BODY element has access to the entire email message, including headers, it could be used to allow emails that contain a certain "From:" string.

Today I was able to test this idea. 

Sending Spam to Myself

A few days ago, I made an airline reservation with Express Jet, but never got the confirmation email.  Even when I went back to their web site and asked it to send me the itinerary by email, it never arrived.

It turns out that IMF consistently flags Express Jet reservation mails with a very high SCL rating (8 - 81.8%).  So using the Express Jet reservation site gave me an easy way to send myself an email from an external source that IMF was treating as spam.

Test the CWL with BODY 

I implemented a CWL with

<CustomWeightEntry Type="BODY" Change="MIN" Text="From: reservations@expressjet.com"/>

but still IMF flagged the email as spam.

Test the CWL with SUBJECT 

Well, is the CWL working at all? The blocked emails always have the same subject ("Booking confirmation from ExpressJet").  So I changed the CWL to include

<CustomWeightEntry Type="SUBJECT" Change="MIN" Text="ExpressJet"/>

and the mail was no longer classified as spam.

Conclusion

Apparently, the BODY element of the CWL does not have access to the email headers. Too bad--that means there is still no good way to whitelist by sender.

Another "Gotcha" 

Another "gotcha" I discovered along the way is that the CWL file (MSExchange.UceContentFilter.xml) must be re-copied to the latest IMF subfolder every time IMF updates itself, then the SMTP service must be restarted.  In other words, it is not good enough to put the .xml file in

C:\Program Files\Exchsrvr\bin\MSCFV2

it (currently) has to go into

C:\Program Files\Exchsrvr\bin\MSCFV2\6.5.7942.0

This is correctly explained at the end of this TechNet article:

http://www.microsoft.com/technet/technetmag/issues/2006/10/WeightLists/

but is incorrect in this KB article:

http://support.microsoft.com/kb/907974/en-us

This is another area where Microsoft could improve IMF:  always read the CWL file from the same location. Automatic updates to a product should not break the product's functionality. In the meantime, remember to re-copy the CWL file every time IMF updates itself!