Sunday, April 20, 2008

Outlook Safelist aggregation

You use Exchange 2007 Content Filtering Agent for spam fighting, there is sometimes occasions when it classifies mail as spam even though it’s not. Content Filtering Agent is using a whitelist that is managed from outlook or OWA. This whitelist is by default not propagated to to your Edge servers or hub server if you have installed antispam agents on it. There is two steps to make this happen, first users must enter addresses into the safelist next step is for the administrator to aggregate this information and save it into AD user object.

This list can be edited in outlook by clicking ToolsOptionsJunk E-mail buttonSafe Senders tab. There is also an option here and there in outlook that says “Add Sender to Safe Senders List”. The list itself is stored inside each user mailbox located on the Exchange mailbox server.

Ok, so how can you get Exchange 2007 Edge server or if you have Exchange HUB/Transport server with antispam agents installed to read this info?

It will not happen automatically, the administrator must make this happen. The easiest way is to run Update- Safelist cmdlet on a scheduled basis. What this command does is reading the safelist inside users mailboxes and writes this info to users AD account. Email addresses are hashed before saved into msExchSafeSendersHash attribute so information cannot be read and used in a bad way.

If you’re using Exchange 2007 Edge server, the edge-sync process will synchronize this attribute from Active Directory to ADAM that Edge server leverage each time edge-sync is run.

The complete process is.
· User adds addresses to there’s safelist with help of outlook
· Administrator run the Update-Safelist cmdlet (this should be set up with a scheduled task)
· If you don’t have Edge servers and have antispam agents installed on your HUB/Transport server, you’re done, Content Filtering agent on Edge server have to wait for this info until edge-sync runs.

End users should not expect that there safelist will work at once because the Update-Safelist must be run and also the edge-sync process.

· mail from is sent to user1
· user1 has no info in the safelist
· mail gets a high SCL value and is either blocked or rerouted to Junk E-mail folder

But if the user1 has in the safelist and the administrator has run outlook-safelist command, content filter agent will set a SCL value of -1 to the mail and it’s therefore not blocked by content filter agent.

But if is sent the same mail to user2 it will get the high SCL value and either be blocked or rerouted to Junk E-mail folder. You see the safelist is personal to each user.

You can see what mail and why Content Filter agent is blocking mail in the agent log file, default located in C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\AgentLog

There is also a performance counter that is good to look at when dealing with Safe-Senders. Performance Object is “MSExchange Content Filter Agent” and the counter is “Bypassed recipients due to per-recipient Safe-Senders”. This number will tell you how many mail that have bypassed content filter agent because users have added mail addresses to there’s safelist.

How to schedule the safelist aggregation.

Create a powershell script file ex. “C:\Batch\safelist-aggregation.ps1”
You only need one line of code in that file.
Get-Mailbox where {$_.RecipientType -eq ‘UserMailbox’ } Update-Safelist -Type Both
This will update the safelist from all user mailboxes.
There may be need for filter the Get-Mailbox cmdlet in so you not get all mailboxes in the search but only those located on a specific server or databases.
“Get-Mailbox –Server …”
“Get-Mailbox –Database …”

Create a scheduled task to run the powershell script.
C:\WINDOWS\SYSTEM32\windowspowershell\v1.0\powershell.exe -PSConsoleFile "C:\Program Files\Microsoft\Exchange Server\Bin\ExShell.psc1" -Command C:\batch\safelist-aggregation.ps1

How often the scheduled task is run, is up to the administrator to decide. Factors are Active Directory replication, site layout, number of users to collect safelist from etc.
By enabling safelist aggregation users will be happier since mail from there’s contacts and safelist will not end up as spam in the Junk e-mail folder.

Sunday, April 6, 2008

Anonymous submission and relay of SMTP messages in Exchange 2007

When organizations install Exchange 2007 they often get problems because they have applications and sometimes users sending SMTP mail to there’s mail server. In previous version of Exchange this was not a problem since it allowed receiving of mail without authentication, with Exchange 2007 this is no longer the case. Default setting on the “Default servername” receive connector is not to allow anonymous users.

The easiest thing to do is to check the “Anonymous users”, but are you really sure you want to do this? There is a good reason not to allow anonymous submission of SMTP mail and that’s getting rid of the anonymity on your network. If you really need to accept anonymous submission then I suggest that you create a new receive connector that allow anonymous users and only accept mail from certain IP (look on the network tab and ) that cannot send mail authenticated, this also makes the “Default servername” receive connector have its default settings.A common misunderstanding is that by allowing anonymous users also makes it possible to relay mail, this is not the case. To allow relaying users or the application must authenticate the SMTP session. If mail is destined to internal users then there is no need to allow relaying, it’s only needed when mail is destined to external recipients.Default settings on receive connectors is set to allow “Exchange users” to relay. Exchange users is all users that have a mailbox, so by creating a mailbox for the application and make the application authenticate it will also be allowed to relay. Type of authentication is specified on the “Authentication” tab.

The most common authentication method is “Basic Auth.”. Exchange 2007 settings is to only allow basic auth after that TLS has been started, and that is not so common that applications can do TLS. TLS is similar to SSL and it encrypts the transmission so it’s a good thing if it can be enabled in the application. Integrated Windows Authentication is good to use if your applications can use it.
Another good thing if you can make your application authenticate when sending SMTP mail is they bypass spam checks done by Exchange. You can see this if you run
Get-ADPermission "receive connector name" where {$_.User -like 'NT AUTHORITY\Authenticated Users' -and $_.isinherited -eq $False} ft User, ExtendedRights –autosize

Spam checks are only done if you have installed the antispamagents on your HubTransport server.

If you really want to allow relay without authentication (=anonymous relay) you should read