Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Topic Last Modified: 2008-01-22

In Microsoft Exchange Server 2007, the term safelist aggregation refers to a set of anti-spam functionality that is shared across Microsoft Office Outlook and Exchange. This functionality collects data from the anti-spam Safe Recipients Lists or Safe Senders Lists and contact data that Outlook users configure and makes this data available to the anti-spam agents on the computer that has the Edge Transport server role installed. Safelist aggregation can help reduce the instances of false-positives in anti-spam filtering that is performed by the Edge Transport server.

When an Exchange administrator enables and correctly configures safelist aggregation, the Content Filter agent passes safe e-mail messages to the enterprise mailbox without additional processing. E-mail messages that Outlook users receive from contacts that those users have added to their Outlook Safe Recipients List or Safe Senders List or have trusted are identified by the Content Filter agent as safe. An Outlook contact is a person, inside or outside the user's organization, about whom the user can save several types of information, such as e-mail and street addresses, telephone and fax numbers, and Web page URLs.

Safelist aggregation can help reduce the instances of false-positives in anti-spam filtering that is performed by the Edge Transport server. A false-positive is a positive test or filter result that is in a subject or body of data that does not possess the attribute for which the filter or test is being conducted. In the context of spam filtering, a false-positive occurs when a spam filter incorrectly identifies a message from a legitimate sender as spam.

For organizations that filter hundreds of thousands of messages from the Internet every day, even a small percentage of false-positives means that users might not receive many messages that were identified incorrectly as spam and therefore were quarantined or deleted.

Safelist aggregation is likely the most effective way to reduce false-positives. Outlook 2003 and the next release of Outlook, which is included in Office 2007, let users create Safe Senders Lists. Safe Senders Lists specify a list of domain names and e-mail addresses from which the Outlook user wants to receive messages. By default, e-mail addresses in Outlook Contacts and in the Exchange Server global address list are considered safe by the Junk E-mail filter. However, the contacts are not actually added to this list unless you send messages to them while you have the Automatically add people I e-mail to the Safe Senders List check box selected. By default, Outlook adds all external contacts to which the user sends mail to the Safe Senders List.

Information Stored in the Outlook User's Safelist Collection

A safelist collection is the combined data from the user's Safe Senders List, Safe Recipients List, Blocked Senders List, and external contacts. This data is stored in Outlook and in the Exchange mailbox.

The following types of information are stored in an Outlook user's safelist collection:

  • Safe senders and safe recipients   The From: message header indicates a sender. The To: field of the e-mail message indicates a recipient. Safe senders and safe recipients are represented by full Simple Mail Transfer Protocol (SMTP) addresses, such as masato@contoso.com. Outlook users can add senders and recipients to their safe lists.

  • Safe domain   The domain is the part of an SMTP address that follows the @ symbol. For example, contoso.com is the domain in the masato@contoso.com address. Outlook users can add sending domains to their safe lists.

    Important:
    Microsoft Exchange Server 2007 Service Pack 1 (SP1) provides functionality that allows you to specify whether to include the safe domain data to the anti-spam agents on the Edge Transport server by using the Update-SafeList cmdlet. In most cases, we do not recommend that you include domains because users may include the domains of large Internet service providers (ISP), which could unintentionally provide addresses that may be used or spoofed by spammers.
  • External contacts   Two types of external contacts can be included in the safelist aggregation. The first type of external contact includes contacts to whom Outlook users have sent mail. This class of contact is added to the Safe Senders List only if an Outlook user selects the corresponding option in the Junk E-mail settings in Outlook 2003 or Exchange 2007.

    The second type of external contact includes the users' Outlook contacts. Users can add or import these contacts into Outlook. This class of contact is added to the Safe Senders List only if an Outlook user selects the corresponding option in the Junk E-mail Filter settings in Outlook 2003 or Outlook 2007.

How Exchange Uses the Safelist Collection

The safelist collection is stored on the user's mailbox server. In the release to manufacturing (RTM) version of Microsoft Exchange Server 2007, a user can have up to 1,024 unique entries in a safelist collection. In Microsoft Exchange Server 2007 Service Pack 1 (SP1), the limit is 3,072 unique entries.

In earlier versions of Exchange Server, the user's mailbox server accessed the safelist collection during spam filtering to allow e-mail from senders on the Safe Senders List to pass through.

In Exchange 2007, the safelist collection is stored on the user's mailbox, but you can push it to the Active Directory directory service, where the safelist collection is stored on each user object. When the safelist collection is stored on the user object in Active Directory, the safelist collection is aggregated with the anti-spam functionality of Exchange 2007 and is optimized for minimized storage and replication so that the Edge Transport server can process the safelist aggregation. The Content Filter agent on the Edge Transport server can access the safelist collection for each recipient. The Microsoft Exchange EdgeSync service replicates the safelist collection to the Active Directory Application Mode (ADAM) instance on the Edge Transport server.

Important:
Although the safe recipient data is stored in Outlook and can be aggregated into the safelist collection on the ADAM instance on the Edge Transport server, the content filtering functionality does not act on safe recipient data. Because content filtering does not use the safe recipient data, we recommend that you do not configure the Update-Safelist cmdlet to update the safe recipient data. For more information, see How to Configure Safelist Aggregation and Update-SafeList.

Hashing of Safelist Collection Entries

It's worth noting that the safelist collection entries are hashed (SHA-256) one way before they are stored as array sets across two user object attributes, msExchangeSafeSenderHash and msExchangeSafeRecipientHash, as a binary large object. When data is hashed, an output of fixed length is produced; the output is also likely to be unique. For hashing of safelist collection entries, a 4-byte hash is produced. When a message is received from the Internet, Exchange Server hashes the sender address and compares it to the hashes that are stored on behalf of the Outlook user to whom the message was sent. If an inbound hash matches, the message bypasses content filtering.

One-way hashing of safelist collection entries performs the following important functions:

  • It minimizes storage and replication space   Most of the time, hashing reduces the size of the data that is hashed. Therefore, saving and transmitting a hashed version of a safelist collection entry conserves storage space and replication time. For example, a user who has 200 entries in his or her safelist collection would create about 800 bytes of hashed data that is stored and replicated in Active Directory.

  • It renders user safelist collections unusable by malicious users   Because one-way hash values are impossible to reverse-engineer into the original SMTP address or domain, the safelist collections do not yield usable e-mail addresses for malicious users who might compromise an Edge Transport server.

Enabling Safelist Aggregation

You can enable safelist aggregation by running the Exchange Management Shell Update-SafeList cmdlet on a user's mailbox. The Update-SafeList cmdlet reads the safelist collection from the user's mailbox, hashes each entry, sorts the entries for easy search, and then converts the hash to a binary attribute. Finally, the Update-SafeList cmdlet compares the binary attribute that was created to any value that is stored on the attribute. If the two values are identical, the Update-SafeList cmdlet does not update the user attribute value with the safelist aggregation data. If the two attribute values are different, the Update-SafeList cmdlet updates the safelist aggregation value. This logic, where the binary values are compared before updates, is intended to significantly minimize resource use on Active Directory replication. Periodic updates make sure that the most up-to-date safelist aggregation is in Active Directory. For more information about how to configure the Update-Safelist cmdlet to run periodic updates, see How to Configure Safelist Aggregation.

To make the safelist aggregation data in Active Directory available to Edge Transport servers in the perimeter network, you must install and configure the Microsoft Exchange EdgeSync service so that the safelist aggregation data is replicated to ADAM.

For More Information