Pro Exchange 2013 SP1 PowerShell Administration: For Exchange On-Premises and Office 365 (2014)

Chapter 6. Message Hygiene

About 95 percent of all messages sent across the Internet are some kind of spam—commercial messages from malicious organizations or infected computers. Well-known spam messages are for illegal Viagra pills, penis enlargement, and imitation Rolex watches, or are solicitations from Nigerian banks or people in Hong Kong who want to offer you millions of dollars if only you’d give them your bank account password.

But not all messages are spam. There’s a second category of bulk mail, which are advertisements whose sponsors have drawn your email address from a distribution list that you might once have subscribed to but have forgotten about.

Message hygiene is the term for dealing with all these unsolicited email messages. They have to be filtered out, so that only your expected and customary messages are delivered to your inbox.

There are two basic ways of performing message hygiene:

1. Using an on-premises message hygiene solution. The Exchange 2013 Edge Transport server is a common example of this. You install, configure, and maintain the server, and it takes care of all those unsolicited email messages.

2. Using an online message hygiene solution. The Exchange Online Protection (EOP) is such a solution. All messages destined for your organization are delivered to the Microsoft data center; Microsoft cleans out the unsolicited email and delivers only your regular email to your internal Exchange organization.

In this chapter we discuss the on-premises message hygiene solution utilizing the Exchange 2013 Edge Transport server. The online message hygiene solution using Exchange Online Protection is discussed in Chapter 11.

The Exchange 2013 Edge Transport Server

Microsoft introduced the Edge Transport server in Exchange Server 2007, continued it in Exchange Server 2010, and unfortunately made it unavailable in Exchange 2013 RTM. However, it was reinstituted in Exchange 2013 SP1.

The Edge Transport server is a first line of defense, so it is located in the perimeter network and is not, therefore, a member of the internal Active Directory domain. In fact, you can have, and probably do have, multiple Edge Transport servers on your perimeter network. The positive side of this is that when the Edge Transport server gets compromised, the internal Active Directory is untouched. The downside, however, is that there’s no shared configuration and so you have to configure all the Edge Transport servers manually, although there’s an export and import utility to keep all the Edge Transport servers identical; the mechanism it uses is called cloning(more about this later in chapter).

The Edge Transport servers need to have some knowledge of the Exchange configuration on the internal network, however; otherwise, it would be hard to route messages to the correct Mailbox server on that internal network or to perform recipient filtering. Therefore, there exists a synchronization mechanism between the Mailbox servers on the internal network and the Edge Transport server on the perimeter network. This mechanism is called edge synchronization. Using edge synchronization, the Mailbox servers push (limited) information to the Edge Transport servers on a regular basis.

So, the Edge Transport servers act as your primary defense when it comes to Simple Mail Transfer Protocol (SMTP) traffic, and all inbound messages are routed via your Edge Transport servers. The MX records in the public Domain Name Service (DNS) point to your Edge Transport servers. You can have multiple MX records whereby each MX record points to a particular Edge Transport server.

A simple representation of a network of two Edge Transport servers and two Mailbox servers is shown in Figure 6-1.

Figure 6-1. The Edge Transport servers are typically located in the perimeter network

The Edge Transport servers are not bound to a particular site, but edge synchronization is bound to a particular site in Active Directory. So, if you have two Edge Transport servers at a site called Amsterdam, as shown in Figure 6-1, the two Edge Transport servers are synchronized with the two Mailbox servers at this site. If you have an additional site in London, the Edge Transport servers will not send information directly to the Mailbox servers in Amsterdam. If you want to implement two Edge Transport servers at a site called London, then, you have to create an edge synchronization there as well, and then this edge synchronization is bound to the Mailbox servers at that London site. There have to be separate MX records pointing to these Edge Transport servers as well. When building a configuration like this, you automatically get site redundancy.

The Edge Transport servers are not only used for inbound SMTP traffic; they are also used for outbound SMTP traffic. The Exchange 2013 Mailbox servers use the Edge Transport servers to route SMTP messages to the Internet. So, besides performing message hygiene, the Edge Transport servers process inbound and outbound messages, following transport rules. Such rules may include adding a disclaimer to a message, putting a tag or header on a message, or maybe even blocking an inbound or outbound message based on certain criteria.

Installation of an Exchange 2013 Edge Transport Server

Installing an Exchange 2013 Edge Transport server involves four main steps: preparing the server, installing the actual Exchange software, creating the edge subscription, and starting the edge synchronization.

Preparing the Server

The latest version of Windows is my preferred operating system for installing Exchange 2013. Exchange 2013 SP1 and higher is supporting Windows Server 2012 R2. Windows Server 2012 R2 has mainstream support until 2018, and extended support until 2023. Of course, it is also possible to install Exchange 2013 on Windows Server 2008 R2, but mainstream support ends in January 2015. Remember that it is not possible to upgrade the operating system once Exchange 2013 is installed, so if you want to upgrade your operating system on the Exchange 2013 server, you have to fully reinstall the Edge Transport server.

As just mentioned, the Edge Transport servers are installed in the perimeter network and are not members of the internal Active Directory domain. The Edge Transport servers do, however, need a fully qualified domain name (FQDN). To set a FQDN like AMS-EDGE01.CONTOSO.COM, you have to change the name of the computer and click the More button, as shown in Figure 6-2. Here, you can change the primary DNS suffix of this server: you enter the domain name, click OK twice, and reboot the server.

Figure 6-2. Changing the DNS suffix of the Exchange 2013 Edge Transport server

Note You can only change the FQDN of the server before the Edge Transport server role is installed. Changing the FQDN when the Edge Transport server is installed will break everything, and the Edge Transport server will need to be reinstalled.

When the server is configured and the latest fixes from Windows Update (or any other updating mechanism you use) are installed, the prerequisite software can be installed. For the Edge Transport server, only the .NET framework (part of Window Server 2012 R2) and the Active Directory lightweight directory service (AD LDS) need to be installed. You can install this prerequisite software by entering the following command in a PowerShell window with elevated privileges:

Install-WindowsFeature NET-Framework, ADLDS, Telnet-Client

Note The Telnet Client is not officially needed for the Edge Transport server to work properly, but I find it useful for troubleshooting purposes.

Installing the Server

To install the Exchange 2013 Edge Transport server, you open a Windows command prompt with elevated privileges, navigate to the Exchange 2013 SP1 installation media, and enter the following command:

Setup.exe /Mode:Install /Roles:EdgeTransport /IAcceptExchangeServerLicenseTerms

This will install the Exchange 2013 SP1 Edge Transport server, as shown in Figure 6-3. After installation, the server needs to be rebooted.

Figure 6-3. Installing the Exchange 2013 Edge Transport server

Note Make sure that the Edge Transport server can resolve the Exchange 2013 Mailbox servers on the internal network. This can be achieved by using DNS on the internal network (depending on your preferred server configuration, of course) or by using a HOSTS file where the FQDN and the IP addresses of the internal Exchange 2013 Mailbox servers are entered.

Creating an Edge Subscription

When the Edge Transport server is installed, you can create the edge subscription. When the edge subscription is created, you can start the edge synchronization, which will push all needed information from the Mailbox server to the Edge Transport server.

Creating the edge subscription consists of the following steps:

1. Create an XML file on the Edge Transport server with the configuration information.

2. Copy the XML file to the Exchange 2013 Mailbox server.

3. Import the XML file into the Exchange 2013 Mailbox server.

4. Start the edge synchronization.

To create the configuration XML file on the Edge server, you open an Exchange Management Shell with elevated privileges and enter the following command:

New-EdgeSubscription -FileName C:\Temp\Edge01.xml

This will create an XML file with all information from the Edge Transport server that’s needed by the Exchange 2013 Mailbox server. You copy the XML file to the Exchange 2013 Mailbox server, and on this server you enter the following command in the Exchange Management Shell:

[byte[]]$FileData = Get-Content -Path C:\Temp\edge01.xml -Encoding Byte -ReadCount 0

New-EdgeSubscription -FileData $FileData -Encoding Byte -Site Amsterdam -CreateInternetSendConnector $true -CreateInboundSendConnector $true

This will begin the edge subscription. Please note the –Site parameter that defines which Active Directory site the Edge Transport server will be bound to.

Beginning the Edge Synchronization

To start the synchronization between the Exchange 2013 Mailbox server and the Edge Transport server, you enter the following command in the Exchange Management Shell on the Mailbox server:

Start-EdgeSynchronization

As mentioned before, for this synchronization to work properly you have to make sure that the Exchange 2013 Mailbox server can resolve the Edge Transport server using the DNS; this typically involves adding the Edge Transport server to the DNS on your internal network.

An informational message is shown on the console when the edge subscription is created. This is one of the most common signs when the edge synchronization will not start. Another pitfall is the firewall between the Exchange 2013 Mailbox server and the Edge Transport server. The edge synchronization is using port 50636 to push information to the Edge Transport server, so you have to make sure that this port is open on the firewall to the perimeter network.

When name resolution and the firewall are properly configured, the edge synchronization should start immediately, as shown in Figure 6-4.

Figure 6-4. Proper start of the edge synchronization

That is all it takes to install the Exchange 2013 Edge Transport server, create the edge subscription, and start the edge synchronization. All relevant settings configured on the internal Exchange 2013 organization for proper functioning of the mail flow are synchronized at this point, including the accepted domains on the internal organization and the send connectors between the Edge Transport server and the internal Exchange 2013 Mailbox servers. You can open the Exchange Management Shell on the Edge Transport server and execute the Get-AcceptedDomaincommand. This will reveal the accepted domains as they are configured on the internal Exchange organization, as shown in Figure 6-5.

Figure 6-5. The accepted domains now available on the Edge Transport server

At the same time, if you want to make changes to certain settings on the Edge Transport server, you have to make them on the Exchange 2013 Mailbox server. For example, if you want to enable logging onto the receive connector of the Edge Transport server, you have to issue the command on the Exchange 2013 Mailbox server. To enable protocol logging, for example, you open the Exchange Management Shell on the Exchange 2013 Mailbox server and enter the following command:

Get-ReceiveConnector | Set-ReceiveConnector –ProtocolLoggingLevel Verbose

To change the FQDN of the Edge Transport server when an EHLO command is sent from another host to another FQDN, you can execute the following command, again on the Exchange 2013 Mailbox server:

Get-ReceiveConnector | Set-ReceiveConnector –Fqdn smtphost.contoso.nl

When it comes to making changes to the Edge Transport server, you always have to be conscious of where you are making those changes. Changes related to message flow have to be made on the Exchange 2013 Mailbox server, but server-specific settings can be made on the Edge Transport server itself.

Anti-Spam Settings

Inbound SMTP messages from the Internet are delivered to the Edge Transport server and are processed there for message hygiene in a certain order, as shown in Figure 6-6.

Figure 6-6. The order of message processing on an Exchange 2013 Edge Transport server

As can be seen in Figure 6-6, the first and most important step in message hygiene is connection filtering. This is where messages that come from IP addresses or ranges that are on block lists are filtered out. In fact, this constitutes the majority of all email entering the Edge Transport server.

The Edge Transport server works with transport agents. The following transport agents are available on the Edge Transport server:

· Connection filtering agents

· Sender Filter agent

· Recipient Filter agent

· Sender ID agent

· Content Filter agent

· Sender Reputation agent

· Attachment Filter agent

You can retrieve a list of transport agents by running the Get-TransportAgent cmdlet in the Exchange Management Shell on the Edge Transport server, as shown in Figure 6-7. Note that all transport agents are enabled by default and are configured with default settings.

Figure 6-7. Transport agents available on an Edge Transport server

In this section I explain the major transport agents and how to configure them, but there’s one thing to note here that’s not a default Transport Edge server configuration. Some receiving SMTP hosts on the Internet perform a reverse DNS lookup as an additional means of message hygiene, so let’s cover that first.

Also, as explained earlier, the only way to configure the Edge Transport server is by using the Exchange Management Shell. There’s no GUI available for managing the Exchange 2013 Edge Transport server.

Reverse DNS

As just mentioned, some SMTP servers perform a reverse DNS lookup when an SMTP server tries to deliver a message. Although it’s not an Exchange feature, it is important. When doing so, the receiving server tries to determine whether the source IP address really matches the FQDN being used. For example, suppose the Edge Transport server is using 176.62.196.249; when a reverse DNS lookup is performed, it should return ams-edge02.exchange16.com, as shown in Figure 6-8 (https://www.misk.com/tools/#dns).

Figure 6-8. Testing the DNS reverse lookup by using misk.com

Note There are mail servers that graylist or even block messages when the PTR message doesn’t match or isn’t available, so it’s important to pay attention to the reverse DNS lookup!

Connection Filtering Agents

Connection filtering is the first default layer of defense when SMTP messages access the Exchange 2013 Edge Transport server. When a sending SMTP server on the Internet sets up a connection on port 25 to the Edge Transport server, the server checks this sending SMTP server. If there’s something wrong, the connection is closed, even before any mail data is sent to the Edge Transport server.

There are four ways to configure the connection filtering:

· IP Allow list

· IP Allow list providers

· IP Block list

· IP Block list providers

IP Allow List

When a remote SMTP server sets up a connection with the Edge Transport server to send a message, the Edge Transport server checks to see if the IP address this remote SMTP server is using is white-listed. In general, a white-list is a list of server names or IP addresses of SMTP servers that are trusted. If it is, this remote SMTP server is assumed to be safe and the connection is allowed; the message is accepted.

To add an IP address to the IP Allow list, you can use the Add-IPAllowListEntry, followed by the IP address of the remote SMTP server; for example,

Add-IPAllowListEntry –IPAddress 194.165.34.254

The output is shown in Figure 6-9.

Figure 6-9. Adding an IP address to the IP Allow list

When a remote SMTP server is white-listed by the Edge Transport server, a special rating of -1 is stamped on the message; more specifically, an X-header is added to the message. This way Exchange knows the message is safe and treats it as such—that is, this message is not processed by any other anti-spam agent on the Edge Transport server.

When checking the header of a message originating from this host, you will see something like this:

Return-Path: administrator@contoso.com
X-MS-Exchange-Organization-Antispam-Report: IPOnAllowList
X-MS-Exchange-Organization-SCL: -1
X-MS-Exchange-Organization-AuthSource: SMTPHOST.exchangelabs.nl

IP Allow List Providers

Instead of adding IP addresses manually to the IP Allow list, it is possible to use IP Allow list providers. These providers have lists of trusted SMTP servers—that is, servers that are definitely not associated with any spam activity.

You have to be careful when implementing these providers. As explained in the previous section, messages sent by allowed SMTP hosts are automatically tagged an SCL of -1, which means these messages flow through the Exchange organization without being inspected by any other anti-spam agent; therefore, the provider needs to be completely trustworthy.

There are a number of providers, sometimes referred to as white-list providers, available on the Internet; for example, there is Spamhaus Whitelist (http://www.spamhauswhitelist.com) or the DNS White Label organization (http://www.dnswl.org).

Be aware that this is a matter of getting what you pay for; there are no reliable and free IP Allow list providers. Therefore, I suggest not using an IP Allow list provider and instead relying on the IP Block lists and IP Block list providers.

IP Block List

An IP Block list is the exact opposite of an IP Allow list. When an external SMTP server sets up a connection with the Exchange 2013 Edge Transport server, and this SMTP server is on the Edge Transport server’s Block list, the connection is automatically voided.

To add an IP address to the Edge Transport server’s Block list, you can use the Add-IPBlockLIstEntry command followed by the IP address of the SMTP server you want to block; for example,

Add-IPBlockListEntry –IPAddress 192.168.10.100

It is also possible to add a range of IP addresses to the Block list; for example,

Add-IPBlockListEntry –IPRange 192.168.10.0/24

To add an IP address to the Block list temporarily, you use the –ExpirationTime parameter. To add the SMTP server to the Block list but have it automatically removed on September 1, 2014, you would use the following command:

Add-IPBlockListEntry –IPAddress 192.168.10.100 –ExpirationTime "9/1/2014 00:00"

To get an overview of all IP addresses that are on the Edge Transport server’s Block list, you can use the Get-IPBlockLIstEntry command, without any parameters.

To review the IP Block list configuration of the Edge Transport server, you can use the Get-IPBlockListConfig command.

Note The IP Block list is configured on a per server basis. If you have multiple Edge Transport servers, you have to configure them individually, but this is prone to error. When deploying the Edge Transport servers, you can also configure one Edge Transport server and export the configuration to subsequent Edge Transport servers. However, remember that changes also need to be made to lists on all Edge Transport servers.

Configuring and maintaining the IP Block lists is quite some work, so it’s better to automate this task by using an IP Block list provider.

IP Block List Providers

To automate maintenance of the IP Block list, you can use an IP Block list provider. The process is identical to a regular IP Block list as discussed in the previous section, but instead of your maintaining the IP Block list entries manually, the entries are maintained by a provider.

One well-known provider is SpamHaus (www.spamhaus.org), in particular their Zen Combined Block List. To configure this provider, you open the Exchange Management Shell on the Edge Transport server and enter the following command:

Add-IPBlockListProvider -Name SpamHaus -LookupDomain zen.spamhaus.org -Enabled $true -BitmaskMatch $null -Priority 1 -AnyMatch $true -RejectionResponse 'Message blocked due to black listing'

This is shown in Figure 6-10.

Figure 6-10. Adding SpamHaus as a Block list provider

You can use the –RejectionResponse parameter of the Add-IPBlockLIstProvider command to add a customer message that’s returned to the sender of the message, but the message cannot exceed 240 characters.

It is possible to disable the IP Block list function on a per-user basis. This way, it is always possible for particular recipients to receive email messages, regardless of any IP Block list provider. To set this, you can use the Set-IPBlockListProvidersConfig command with the –ByPassedRecipients parameter. For example, to bypass the IP Block list filtering for a user named jaap@contoso.com, you can use the following command:

Set-IPBlockListProvidersConfig –ByPassedRecipients "jaap@contoso.com"

To add or remove multiple recipients at the same time as when the IP Block list provider is configured, you can use the @{Add="recipient"} syntax:

Set-IPBlockListProvidersConfig –ByPassedRecipients @{Add="jaap@contoso.com","michel@contoso.com"; Remove="marina@contoso.com"}

The IP Block list typically works for connections coming from the Internet—that is, external connections. It is also possible to configure the IP Block list for internal use; you use the –InternalMailEnabled parameter. By default this function is turned off, but you can enable it using the following command:

Set-IPBlockListProvidersConfig –InternalMailEnabled $true

Sender Filtering

Sender filtering is a default feature in the Edge Transport server that enables you to filter messages based on the sender. This agent does the blocking based on the SMTP header Mail From in the message. If the agent reads a name that’s also in the Sender Filter list, the messages is blocked.

You can use the Get-SenderFilterConfig command to check the current configuration of the Sender Filter configuration, as shown in Figure 6-11.

Figure 6-11. The configuration of the Sender Filter

To add a particular sender to the Sender Filter configuration, you can use the Set-SenderFilterConfig command. This command takes the –BlockedSenders parameter to add specific senders, but you can also use the –BlockedDomains and –BlockedDomainsAnsSubdomains parameters to add complete domains to the Sender Filter configuration. For example, to add a user called john@alpineskihouse.com to the blocked senders list, and to add the cheapwatches.com domain to the list of blocked senders, you can use the following command:

Set-SenderFilterConfig -BlockedSenders "John@alpineskihouse.com" -BlockedDomains "cheapwatches.com"

If you want to block senders from the northwindtraders.com and all its subdomains, you can use the following command:

Set-SenderFilterConfig -BlockedDomainsAndSubdomains northwindtraders.com

These properties are multi-value, which means they can contain more than one value. If you want to add multiple senders to the Sender Filter configuration later on, you have to use the @{Add="sender"} syntax. If you want to remove senders from the Sender Filter configuration, you have to use the @{Remove="sender"} syntax. For example,

Set-SenderFilterConfig -BlockedSenders @{Add="onlinecasino@gmail.com","enlargement@hotmail.com"; Remove="john@alpineskihouse.com"}

You have to use the same syntax if you want to add or remove domains from the BlockedDomains and BlockedDomainsAndSubDomains properties.

To get an overview of all blocked senders and domains on your Edge Transport server, you can use the Get-SenderFilterConfig again; for example,

Get-SenderFilterConfig | Format-List BlockedSenders,BlockedDomains,BlockedDomainsAndSubdomains

Note Only anonymous connections are processed by the Sender Filter agent.

It is possible to configure the Sender Filter agent to filter out messages that don’t have anything listed in the Mail From header of a message. This safeguards your organization from NDR attacks from the Internet. To configure this, you use:

Set-SenderFilterConfig -BlankSenderBlockingenabled $true

Note It is relatively easy to spoof the Mail From header in an email message. Therefore, it is not recommended you rely exclusively on the Sender Filter agent.

Recipient Filtering

Recipient filtering on the Edge Transport server gives you the opportunity to accept messages only for existing recipients in your Exchange environment. As its name implies, the Recipient Filter agent on the Edge Transport server only accepts messages with a valid recipient in your Exchange 2013 organization.

The accepted domains configured in an Exchange 2013 environment have a property called AddressBookEnabled. This property enables or disables recipient filtering for an accepted domain. By default, the Recipient Filter agent is enabled for authoritative accepted domains and is disabled for accepted domains that are configured as internal relay domains or as external relay domains.

To check the value of the AddressBookEnabled property, and thus the status of the Recipient Filter agent, you can use the following command:

Get-AcceptedDomain | Format-List Name,AddressBookEnabled

If you want to disable the Recipient Filter agent, you can use the following command:

Set-RecipientFilterConfig -Enabled $false

You can use recipient filtering not only to block messages to unknown recipients but also to block individual recipients in your Exchange 2013 organization; you do this by adding them individually, using the following command:

Set-RecipientFilterConfig -BlockedRecipients joe@contoso.com

Just as described for sender filtering, you can use the @{Add="<recipient>" syntax to add other recipients to the blocked recipients list. This adds john@contoso.com and blake@contoso.com, and removes joe@contoso.com at the same time.

Set-RecipientFilterConfig -BlockedRecipients @{Add="john@contoso.com","blake@contoso.com"; Remove="joe@contoso.com"}

You can use the –RecipientValidationEnabled parameter to enable recipient validation, which blocks messages to recipients in your Exchange 2013 organization who do not exist. To enable recipient validation, you can use the following command:

Set-RecipientFilterConfig -RecipientValidationEnabled $true

When you enable the recipient validation, the Recipient Filter agent does a recipient lookup. Since the Edge Transport server does not have access to the internal Active Directory, it performs this lookup in the local Active Directory Lightweight Directory Service (AD LDS), which contain a list of internal users. To prevent any information from being exposed when the Edge Transport server is compromised, the user information is stored directly in AD LDS but only a one-way hash is used with a secure hash algorithm (SHA)-256.

Sender ID Filtering

Sender ID filtering is a DNS-based technique whereby the receiving SMTP server (in our case, this is the Exchange 2013 Edge Transport server) checks for certain DNS records (called SPF records) of the sending organization.

This SPF record in DNS, which is the responsibility of the sending organization, defines which SMTP servers are actually allowed to send SMTP messages on behalf of this SMTP domain. When properly configured, the IP address of the sending SMTP record matches the SPF record in the public DNS. When this does not match, it might signal spoofing of the SMTP domain, and thus be a spamming technique.

When the Edge Transport server performs the Sender ID check, there are two potential results:

· Pass The IP address of the remote SMTP server matches the information in the SPF record and a header indicating the successful test is added to the message. This also contributes to the sender’s reputation data. (Sender reputation is explained later in this chapter.)

· Fail The IP address of the remote SMTP server does not match the information in the SPF record, or an SPF record was not found. The first can indicate a malicious message or SMTP server. It is also possible that the SPF is not configured or is misconfigured owing to some changes in the sender’s messaging infrastructure. A failed Sender ID test contributes to the sender’s reputation data, but in a negative way, of course.

The reputation data contributes to the spam confidence level (SCL) of an email message; in turn, this determines what happens to a message, as shown in Figure 6-12.

Figure 6-12. Overview of the Sender ID framework

The SPF record (a TXT record can be used as well) is registered in the public DNS of the sending organization, and this is checked by the receiving Mail server—that is, your Edge Transport server.

When you open the EMS and enter the Get-SenderIDConfig cmdlet, you’ll see the default settings for the Sender ID agent. You might want to change the SpoofedDomainAction setting; this setting determines what the agent needs to do when the Sender ID check returns an error (wrong IP on sending SMTP server and possibly a spoofed domain). There are multiple options:

· StampStatus This is the default setting. It stamps an additional header on the message and the server continues processing.

· Reject This option returns an NDR to the sender, notifying her that something is wrong.

· Delete This option deletes the message without returning an NDR to the sender. In this case when it is a legitimate sender, he never knows the message got lost.

It is also possible to bypass certain sending SMTP domains using the BypassedSenderDomains parameter. To change the Sender ID setting to Reject and add the Microsoft.com SMTP domain to the bypassed sender domains, you can use the following command:

Set-SenderIDConfig –SpoofedDomainAction Reject –BypassedSenderDomains Microsoft.com

If you want external recipients to perform a Sender ID check on the email messages sent by your organization, and thus contribute to a higher success rate for your messages, you have to implement an SPF record in your public DNS domain as well.

To create an SPF record, Microsoft has a wizard available on their website that you can find at http://bit.ly/SenderIDWizard.

This wizard consists of four steps:

1. Identify the SMTP domain—that is, exchange16.com.

2. The wizard determines that there’s no SPF record and retrieves the IP address for the domain (contoso.com) and its MX record, as shown in Figure 6-13:

Figure 6-13. The Sender ID framework wizard

3. You enter details about the sending SMTP server that the wizard then uses to create the actual SPF record. If you also have a valid PTR record for the Edge Transport server, you can check the All PTR Records Resolve to Outbound Email Servers option under “Reverse DNS Lookup.”

4. The value for the SPF record is indicated, as shown in Figure 6-14.

Figure 6-14. Entering the string in the public DNS

This value should be entered in the public DNS. Once entered, you can check its availability using the NSLookup utility, as shown in Figure 6-15.

Figure 6-15. Checking your SPF record using NSLookup utility

When you’ve configured this and send a new email message—for example, to your Hotmail mailbox—you can check the message header. You’ll find something like this:

Authentication-Results: hotmail.com; spf=pass (sender IP is 176.62.196.254) smtp.mailfrom=john@exchange16.com; dkim=none header.d=exchange16.com; x-hmca=pass header.id=john@exchange16.com

Content Filtering

Content filtering is another important feature of the Edge Transport server. Using content filtering, it’s possible to filter and delete incoming messages based on certain keywords like “online casino,” “cheap watches,” “Viagra,” or whatever other words you want to target. You can use theAdd-ContentFilterPhrase cmdlet to add specific words to the Content Filter agent, as done here and shown in Figure 6-16:

$Phrases = 'Online Casino','V I A G R A','Nigeria Bank'
$Phrases | ForEach-Object {Add-ContentFilterPhrase -Phrase $_ -Influence BadWord}

Figure 6-16. Setting specific words for content filtering

Content filtering also works with an SCL, or spam confidence level. This number identifies the likelihood an email message is spam. An SCL rating of 9 means the message is most likely spam, while an SCL rating of 1 indicates the message is likely legitimate.

Based on the SCL rating, you can block messages, reject messages (and NDR is returned to the sender), or send the messages to a quarantine mailbox. My personal preference is to block no. 9 messages, reject no. 8 messages, and forward no. 7 messages to a quarantine mailbox.

These settings are set using the Set-ContentFilterConfig cmdlet on the Edge Transport server, as shown in Figure 6-17:

Set-ContentFilterConfig -QuarantineMailbox quarantaine@exchange16.com -SCLQuarantineEnabled $true -SCLQuarantineThreshold 7
Set-ContentFilterConfig –SCLDeleteEnabled $true –SCLDeleteThreshold 9
Set-ContentFilterConfig –SCLRejectEnabled $true –SCLRejectThreshold 8

Figure 6-17. Using the spam confidence level ratings

It is also possible to bypass certain recipients from content filtering. A common candidate for this is the email address postmaster@contoso.com or abuse@contoso.com. These settings are also made using the Set-ContentFilterConfig cmdlet:

Set-ContentFilterConfig -BypassedRecipients postmaster@exchangelabs.nl, abuse@exchangelabs.nl

There are a couple of best practices you can take into consideration:

1. Use a dedicated mailbox and user account for the quarantine mailbox, and remove the quota limits from this mailbox. If there’s a quota on the mailbox and the contents exceed this limit, the mail will get lost.

2. Use a dedicated mailbox database for the quarantine mailbox.

3. Configure Outlook so that the original sender, recipient, and BCC fields are shown in the Message view.

To get an overview of all Content Filter agent settings, you can use the Get-ContentFilterConfig command, as shown in Figure 6-18:

Figure 6-18. Retrieving all content filtering settings

Sender Reputation

On the Edge Transport server, a Protocol Analysis agent is running which analyses statistics from SMTP senders. The Protocol Analysis agent is a non-configurable agent and Sender Reputation relies on persistent data that’s received from this Protocol Analysis agent.

A sender reputation level (SRL) is calculated based on the following characteristics:

· EHLO/HELO analysis of the sending SMTP server

· Reverse DNS lookup

· SCL ratings of a particular sender

· Open proxy test on the sending SMTP server

Based on the outcome of these tests, an SRL is calculated, and this SRL is an indication of the likelihood of a spammer; it’s somewhat like the SCL ratings for individual messages. An SRL rating of 0 indicates that the sending SMTP server most likely is a spam-sending server, while a rating of 9 indicates that the sending SMTP server is a normal SMTP server.

Based on the SRL rating, actions can be taken on the messages as follows:

· Rejected

· Deleted and archived

· Accepted and marked as a blocked sender

By default, all senders start with an SRL rating of 0. Only after receiving 20 messages does Sender Reputation start calculating the SRL. If a sender is registered as a blocked sender, Sender Reputation signals the Sender Filter agent to block this particular sender.

Note The SRL is kept in memory. When the Transport service is restarted on the Edge Transport servers, all SRL data is lost and Sender Reputation restarts with 0.

The SRL threshold is set to 7 by default, and this is sufficient for most organizations. However, you should monitor the effectiveness of this setting and if needed, adjust the threshold using the Set-SenderReputationConfig command. This command takes the –SrlBlockThreshold parameter to change the SRL setting.

Another interesting parameter is the –SenderBlockinPeriod, which defines the number of hours a particular sender is blocked when this sender exceeds the threshold. To change the SRL threshold to a value of 6 and set the blocking period to 36 hours, for example, you can use the following command:

Set-SenderReputationConfig -SrlBlockThreshold 6 -SenderBlockingPeriod 36

When the Transport Edge server’s anti-spam configuration is fully configured, you can continue with the other settings, such as the SSL certificates (which is optionally) and can start testing the Transport Edge server.

SSL Certificates

When the Exchange 2013 Edge Transport server is installed, a self-signed certificate is created. This certificate can be used for encryption by the opportunistic TLS feature. Using opportunistic TLS, the Edge Transport servers secure the communication when the receiving SMTP host also supports TLS.

It is not really necesssary to replace the self-signed certificate, but every now and then I see customers who want to install a third-party SSL certificate on the Edge Transport server.

Note The SSL certificate is also used for encrypting the edge synchronization. If the (self-signed) certificate is replaced by a third-party certificate, the edge subscription needs to be re-created.

The only way to create a new SSL certificate on the Edge Transport server is by using PowerShell. The first step is to generate a request file for the new SSL certificate. This request file is created using the following command:

$data = New-ExchangeCertificate -GenerateRequest -SubjectName "c=NL, o=Contoso Enterprise, cn=edge.contoso.com" -PrivateKeyExportable $true
Set-Content -Path "c:\temp\mailhost.req" -Value $Data

The request file is stored in a variable called $data, and the contents of this request are flushed to disk using the Set-Content command.

This request file can be used to request the actual SSL certificate at the certificate authority (CA) of your preference. When the certificate is issued, you receive the actual certificate from your CA. Store this file on the local disk of your Edge Transport server and execute the following command:

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path c:\temp\edge_contoso_com.cer -Encoding Byte -ReadCount 0))

This will import the certificate on your Edge Transport server.

Important to note here is that you need to execute this step on the server you used to create the certificate request file. If you do this on a different server, you’ll end up with an SSL certificate that lacks the corresponding private key, making the certificate useless.

For backup purposes, you want to export the SSL certificate to a local disk and store it in a safe location. The first step is to retrieve the thumbprint of the newly created SSL certificate using the Get-ExchangeCertificate command. You copy and paste the thumbprint to the clipboard of the computer, and execute the following command:

$file = Export-ExchangeCertificate -Thumbprint 18A5F6909F8E2668D7E884FBD31D0F87FDCB20E2 -BinaryEncoded $true -Password (Get-Credential).Password
Set-Content -Path c:\temp\edge_contoso_com.pfx -Value $file.FileData -Encoding Byte

Note The Get-Credential command shows a credential windows. Only the password entered in this dialog box is used for exporting the SSL certificate.

Test of the Edge Transport Server

The easiest way to test the installation of your Edge Transport server is to start sending email. You can also use the remote connectivity analyzer (RCA) (www.testexchangeconnectivity.com) to test the environment. To use the analyzer, you open the RCA in your browser and under Internet Email Tests, you select the Outbound SMTP Email option. Then, you enter the IP address of the outbound SMTP server, select the options you want to check, and enter your email address, as shown in Figure 6-19.

Figure 6-19. Testing the Outbound SMTP email configuration

When all is well, you will see the results in seconds; all options should show the green balls with the white checkmark, as shown in Figure 6-20.

Figure 6-20. Results that show the outbound SMTP Test was successful

For a complete and up-to-date overview of all anti-spam and anti-malware cmdlets available in Exchange 2013, visit the Microsoft documentation at http://bit.ly/AntiSpamCmdlets.

Export and Import Edge Configuration

Regular Exchange 2013 servers are domain-joined and almost all configuration is stored in Active Directory. This means that configuration information can be shared among multiple Exchange 2013 servers.

For example, information regarding transport rules on Exchange 2013 Mailbox servers is stored in Active Directory, and it is used by all Exchange 2013 Mailbox servers in the organization. The Exchange 2013 Edge Transport server, however, is not a member of the Active Directory domain and therefore configuration information cannot be shared among multiple Edge Transport servers.

Note Joining the Edge Transport servers to an Active Directory domain is supported. For example, some customers have an Active Directory domain in their perimeter network for management purposes; it aids deployment of GPOs or System Center clients to domain members. This does not mean the Edge Transport server can use this Active Directory domain, however. Even though they are domain-joined from an Exchange point of view, they are still standalone servers.

As mentioned earlier in the chapter, if you have multiple Exchange 2013 Edge Transport servers, you have to configure them individually. To release the management burden a bit, it is possible to configure one Edge Transport server and export its configuration to an XML file. This XML file can then be imported into subsequent Edge Transport servers to get an identical configuration across these Edge Transport servers. This is called a cloned configuration. Note: Cloning works only when you’re installing the Edge Transport servers. When making regular changes to the Edge Transport server during normal operation, these changes still have to be made to the individual Edge Transport servers.

Microsoft has written a script that can be used for multiple installations, located in the $ExScripts directory on the Edge Transport server and called ExportEdgeConfig.ps1. To export the Edge Transport server configuration, you open the Exchange Management Shell, navigate to the $ExScripts directory, and enter the following command:

.\ExportEdgeConfig.ps1 –CloneConfigData:"C:\Temp\EdgeClonedConfig.xml"

This command will generate a configuration file that contains the individual settings of the Edge Transport server. You copy this XML file to another Edge Transport server. To do so, on the other Edge Transport server, you open the Exchange Management Shell and enter the following command:

.\ImportEdgeConfig.ps1 –CloneConfigData:"C:\Temp\EdgeClonedConfig.xml" –IsImport $false –CloneConfigAnswer:"C:\Temp\CloneAnswerFile.xml"

This command will run a trial import of the configuration file, and any settings that are not valid for this Edge Transport server are logged into the answer file. Any errors that are logged in the answer file can be edited in the clone answer file, as shown in Figure 6-21. When no changes are needed, the answer file will be empty!

Figure 6-21. The answer files show any problems that need to be fixed when cloning

To run a full import to the subsequent Edge Transport server, you can run the same command but change the value of the –IsImport parameter to $true; for example:

.\ImportEdgeConfig.ps1 –CloneConfigData:"C:\Temp\EdgeClonedConfig.xml" –IsImport $true –CloneConfigAnswer:"C:\Temp\CloneAnswerFile.xml"

Note You cannot run the ImportEdgeConfig.ps1 script on an Edge Transport server that’s subscribed to the internal Exchange 2013 servers; therefore, you have to do this in advance of creating the edge subscription.

Load-Balancing the Edge Transport Servers

When you have multiple Exchange 2013 Edge Transport servers, most likely you want to load-balance the SMTP traffic. The good thing is that you only have to worry about load-balancing the incoming SMTP traffic; traffic between the Edge Transport servers and the internal Exchange 2013 Mailbox servers is automatically load balanced.

One Edge Transport server is bound to an Active Directory site through the edge subscription. This means that all Exchange 2013 Mailbox servers will use this Edge Transport server. Going the other way, this one Edge Transport server will use all the Exchange 2013 Mailbox servers so that SMTP traffic will be load-balanced across those Mailbox servers using a round robin mechanism.

If you have multiple Edge Transport servers in your perimeter network, then each Edge Transport server will have its own edge subscription. Of course, each Edge Transport server will automatically load-balance the inbound SMTP traffic across all available Exchange 2013 Mailbox servers. The Mailbox servers in turn automatically use all the edge subscriptions and therefore automatically load-balance their outbound SMTP traffic across the multiple Edge Transport servers.

Inbound SMTP traffic originating from external hosts (i.e., from the Internet) is a different story, though. If you have multiple Edge Transport servers, you will have multiple external IP addresses and multiple FQDNs, so you have to distribute that inbound SMTP traffic across these servers. The easiest way to do this is to use multiple MX records in the public DNS. These MX records are used by sending SMTP hosts and by using multiple MX records the inbound connections are automatically distributed.

Another option is to use a (hardware) load balancer for inbound SMTP traffic. In the load balancer, you create a virtual IP (VIP), and this IP address is used in an MX record. This way, only one MX record is used and this MX record points to the load balancer.

In the load balancer, then, you can use layer-4 (L4) load balancing to distribute the incoming requests across all available Edge Transport servers. If for some reason one server fails, the load balancer will automatically disable this server so it is no longer used by the VIP in the load balancer.

So, balancing the load to the Edge Transport servers is not a big deal and is relatively easy to implement.

Note If you have multiple Edge Transport servers, you can also use Windows Network Load Balancing (NLB) as a load-balancing solution. However, the official Microsoft recommendation is to use a (hardware) load balancer for load-balancing your Exchange traffic.

Exchange 2013 Anti-Malware

The Edge Transport server is all about anti-spam and filtering out messages received from malicious senders. it can do content inspection, but only on certain keywords as a way to filter out unsolicited email. It does not do content inspection to filter out viruses, for example. A legitimate email message coming from a reliable source could still contain a virus and be passed successfully through the Edge Transport server without any problem.

Note Message hygiene services in the cloud—for example, from Microsoft Exchange Online Protection—do scan the messages for viruses. If viruses are found, these messages can be cleaned-up or deleted. This is in sharp contrast with the Edge Transport server, which cannot offer this protection.

Besides the anti-spam features of the Edge Transport server, the Exchange 2013 Mailbox server comes with a default anti-malware engine. This anti-malware engine can perform content scanning for viruses. Th Exchange 2013 anti-malware service is a single engine (whereas the old Forefront Protection for Exchange consisted of four separate engines) and it scans all inbound and outbound messages in transit. There’s no option to scan messages that are already in the Mailbox database, however; it’s only scanning messages in transit.

Malware definition files are downloaded once per hour from the Microsoft download site. This means that the Exchange 2013 Mailbox servers need to be able to access the Internet on port 80. The URL of this download location ishttp://forefrontdl.microsoft.com/server/scanengineupdate.

It is possible to manually update these definition files. Microsoft has written a script that can be found in the $ExScripts directory, which you can use with the following command, as shown in Figure 6-22:

Set-Location $ExScripts
.\Update-MalwareFilteringServer.ps1 -Identity ams-exch02.contoso.com

Figure 6-22. Updating the anti-malware engine using the script

Another option is to manually download the definition files and store them on a file share. To update the Mailbox server with the definition files stored on a file share, you use the following command:

CD $ExScripts
.\Update-MalwareFilteringServer.ps1 -Identity ams-exch01.contoso.com -EngineUpdatePath \\ams-fs01\UpdateShare

Note In this command, CD is used to change to the proper directory, whereas in the previous command, Set-Location was used. CD is a common command for an IT Pro, as it has been used for years, but it is an alias for the Set-Location command.

When the definition files are updated, events are logged in the event log from source FIPFS. EventID 6033 shows detailed information when the update is downloaded and what version it is, as follows:

Log Name: Application
Source: Microsoft-Filtering-FIPFS
Date: 9/16/2014 4:34:11 PM
Event ID: 6033
Task Category: None
Level: Information
Keywords:
User: NETWORK SERVICE
Computer: AMS-EXCH02.contoso.com
Description:
MS Filtering Engine Update process performed a successful scan engine update.
Scan Engine: Microsoft
Update Path: http://forefrontdl.microsoft.com/server/scanengineupdate
Last Update time:2014-09-16T14:34:11.000Z
Engine Version:1.1.11005.0
Signature Version: 1.185.109.0

To disable malware scanning on an Exchange 2013 Mailbox server, you can use the PowerShell script that’s located in the $ExScripts Directory, with this command:

CD $ExScripts
.\ Disable-Antimalwarescanning.ps1

If you want to temporarily stop the malware scanning, you can bypass it instead of disabling it. This can be achieved using the Set-MalwareFilteringServer command:

Set-MalwareFilteringServer –Identity ams-exch01 –BypassFiltering $true

To stop bypassing the malware filter, you can use the same command with a $false value.

The malware filtering in Exchange 2013 is using default anti-malware policies. The default anti-malware policies can be edited, but not deleted. It is also possible to create custom anti-malware policies that are targeted toward groups of mailboxes.

You can view the default malware filtering policy using the Get-MalwareFilterPolicy command, as shown in Figure 6-23.

Figure 6-23. The default malware filter policy in Exchange 2013

You can also create custom alert messages for both internal and external alerts, as well as what should happen when an infected message is found. New malware filter policies can be created using the New-MalwareFilterPolicy command. The following example creates a new malware filter policy named “Contoso Malware Filter Policy” that enables notifications to the administrator mailbox. Messages that contain malware are blocked, and the sender of the message is not notified.

New-MalwareFilterPolicy -Name "Contoso Malware Filter Policy" -EnableInternalSenderAdminNotifications $true -InternalSenderAdminAddress administrator@contoso.com

If you want to use a custom notification, you have to use the –CustomNotifications parameter and set it to $true. At the same time, you have to configure the following options:

· CustomFromAddress

· CustomFromName

· CustomExternalSubject

· CustomExternalBody

· CustomInternalSubject

· CustomInternalBody

A malware filter rule contains one or more malware filter policies; a malware filter rule can be assigned to a mailbox. For example, to create a new malware filter rule that contains the Contoso malware filter policy created in the previous example, you can use the New-MalwareFilterRule command as follows:

New-MalwareFilterRule -Name "Contoso Recipients Rule" -MalwareFilterPolicy "Contoso Malware Filter Policy" -RecipientDomainIs contoso.com

You can use the –SentTo parameter to select the recipients to whom the malware filter rule is applied. For a broader scope, you can use the –SentToMemberOf parameter to define the members of a distribution group where the malware filter rule will be applied.

You can test the anti-malware settings using the EICAR test virus. This is a small text file that contains a test virus pattern, and is used by anti-virus and anti-malware vendors for testing purposes. To do so, you create a new text file and copy this exact line into the text file:

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

Make sure that this is the only string in the file. When done, you will have a 68-byte file that can be stored as EICAR.TXT. Be careful with local virus scanners on your workstation, as these scanners will pick up the EICAR pattern as well. Send a new message to yourself, attach the EICAR.TXT file, and see what happens.

Summary

Exchange Server 2013 SP1 has a new server role called the Edge Transport server. This server is typically located in the perimeter network and is used for anti-spam purposes. It can perform the most standard types of anti-spam actions, like connection filtering, sender filtering, recipient filtering, and content filtering.

The only management interface of the Exchange 2013 Edge Transport server is the Exchange Management Shell. The Edge Transport server is not a member of the internal Active Directory domain, and as such it cannot use this method to share configuration information as can regular Exchange 2013 servers. If you have multiple Edge Transport servers, you can configure the first Edge Transport server and clone the configuration to the remaining Edge Transport servers.

The Exchange 2013 Mailbox server comes with a built-in anti-malware solution. It’s not as efficient as the former Forefront Protection for Exchange, but it can perform the most basic anti-malware functions. This anti-malware solution only scans messages in transit, however; it does not scan messages that are stored in the mailbox database.

As you have seen in this chapter configuration of the Edge Transport server is quite some work and is prone to error. A viable alternative to using the Edge Transport server for hygiene purposes is to employ an online anti-spam (and anti-virus) solution like Microsoft Exchange Online Protection. Of course, this comes with a monthly fee per mailbox, but it saves an IT administrator a lot of hassle (plus servers, licenses, and maintenance!).