Continuing the Fight Against Spam
Microsoft has steadily improved Exchange's ability to suppress unwanted email. The original version of Exchange 2003 supported better connection and recipient filtering and the ability to restrict access to distribution groups. SP1 fixed some problems, as did the first version of the Intelligent Message Filter (IMF), which is based on the same SmartScreen Technology that Microsoft uses to protect its MSN Hotmail service. Outlook 2003's Junk E-mail Filter also uses a variation of IMF. Basically, IMF examines an incoming mail stream and sets a spam confidence level (SCL) value for each message. If the SCL is greater than the administrator-set value, Exchange can immediately drop the message; otherwise, it's passed on to the user. Outlook's Junk E-mail Filter then evaluates the message and passes or rejects it, depending on the user's preferences. For example, some addresses might be in a user's safe senders list and, if so, Outlook won't suppress messages from those addresses, even when they have a high SCL value.
SP2 builds on this foundation by upgrading several antispam components and including a new IMF release. For example, SP2 now examines incoming SMTP connections to make sure that the connection partner is sending correctly formatted messages so that malicious users can't transmit messages that include 8-bit characters in the RFC2821 stream (a common tactic used to defeat filters). Also, SP2 responds to incoming SMTP VRFY commands, which remote correspondents use to verify email addresses, but Exchange doesn't provide the directory information because spammers often use VRFY commands to harvest valid email addresses. Exchange doesn't support the SMTP EXPN command, which queries a server about the membership of distribution lists (DLs).
If messages pass the connection test and are accepted, Exchange can then apply recipient filtering to prevent them being delivered to certain addresses. Recipient filtering can stop messages being sent to nonexistent addresses, but spammers can perform address-book mining by attempting to send messages to addresses that they build and monitoring the results to detect which addresses are valid. SP2 supports a technique called SMTP command tarpitting, which lets you configure Exchange to implement a delay (in seconds) to respond to a Rcpt To: command if a remote sender attempts to harvest addresses. As a result, spammers will find that their attacks slow down so much that they don't get any results, and they'll probably find an easier target.
The big news for the upgraded IMF is the way it detects and suppresses messages that contain phishing attacks. The upgraded IMF now contains tests that assess whether a message exhibits the characteristics of phishing and sets a Phishing Confidence Level (PCL) value that you can use to decide whether to accept or suppress the message. The higher the PCL, the more likely the message is dubious.
IMF also supports Sender ID, an industry standard framework that's designed to counter email domain spoofing in which a spammer generates messages that seem to originate from a legitimate domain such as Microsoft.com. Sender ID depends on organizations populating DNS records with details of the mail servers that transmit messages for their domains; servers that support Sender ID can use this information to check whether a message actually came from a legitimate source. You can decide to delete illegitimate messages, reject them and send a nondelivery report (NDR), or accept them with a status that causes the IMF to increase the SCL for the message. The default action is Accept, but any message that comes in as marked from an illegitimate source is likely to have such a high IMF-calculated SCL value that it will be suppressed anyway, probably by the recipient's junk-mail filter. See http://www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx for more information about the Sender ID framework.
IMF doesn't support cluster environments, but that isn't a big deal. The vast majority of servers that participate in mail hygiene operations are standalone and don't do much except process incoming email to filter for spam and viruses, whereas clusters tend to be used for mailbox servers. By comparison, redundancy and availability of mail hygiene servers is usually accomplished by scaling and load balancing across multiple systems.
The New OAB
For many organizations, the new Offline Address Book (OAB) format introduced in Exchange 2003 works very well with Outlook clients running in cached mode. However, large organizations have encountered difficulties that can swamp servers with client requests for OAB downloads, so SP2 introduces a revised OAB format (OAB v4) and a new update mechanism to relieve the strain on servers.
Outlook clients request a full OAB download if more than a certain percentage of the OAB has changed. The default threshold is 12.5 percent, or one-eighth, of the OAB entries. However, even a small change such as the update of one digit in a phone number can cause Exchange to consider the record changed. Any organization that upgrades from Exchange 5.5, consolidates servers, adds or removes administrative groups, or performs typical email operations (e.g., moving mailboxes between servers, changing physical offices, adding new SMTP or other email proxy addresses), generates a large number of OAB changes. In turn, the default 12.5 percent threshold will easily be surpassed, leading to many client requests for complete copies of the OAB and a subsequent heavy demand on servers. Small organizations generate small OABs, so their servers are less likely to be affected, but large organizations have felt the pain and are therefore less willing to deploy Outlook 2003 in Cached Exchange Mode.
Microsoft's response is to introduce LZX compression to speed transfer of OAB data between server and client (this is the same technology that clients use to download Windows updates from the Web) and a mechanism called Binpatch, which uses Binary Delta Compression (BDC) to apply updates to client OAB files. In addition, clients now generate their own sort orders for the ANR and Browse files based on the PC locale setting instead of depending on the locales that the server supports. Because of the changes to the client, only PCs running Outlook 2003 SP2 can download and use the OAB v4 files; clients running Outlook 2003 or Outlook 2003 SP1 will continue to use the OAB v3a format.
During the OAB-generation process, SP2 servers generate two new files called Binpatch.oab and Data.oab and store these files in the OAB v4 system public folder, as Figure 2 shows. Each Binpatch.oab file contains the delta changes from the last OAB generation run, or every change to the GAL that has occurred during a day. Earlier versions of OAB changed files that contained complete updated records, even if the actual change to the record was minimal, but the new files contain binary patches that Outlook 2003 SP2 clients can combine to create an updated OAB. For example, the OAB v3 "full data" file that Figure 2 shows is 66MB, and the August 17 update is 1003KB, whereas the OAB v4 versions are 34MB and 239KB, respectively. The net result is that Outlook now has far less data to download than earlier versions did.
Microsoft expects the new OAB format and SP2 patches to considerably reduce the number of times a client has to request a full OAB download. Full downloads should now occur only when the OAB files don't exist on a client, when files are corrupted, or when the client hasn't downloaded updates for more than a month. One minor problem is that although the new format reduces server load, it also gives the client more work to do to decompress and apply the binary patch files. If your PC is overworked today, it won't appreciate the extra burden, and you'll notice that things slow down during OAB processing.
Increased Store Size Limit (Standard Edition)
Prior to SP2, the limit of a mailbox store in Exchange 2003 Standard Edition was 16GB. This limit had been in place since Exchange Server 4.0, so it was obviously outdated and inappropriate in a world in which the average size of a message has grown, average disk size has increased, and the cost per gigabyte has decreased enormously. Microsoft's response was to increase the SP2 limit to 75GB. In time, Microsoft will update the version of Exchange included in Microsoft Small Business Server (SBS) 2003 to support the new limit, probably in a service pack that's released several months after Exchange 2003 SP2's release. Having a larger limit for the store is nice, but even an increase of 59GB doesn't match the growth in average message size. In 1996, the average message was around 10KB; it's now 100KB or larger. As a result, just to keep pace, Microsoft could have increased the store limit to 160GB or more. You'll find a good discussion about how Exchange deals with the new size limit at http://blogs.technet.com/exchange/archive/2005/09/14/410821.aspx.
Public Folder Management Changes
Public folders are everyone's favorite part of Exchange. Some organizations find that public folders do a good job in meeting their needs, but far more have discovered that better options exist. For example, Microsoft SharePoint Portal Server and SharePoint Team Services are popular alternatives for organizations that want collaboration tools. Microsoft is clearly moving away from public folders and will eventually drop this feature, probably when the company has solid migration tools that take data and the applications that people have built around public folders to new platforms. In the interim, SP2 will address some of the problems that plague Exchange administrators. You can now use Exchange System Manager (ESM) to stop and resume content replication activity (but only to servers that run SP2 or later), force the replication of the public folder hierarchy (as Figure 3 shows), and update permissions on folders and have the new permissions propagate down through the public folder hierarchy. Finally, Exchange will log public folder deletions in the Application log so that you can determine who deleted a folder if a mistake is made.
Welcome Changes
SP2 doesn't introduce any earth-shattering changes, but it includes many welcome improvements that will make life easier for Exchange administrators and users alike. The update is easy to apply and will be worthwhile for early deployment. As always, make sure that you take the time to test SP2 in your production environment before rolling it out across the organization. With that caveat, enjoy the update.