Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
Topic Last Modified: 2012-11-29
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
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.
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.
| Important: |
|---|
| Although the safe recipient data is stored in Outlook and can be aggregated into the safelist collection on the AD LDS instance on the Edge Transport server, the content filtering functionality doesn't act on safe recipient data. |
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.
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.
Options available in the msexchangemailboxassistants.exe.config file
To activate the options to include safe domains, or to change the maximum values for the default settings, you must change the msexchangemailboxassistants.exe.config file. Specifically, the following settings and values can be changed in the appsettings section of the msexchangemailboxassistants.exe.config file:
| Setting | Value |
|---|---|
|
IncludeSafeDomains |
The value for this setting can be True or False. |
|
UpdateInterval |
By default, the value for this setting is 15 minutes. This setting can have a value from 15 minutes through 1 day. |
|
TestUpdateInterval |
TestUpdateInterval is used in test environments. This setting can have a value from 10 seconds through 1 hour. |
|
MaxSafeSenders |
3*1024 |
|
MaxSafeRecipients |
2*1024 |
|
MaxBlockedSenders |
By default, the value for this setting is 500. The maximum value is 1000. |
For example, the settings in the appsettings section of the msexchangemailboxassistants.exe.config file may be as follows:
 Copy Code |
|
|---|---|
<configuration> <runtime> <gcConcurrent enabled="false" /> <generatePublisherEvidence enabled="false" /> </runtime> <appSettings> <add key="IncludeSafeDomains" value="true" /> </appSettings> </configuration> |
|