Understanding Safelist Aggregation

Applies to: Exchange Server 2010

In Microsoft Exchange Server 2010, safelist aggregation refers to anti-spam functionality shared across Microsoft Outlook and Exchange. This functionality collects data from the anti-spam Safe Recipients Lists, Safe Senders Lists, Blocked 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 performed by the Edge Transport server.

When you enable and correctly configure 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.

In Exchange 2010, the safelist aggregation process also replicates a per-recipient Blocked Senders List to the Edge Transport server. This allows the Sender Filtering agent on the Edge Transport server to block incoming messages from those senders.

Safelist aggregation can help reduce the instances of false-positives in anti-spam filtering performed by the Edge Transport server. A false-positive is a positive test or filter result in a subject or body of data that doesn't 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 identified incorrectly as spam, which were quarantined or deleted.

Safelist aggregation is likely the most effective way to reduce false-positives. In Office Outlook 2007, users can 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 included in this list. By default, Outlook adds all external contacts to which the user sends mail to the Safe Senders List.

Contents

Information Stored in the Outlook User's Safelist Collection

How Exchange Uses the Safelist Collection

Hashing of Safelist Collection Entries

Enabling Safelist Aggregation

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 SMTP addresses, such as masato@contoso.com. Outlook users can add senders and recipients to their safe lists.

• Blocked senders   Just like safe senders, users can block unwanted senders by adding them to their Blocked Senders 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

  Exchange provides functionality that allows you to specify whether to include the safe domain data for the anti-spam agents on the Edge Transport server by using the Update-SafeList cmdlet. In most cases, we don't 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. By default, Exchange doesn't include the domains during safelist aggregation.

• 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 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 2010 or Outlook 2007.

Return to top

How Exchange Uses the Safelist Collection

The safelist collection is stored on the user's Mailbox server. A user can have up to 1,024 unique entries in a safelist collection. Exchange 2010 has a mailbox assistant, called the Junk E-mail Options mailbox assistant, which monitors changes to the safelist collection for your mailboxes. It then replicates these changes to Active Directory, 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 2010 and is optimized for minimized storage and replication. The Microsoft Exchange EdgeSync service replicates the safelist collection to the Active Directory Lightweight Directory Services (AD LDS) instance on the Edge Transport server. The Edge Transport servers use the safelist collection data during content filtering.

Return to top

Hashing of Safelist Collection Entries

Safelist collection entries are hashed (SHA-256) one way before they are stored as array sets across three user object attributes, msExchSafeSenderHash, msExchSafeRecipientHash, and msExchBlockedSendersHash, as a binary large object. When data is hashed, an output of fixed length is produced, and the output is 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 hashes the sender address and compares it to the hashes stored on behalf of the Outlook user to whom the message was sent. If the sender matches the safe senders hash, the message bypasses content filtering. If the sender matches the blocked senders hash, the message is blocked.

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

• Minimizes storage and replication space   Most of the time, hashing reduces the size of the data 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 stored and replicated in Active Directory.
• 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 don't yield usable e-mail addresses for malicious users who might compromise an Edge Transport server.

Return to top

Enabling Safelist Aggregation

Safelist aggregation is enabled by default in Exchange 2010. Unlike in Exchange Server 2007, you don't need to manually run the Update-SafeList cmdlet to hash and write the safelist collection data to Active Directory. In Exchange 2010, this is accomplished behind the scenes by the Junk E-mail Options mailbox assistant.

You can still manually run safelist aggregation by using the UpdateSafelist cmdlet. 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 stored on the attribute. If the two values are identical, the Update-SafeList cmdlet doesn't 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.

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 AD LDS.

Return to top