You have an Exchange Server 2010 organization that contains five Hub Transport servers, five
Mailbox servers and one Edge Transport server. You need to provide a solution to ensure that users
can prevent legitimate inbound e-mail messages from being classified as spam. What should you do?

A.
Enable sender filtering

B.
Enable Sender ID filtering

C.
Configure a custom MailTip

D.
Configure safelist aggregation

Explanation:
Safelist Aggregation
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 Microsoft Exchange. This
functionality collects data from the antispam 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 you configure safelist aggregation, the Content Filter agent passes safe email messages to the
organization’s 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 can be 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 included in this list. 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 P2 From: field of the e-mail message 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.
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 Server 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. A user can have up to 1,024 unique
entries in a safelist collection.
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 Server 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 antispam functionality of Exchange Server 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. EdgeSync replicates the safelist collection to the Active Directory Application Mode
(ADAM) instance on the Edge Transport server.
Note Safelist collection entries are one-way hashed (SHA-256) before they are stored in Active
Directory. This minimizes storage and replication size, and it renders the safelist collections
unreadable by malicious users.
Hashing of Safelist Collection Entries
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
command on a user’s mailbox. The Update-SafeList command 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 command compares the binary attribute that was
created to any value that is stored on the attribute. If the two values are identical, the UpdateSafeList command does not update the user attribute value with the safelist aggregation data. If the
two attribute values are different, the Update-SafeList command 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 use of Update-Safelist ensures that
the most up-to-date safelist aggregation is in Active Directory.
To make the safelist aggregation data in Active Directory available to Edge Transport servers in the
perimeter network, you must install and configure the EdgeSync tool so that the safelist aggregation
data is replicated to the Active Directory Application Mode (ADAM) instance on the Edge server.