Using Safelist Aggregation (PART 2)

If you would like to read the first part of this article series please go to Using Safelist Aggregation (PART 1).

Introduction

The first part of this article was about explaining the different kinds of data involved in a safelist aggregation process and how this data flows from the user’s mailbox to the Active Directory first, and to the Exchange Edge ADAM at last.

In this second part I will provide the detailed instructions to configure safelist aggregation using the Exchange Management Shell and the Task Scheduler.

Solution Topology

For the purpose of this article, I used the following environment on my test lab:

Figure 1: Solution Topology

All systems were virtualized with Windows Server 2008 R2 Hyper-V.

Table 1: List of machines

Requirements

In order to implement safelist aggregation, the following minimum requirements should be met:

• Exchange Server 2007 – Safelist aggregation is an Exchange Server 2007 intrinsic process, previous versions of Exchange use the Safelist Collection data *after* processing the organization-wide anti-spam settings. Previously, if a message was blocked at the gateway level (by IMF for example), it would never be delivered to the user.
  With Exchange Server 2007, the user settings are imported and respected by the anti-spam agents at the transport level.
  

• Microsoft Office Outlook 2003 or higher – Outlook Junk E-Mail settings were introduced with the 2003 version, so you need at least this version or higher in order to provide users the ability to populate the Safelist Collection. Outlook Web Access can also be used (Figure 2).

Figure
2: Outlook Web Access

Configuration Tasks

Setting up safelist aggregation is actually quite simple, there are only a few steps involved:

1. Upload safelist information from Microsoft Office Outlook users to Active Directory using the Update-Safelist cmdlet.

2. Schedule periodic updates of safelist aggregation to make sure that the most up-to-date safelist aggregation information is in the Active Directory.

The Update-SafeList cmdlet reads the safelist aggregation data that is stored on a Microsoft Office Outlook user mailbox (user’s Safe Senders List and Safe Recipients List) and then hashes and writes the data to the corresponding user object in Active Directory.

The cmdlet has the following syntax:

Update-SafeList -Identity <MailboxIdParameter> [-Confirm [<SwitchParameter>]] [-DomainController <Fqdn>] [-IncludeDomains <SwitchParameter>] [-Type <SafeSenders | SafeRecipients | Both>] [-WhatIf [<SwitchParameter>]]

There are 2 switch parameters that you should pay special attention:

• IncludeDomains: This option was introduced with Exchange Server 2007 SP1. It is not recommended to upload safe domains defined by users to the Active Directory (and thus to the Edge ADAM by means of Edge Sync), since this could mean a large collection of email addresses that can be used by spammers. By default, domains that are specified by the senders are not included.
• Type: Although the safelist collection includes the user’s Safe Recipients List, the content filtering functionality does not act on safe recipient data. Because of that, it’s not recommended to run the Update-Safelist cmdlet with the Type parameter set to SafeRecipients or Both values. The default value for the Type parameter is SafeSenders.

The step-by-step process to setup and configure safelist aggregation should look something like this:

1. Create a PowerShell script (updateSafelistAggregation.ps1) with the proper configured Update-Safelist cmdlet, in order to read the Safelist Collection data from all the mailboxes in the Exchange Organization. to update safelist information for Microsoft Office Outlook users:
   get-mailbox -ResultSize Unlimited | where {$_.RecipientType -eq [Microsoft.Exchange.Data.Directory.Recipient.RecipientType]::UserMailbox } | Update-SafeList

2. Create a batch file (RunUpdateSafelist.bat) that will be used to start the previous created PowerShell script:
   %windir%\system32\WindowsPowerShell\v1.0\PowerShell.exe -PSConsoleFile “%ProgramFiles%\Microsoft\Exchange Server\bin\exshell.psc1” -Command “. ‘%ProgramFiles%\Microsoft\Exchange Server\Scripts\updateSafelistAggregation.ps1′”

3. Schedule the task to run every day, by using the AT command or by running Windows 2008 Task Scheduler (Start > All Programs > Accessories > System Tools > Task Scheduler).
   Using the AT command:
   at 23:00 /every:M,T,W,Th,F,S,Su cmd /c “C:\Tasks\RunUpdateSafelist.bat”

Using Windows 2008 Task Scheduler:

1. Start Task Scheduler. In the Actions Pane, click Create Basic Task. On the Create a Basic Task window, type in a unique name (Figure 3). Click Next.

Figure 3: Create a Basic Task

2. On the Task Trigger page, select Daily (Figure 4) and click Next. Set a starting date and time (Figure 5) and click Next.

Figure 4: Task Trigger

Figure 5: Daily

3. On the Action page, select Start a program (Figure 6) and click Next. Browse to the runUpdateSafelist.bat location (Figure 7) and click Next.

Figure 6: Action

Figure 7: Start a Program

4. Review the Summary page, check Open the Properties dialog for this task when I click Finish and click Finish.

Figure 8:
Summary

5. On the task properties, check the following options: Run whether user is logged on or not and Run with highest privileges. Click OK.

Figure 9: Task Advanced Properties

Figure 10: Task Scheduler

Testing Safe Recipients List

After the task is run at least once, we can start doing some tests. In order to do that, I started a telnet session to the Exchange Edge Server, and tested 3 different scenarios (Figure 11):

1. Message sent from a safe senders domain (@microsoft.com): the message was classified as spam and rejected because I followed the recommendation and didn’t upload user’s safe domains to AD and ADAM.

2. Message sent from a safe sender ([email protected]): althoug the message was clearly spam, it was accepted, because the safe senders list is being respected (Figure 12).

3. Can one user’s safe sender ([email protected]) send mail to the entire organization? My next test was to verify if the users classified as safe by “James Bond” could send email to “Mata Hary”. The answer is no! The message was classified as spam and rejected.

Figure 11: SMTP test

Figure 12: James Bond’s Inbox

By using the excellent Content Agent Log Message Tracker GUI tool, developed by Glen Scales, we can clearly see what happened to each message sent. Notice that the accepted message for “James Bond” bypassed the content filter agent (Figure 13).

Figure 13: Message tracking

Basic Troubleshooting

If you find things are not working as expected, there are some troubleshooting steps you could follow.

1. Verify that Safelist Collection data is being replicated to Active Directory. This can easily be done by using a tool like ADSI Edit or AD Explorer, finding a user object and opening its properties. The msExchSafeSendersHash attribute should have a hexadecimal value like \04\E4\2E\7E\C2\B5\C3\7E (Figure 14), and not <Not Set>.

Figure 14: msExchSafeSendersHash attribute in AD

2. Use the Test-EdgeSynchronization cmdlet on a Hub Transport server to determine whether the subscribed Edge Transport server have a current synchronization status. You can use the Start-EdgeSynchronization cmdlet to start immediate synchronization and bring ADAM up to date.

3. Verify that the Microsoft Exchange EdgeSync service is replicating safelist aggregation data to the Active Directory Application Mode (ADAM) directory service. The best way to do this is by running the ADAM ADSI Edit tool on the Edge server:

a)       Determine the GUI associated with the user for which you want to verify EdgeSync synchronization results. You can use ADSI Edit to connect to Active Directory, for example (Figure 15). The previous determined GUID is represented as the recipient’s canonical name (CN) in ADAM.

Figure 15: objectGUID

b)       On the Exchange Edge server, run the ADAM ADSI Edit tool. On the Action menu, click Connect to. Type 50389 in the Port field and insert OU=MSExchangeGateway as the Distinguished name (DN) or naming context (Figure 16). Click OK.

Figure 16: Connection Settings

c)        Expand the LDAP tree, and under Recipients find the GUID of the desired user. Right click it, select Properties and verify that the msExchSafeSendersHash attribute contains a proper hash value.

4. The safelist aggregation feature relies on content filtering to recognize the senders on an Outlook user’s Safe Senders List. Verify that content filtering is enabled on the servers where you are running anti-spam features and that safelist aggregation is functioning correctly. Use the following command to enable content filtering:
   Set-ContentFilterConfig -Enabled:$true
   

Conclusion

Having user’s safelist collection data uploaded to AD and ADAM, enables the Exchange Transport services to screen senders appropriately, reducing the operational overhead involved with filtering mail.

Safelist Aggregation helps reducing false positives in anti-spam filtering, by giving the ability to the users of defining who their safe senders are. From a messaging administrator point of view, it really pays off, since the setup, configuration process and day to day operation is not complex.

Regarding the future, although Exchange Server 2010 is still in Beta, it looks like Safelist Aggregation will have little or no differences at all.

Related Links

• How to Configure Safelist Aggregation
• How to Verify EdgeSync Results for a Recipient
• Exchange Server 2010: Configure Safelist Aggregation
• ADAM Administration Tools
  

If you would like to read the first part of this article series please go to Using Safelist Aggregation (PART 1).