Monday, 1 February 2016

Receive connector logging | Exchange 2013, 2016

Introduction


In this post, we’ll do a walk through on how to enable receive connector logging, where to find the logs or move the receive connector log path.
  • Enable Receive Connector Logging
  • Receive Connector Log Path
  • Change the Receive Connector Log Path and other settings
  • Disable Receive Connector Logging

Enable Receive Connector Logging


To enable receive connector logging for a single receive connector, e.g. Relay 1 on server LITEX01:

Set-ReceiveConnector “LITEX01\Relay 1” -ProtocolLogging Verbose


image_thumb


To enable receive connector logging for all receive connector on a particular server, e.g. server LITEX01:

Get-ReceiveConnector -Server LITEX01 | Set-ReceiveConnector -ProtocolLogging Verbose


image_thumb1


Receive Connector Log Path


If you read the background infromation on receive connectors here, you’ll see that there are two services involved in email transport and each has its own receive connectors:
  • Front End Transport Service
  • Transport Service

They also each have their own receive connector protocol log path.

Front End Transport Service Receive Connector Log Path


The default for the Front End Transport Service is: "C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive"

You can check the Front End Transport Service receive connector log path by running the below command which outputs the path for the server LITEX01:

Get-FrontendTransportService -Identity LITEX01 | fl ReceiveProtocolLogPath

image


Transport Service Receive Connector Log Path


The Transport Service receive connector log path is: "C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive"

You can check the log path by running this command for server LITEX01:

Get-TransportService -Identity LITEX01 | fl ReceiveProtocolLogPath

image

Change the Receive Connector Log Path and other settings


In this section, we’ll look at how to change the log path and other settings for the Front End Transport Service and the Transport Service.

Front End Transport Service


We can confirm the current settings by running the command below:

Get-FrontEndTransportService -Identity LITEX01 | fl Receive*

image

Here we can see that logs are stored for a maximum of 30 days, each log file can grow to 10MB and the maximum log directory size is 250MB. The log path is also listed.

There may be some requirements to store receive connector logs for more than 30 days. In this case, you can increase the maximum directory size to 500MB and the maximum age to 60 days using this command:

Set-FrontEndTransportService -Identity LITEX01 -ReceiveProtocolLogMaxAge 60.00:00:00 -ReceiveProtocolLogMaxDirectorySize 500MB

image

You can also change the log path. For example, this command changes the log path to E:\Logs\Frontend:

Set-FrontEndTransportService -Identity LITEX01 -ReceiveProtocolLogPath E:\Logs\Frontend

image

New logs are now written to the new path without requiring a restart of any services:

image

Transport Service


We can confirm the current settings by running the command below:

Get-TransportService -Identity LITEX01 | fl Receive*

image

Here we can see that logs are stored for a maximum of 30 days, each log file can grow to 10MB and the maximum log directory size is 250MB. The log path is also listed.

There may be some requirements to store receive connector logs for more than 30 days. In this case, you can increase the maximum directory size to 500MB and the maximum age to 60 days using this command:

Set-TransportService -Identity LITEX01 -ReceiveProtocolLogMaxAge 60.00:00:00 -ReceiveProtocolLogMaxDirectorySize 500MB

image

You can also change the log path. For example, this command changes the log path to E:\Logs\Hub:

Set-TransportService -Identity LITEX01 -ReceiveProtocolLogPath E:\Logs\Hub

image

New logs are now written to the new path without requiring a restart of any services:

image

Disable Receive Connector Logging


When you’re done with troubleshooting, you can disable receive connector logging.
To disable receive connector logging for a single receive connector, e.g. Relay 1 on server LITEX01:

Set-ReceiveConnector “LITEX01\Relay 1” -ProtocolLogging None

image

To disable receive connector logging for all receive connector on a particular server, e.g. server LITEX01:

Get-ReceiveConnector -Server LITEX01 | Set-ReceiveConnector -ProtocolLogging None

image


Conclusion


In this post, I’ve demonstrated how to enable receive connector logging, where to find the logs and how to change logging settings such as the log path and the amount of logs that are stored.

Thursday, 28 January 2016

OWA blank page | Exchange 2013, 2016

Symptoms


You try to log into Outlook Web App (or now called Outlook on the Web) using Exchange 2013 or 2016. You’re presented with a login screen then after you sign in, you are presented with a blank screen. This often happens after a restart or an upgrade. See below:

image

After logging in:

image


Cause


The cause of this is that the Exchange Back End site in IIS on your MBX server is no longer bound to a certificate (SSL certificate “Not Selected”). See below:

image

Resolution


To resolve this issue, open up IIS Manager on your Exchange server:

image

Then right click on Exchange Back End and click on Edit Bindings. You’ll be presented with a list of site bindings.

image

Double click on the https entry in the list. You should now see the below window:

image

In the SSL certificate drop down, select the Microsft Exchange certificate:

image

Click OK then click Close.

You should now be able to log into OWA:

image

Repeat for your other servers if needed.

Wednesday, 27 January 2016

Bindings and RemoteIPRanges parameters conflict | Exchange 2013, 2016

Symptoms


When creating a new receive connector on Exchange 2013 or 2016, you may run into this error:

The values that you specified for the Bindings and RemoteIPRanges parameters conflict with the settings on Receive connector "LITEX01\Default Frontend LITEX01". Receive connectors assigned to different Transport roles on a single server must listen on unique local IP address & port bindings.


image


Cause


When creating a receive connector, you choose one of two roles; either a Hub Transport connector or a Frontend Transport connector, as you can see in the screen shot below:


image


The problem is that the Frontend Transport Service is using port 25 for the Default Frontend Proxy <ServerName> receive connector and if you follow the defaults in the wizard, you’ll end up tying to create a new receive connector using the Transport Service which also listens on port 25. These two services run under different windows processes and they therefore cannot listen on the same port.

Resolution


If you want to create a new receive connector that listen on port 25, you can do this but you have to create them it using the Frontend Transport role if you have either an Exchange 2016 server or an Exchange 2013 server with both the CAS and MBX roles installed on the same server.

Tuesday, 26 January 2016

Receive connector selection | Exchange 2013, 2016

Introduction


In this post, we’ll look at how Exchange selects a receive connector for a particular client connection. We’ll break down this post into the below sections:
  • Default receive connectors
  • Receive connector selection
  • Example scenarios

For more information on how to check which receive connector is in use by Exchange for a particular connection, see here.

Default receive connectors


When Exchange is installed, there are a number of receive connectors that are set up by default. In Exchange 2013, there are two roles (CAS and MBX) but in Exchange 2016 the CAS and MBX roles cannot be installed separately and are merged into one role called the MBX role.

Exchange 2013 has a Front End Transport Service as part of the CAS role and a Transport Service as part of the MBX role. Multi-role Exchange 2013 servers have both the services.

Exchange 2016 is similar to a multi-role Exchange 2013 server in that it has both transport services.


Front End Transport Service Receive Connectors


The Front End Transport Service has three receive connectors. These only proxy connections to the Transport Service (running on Exchange 2013 or 2016 MBX servers):
  • Client Frontend <ServerName>: This receive connector listens on port 587 and is used for authenticated SMTP connections from clients such as POP3 clients. Generally little configuration is done on this receive connector.
  • Default Frontend <ServerName>: This receive connector accepts anonymous connections from external SMTP servers on port 25 and is (or should be) the point at which external messages enter the Exchange organization. (No, you should not be using the Transport Service on an Exchange 2013 MBX server to receive external email. It should be proxied through the Front End Transport Service on the CAS server).
  • Outbound Proxy Frontend <ServerName>: Yes, outbound. This receive connector is not involved in inbound email delivery to the Exchange organization. It’s only used if you have configured your Send Connector to proxy through your front end CAS server/service and is use for outbound email from your Exchange organization. You enable this when creating or configuring your send connector by setting the FrontendProxyEnabled parameter to enabled on the Set-SendConnector or New-SendConnector cmdlets. This receive connector listens on port 717 for outbound email from the Transport Service in the MBX role.

Generally it’s best to leave these receive connectors as they are and create new receive connectors for specific scenarios such as if you need to configure anonymous relay for a list of client IPs. See here if you need more information on how to configure this.

These Front End Transport Service receive connectors are bound to all local and remote IPv4 and IPv6 addresses by default which means that Exchange will listen for connections from any client IP and to any IP configured on the Exchange server.


Transport Service Receive Connectors


The Transport Service (part of the MBX role) has two receive connectors. These are not on standard ports and they don't need to be because they don’t receive connections from clients.
  • Client Proxy <ServerName>: This receive connector listens on port 465 and accepts authenticated connections that are proxied from the Client Frontend <ServerName> receive connector which is part of the Front End Transport Service.
  • Default <ServerName>: This receive connector listens on one of two ports. In Exchange 2013 it listens on port 25 if the MBX role has been installed without the CAS role on the same server and it listens on port 2525 if the CAS and MBX roles are installed on the same server. As Exchange 2016 behaves much like a multi-role Exchange 2013 server, this receive connector listens on port 2525. It is used to accept authenticated connections from the Front End Transport Service, the Transport Service on other MBX servers or connections from Edge Transport Servers. Connections are authenticated using the Exchange server’s self-signed certificate and this is why you shouldn’t delete it. See more here.

As with the Front End Transport Service receive connectors, the Transport Service receive connectors are bound to all local and remote IPv4 and IPv6 addresses which means that Exchange will listen for connections from any IP and to any IP configured on the Exchange server.

Now that we have a better understanding about the default receive connector configuration, we can continue on to receive connector selection.


Receive Connector Selection


As we know, each receive connector includes a number of properties but for the purpose of receive connector selection, we only need to focus on these three properties:
  • Port Binding (the TCP on the  Exchange server that the receive connector listens on)
  • IP Binding (the Exchange server IP that the receive connector listens on)
  • Remote IP ranges (the remote IP range that the receive connector accepts connections from)

The Port and IP binding make up the receive connector binding. E.g. a binding of 0.0.0.0:25 means that the receive connector listens on all IPs for connections on port 25.

You cannot have two receive connectors which have all three properties set to be the same – i.e. you cannot have two receive connectors with the same port binding, IP binding and remote IP ranges configured. If you try to do this, you’ll get the error below:

The values that you specified for the Bindings and RemoteIPRanges parameters conflict with the settings on Receive connector "LITEX01\Relay 1". A Receive connector must have a unique combination of a local IP address & port bindings and remote IP address ranges. Change at least one of these values.

image

There needs to be a difference so that Exchange can select the correct receive connector for the incoming client connection.

While we're here, let’s also define what an SMTP client is. SMTP clients include:
  • Other servers relaying through Exchange using authenticated or anonymous relay
  • Other Exchange organizations sending email through to your organization
  • Incoming external email directly from the internet or via a smart host (mail gateway or mail filter)
  • End user clients which are using SMTP to send email using a POP3 client

Now that we have enough background information, we can start to look at the receive connector selection process. This involves the four steps below:
  • Step 1: Get all receive connectors where the network adapter bindings include the port on the Exchange server that the client is connecting to
  • Step 2: Get all receive connectors identified in step 1 where the network adapter bindings include the IP on the Exchange server that the client is connecting to
  • Step 3: If step 2 identifies more than one receive connector, select the receive connector with the most specific remote IP range which includes the client IP
  • Step 4: If step 3 identifies more than one receive connector, select the receive connector with the most specific IP binding


Example scenarios


In order to explain the selection process, I’ve made up some scenarios and I’ll demonstrate how to figure out the receive connector that is used. In each scenario, we have all the default receive connectors as per the default configuration above but we also have a three custom receive connectors with the below settings:

Custom receive connector 1:
  • Name: Relay 1
  • Port Binding: 25
  • IP Binding: All available IPv4 and IPv6 addresses
  • Remote IP Ranges: 10.2.0.10 - 10.2.0.11 (IP range)

Custom receive connector 2:
  • Name: Relay 2
  • Port Binding: 25
  • IP Binding: All available IPv4 and IPv6 addresses
  • Remote IP Ranges: 10.2.0.10 and 10.2.0.11 (individual IPs)

Custom receive connector 3:
  • Name: Relay 3
  • Port Binding: 25
  • IP Binding: 10.2.0.21
  • Remote IP Ranges: 10.2.0.10 and 10.2.0.11 (individual IPs)

In the below scenarios, our server is either an Exchange 2013 CAS server, an Exchange 2013 multi-role server or an Exchange 2016 server as these all behave the same way in these scenarios. In each scenario, our Exchange server has an IP of 10.2.0.21 and hostname LITEX01.


Scenario 1: A client with IP 105.10.10.10 connects to the Exchange server on port 587 and IP 10.2.0.21 (through the firewall using a NAT rule):

Step 1: Get all receive connectors where the network adapter bindings include the port on the Exchange server that the client is connecting to

When we look through all the receive connectors on the server, we can see that there is only one receive connector bound to port 587: Client Frontend LITEX01

Step 2: Get all receive connectors indentified in step 1 where the network adapter bindings include the IP on the Exchange server that the client is connecting to

Our client is connecting to 10.2.0.21 and the Client Frontend LITEX01 receive connector is bound to all IPv4 and IPv6 IPs so this matches.

Step 3: If step 2 identifies more than one receive connector, select the receive connector with the most specific remote IP range which includes the client IP

We only identified one receive connector in step 2 so we skip this step.

Step 4: If step 3 identifies more than one receive connector, select the receive connector with the most specific IP binding

We only identified one receive connector in step 3 so we skip this step.

Result: The receive connector that is selected is the Client Frontend LITEX01 receive connector.


Scenario 2: A client with IP 105.10.10.10 connects to the Exchange server on port 25 and IP 10.2.0.21 (through the firewall using a NAT rule):

Step 1: Get all receive connectors where the network adapter bindings include the port on the Exchange server that the client is connecting to

When we look through all the receive connectors on the server, we can see that there are four receive connectors bound to port 25:
  • Default Frontend LITEX01
  • Relay 1
  • Relay 2
  • Relay 3

Step 2: Get all receive connectors indentified in step 1 where the network adapter bindings include the IP on the Exchange server that the client is connecting to

The client is connecting to the server on IP 10.2.0.21. All of the receive connectors identified in step 1 are bound to either all IPv4 and IPv6 addresses or to just 10.2.0.21 so they all include the IP the client is connecting to:
  • Default Frontend LITEX01
  • Relay 1
  • Relay 2
  • Relay 3

Step 3: If step 2 identifies more than one receive connector, select the receive connector with the most specific remote IP range which includes the client IP

Relay 1 has a remote IP range which only includes 10.2.0.10 - 10.2.0.11  so cannot be used by the client. Relay 2 has a remote IP range which only includes 10.2.0.10 and 10.2.0.11 so also cannot be used by the client. Relay 3 also has a remote IP range which includes 10.2.0.10 and 10.2.0.11 so also cannot be used by the client. This leaves Default Frontend LITEX01 which has a remote IP range which includes all IPv4 and IPv6 addresses so this is the selected receive connector.

Step 4: If step 3 identifies more than one receive connector, select the receive connector with the most specific IP binding

We only identified one receive connector in step 3 so we skip this step.

Result: The receive connector that is selected is the Default Frontend LITEX01 receive connector.


Scenario 3: A client with IP 10.2.0.10 connects to the Exchange server on port 25 and IP 10.2.0.21

Step 1: Get all receive connectors where the network adapter bindings include the port on the Exchange server that the client is connecting to

When we look through all the receive connectors on the server, we can see that there are four receive connectors bound to port 25:
  • Default Frontend LITEX01
  • Relay 1
  • Relay 2
  • Relay 3

Step 2: Get all receive connectors indentified in step 1 where the network adapter bindings include the IP on the Exchange server that the client is connecting to

The client is connecting to the server on IP 10.2.0.21. All of the receive connectors identified in step 1 are bound to either all IPv4 and IPv6 addresses or to just 10.2.0.21 so they all include the IP the client is connecting to:
  • Default Frontend LITEX01
  • Relay 1
  • Relay 2
  • Relay 3

Step 3: If step 2 identifies more than one receive connector, select the receive connector with the most specific remote IP range which includes the client IP

Relay 1 has a remote IP range set to 10.2.0.10 - 10.2.0.11 so this includes the client IP. Relay 2 has a remote IP range which includes 10.2.0.10 and 10.2.0.11. Relay 3 has a remote IP range which also includes 10.2.0.10 and 10.2.0.11. Default Frontend LITEX01 has a remote IP range which includes all IPv4 and IPv6 addresses so can also be used by the client.

We need to select the most specific IP range that includes the client IP. In this case we have a tie between Relay 2 and Relay 3 which both only have two IPs in the remote IP range whereas Default Frontend LITEX01 includes all IPv4 and IPv6 addresses. Now, your question is “why is Relay 1 not included in this tie? Surely it also includes the same two remote IPs as Relay 2 and Relay 3?” The answer is that you need to look at the range that the IP is in. For receive connector Relay 1 the IP 10.2.0.10 is in a range of two IPs (10.2.0.10 - 10.2.0.11) whereas for receive connectors Relay 2 and Relay 3, the IP 10.2.0.10 is in a range of just one IP (i.e. the two IPs are added as two IP ranges of one IP each). This makes Relay 2 and Relay 3 more specific than Relay 1. So, now we are down to these two receive connectors:
  • Relay 2
  • Relay 3

Step 4: If step 3 identifies more than one receive connector, select the receive connector with the most specific IP binding

Now, which receive connector is actually being used? Well, this is where we look at the IP binding. Relay 2 is bound to all IPv4 and IPv6 addresses whereas Relay 3 is bound to only 10.2.0.21 making it more specific.

Result: The receive connector that is selected is the Relay 3 receive connector.


Conclusion


In this post, we’ve looked at the default receive connectors that are configured when you first install your Exchange 2013 or 2016 server. We’ve also discussed how a receive connector is selected according to client IP and receive connector IP and port bindings.

Monday, 25 January 2016

Which receive connector? | Exchange 2013, 2016

Introduction


In this post, I’ll show you how to work out which receive connector is being used for a particular client SMTP connection in Exchange 2013 and 2016.

Which receive connector is a client SMTP connection using?


To figure this out, we will use receive connector logging. To view the receive connector logs, we first need to enable verbose logging as it's not enabled by default. This is enabled per receive connector so enable logging on each receive connector that you think may be in use.

Enable receive connector logging


To enable receive connector logging for a single receive connector, e.g. Relay 1 on server LITEX01:

Set-ReceiveConnector “LITEX01\Relay 1” -ProtocolLogging Verbose

image

To enable receive connector logging for all receive connector on a particular server, e.g. server LITEX01:

Get-ReceiveConnector -Server LITEX01 | Set-ReceiveConnector -ProtocolLogging Verbose

image

Once enabled, you will start to see log files created in this path for the Front End Transport Service (runs on Exchange 2013 CAS and multi-role servers and also on Exchange 2016 servers): 

"C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive"

And this path for the Transport Service logs (runs on Exchange 2013 MBX and multi-role servers and also on Exchange 2016 servers):

"C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive"

Below is an example of an email sent from mark@domain.com to administrator@litwareinc.com:

2016-01-24T23:36:56.545Z,LITEX01\Relay 3,08D311385B77F991,0,10.2.0.21:25,10.2.0.10:64590,+,,
2016-01-24T23:36:56.545Z,LITEX01\Relay 3,08D311385B77F991,1,10.2.0.21:25,10.2.0.10:64590,>,"220 litex01.litwareinc.com Microsoft ESMTP MAIL Service ready at Sun, 24 Jan 2016 23:36:55 +0000",
2016-01-24T23:36:56.545Z,LITEX01\Relay 3,08D311385B77F991,2,10.2.0.21:25,10.2.0.10:64590,<,EHLO litdc01,
2016-01-24T23:36:56.545Z,LITEX01\Relay 3,08D311385B77F991,3,10.2.0.21:25,10.2.0.10:64590,>,250  litex01.litwareinc.com Hello [10.2.0.10] SIZE 36700160 PIPELINING DSN ENHANCEDSTATUSCODES STARTTLS 8BITMIME BINARYMIME CHUNKING,
2016-01-24T23:36:56.545Z,LITEX01\Relay 3,08D311385B77F991,4,10.2.0.21:25,10.2.0.10:64590,<,MAIL FROM:<mark@domain.com>,
2016-01-24T23:36:56.545Z,LITEX01\Relay 3,08D311385B77F991,5,10.2.0.21:25,10.2.0.10:64590,*,08D311385B77F991;2016-01-24T23:36:56.545Z;1,receiving message
2016-01-24T23:36:56.545Z,LITEX01\Relay 3,08D311385B77F991,6,10.2.0.21:25,10.2.0.10:64590,>,250 2.1.0 Sender OK,
2016-01-24T23:36:56.545Z,LITEX01\Relay 3,08D311385B77F991,7,10.2.0.21:25,10.2.0.10:64590,<,RCPT TO:<administrator@litwareinc.com>,
2016-01-24T23:36:56.545Z,LITEX01\Relay 3,08D311385B77F991,8,10.2.0.21:25,10.2.0.10:64590,>,250 2.1.5 Recipient OK,
2016-01-24T23:36:56.545Z,LITEX01\Relay 3,08D311385B77F991,9,10.2.0.21:25,10.2.0.10:64590,<,DATA,
2016-01-24T23:36:56.545Z,LITEX01\Relay 3,08D311385B77F991,10,10.2.0.21:25,10.2.0.10:64590,>,354 Start mail input; end with <CRLF>.<CRLF>,
2016-01-24T23:36:56.560Z,LITEX01\Relay 3,08D311385B77F991,11,10.2.0.21:25,10.2.0.10:64590,*,,Proxy destination(s) obtained from OnProxyInboundMessage event


You can see from the above output that the receive connector in use is called LITEX01\Relay 3 (well, you should be able to because it’s highlighted enough times!).

Conclusion


In this post, I’ve demonstrated how you can work out which receive connector is in use by enabling receive connector logging.

Thursday, 21 January 2016

Require SPF Pass for selected senders | Exchange 2013 - 2016

Introduction


In this post, I’ll show you how to partially enable SPF checks by requiring that the SenderID/SPF check is a pass for incoming email from a specified list of domains in Exchange 2013 and Exchange 2016. This is particularly useful if you receive legitimate email from financial institutes or other organizations which may request sensitive information and where these domains are often spoofed but you don't yet want to reject all email that fails the SPF check.

SPF is not a new way of detecting spoofed email but SenderID/SPF checks on incoming mail has not yet been enabled by many of the mail servers across the internet. This may be due to a lack of understanding or confidence in the system. If this includes you then have a read of these posts to get a better understanding:


Ensure that you have completed these steps from How to prevent spoofed email part 1 before continuing:

  • Configure the InternalSMTPServers property on your transport servers
  • Install the Anti-Spam agents on Exchange

How to require an SPF pass for email from particular domains


To do this, we will create a new transport rule to look at the Received-SPF header on incoming email from outiside the organisation that is from our list of domains for which we only want to receive email if they pass the SPF check.

The email headers for an email that passes the SPF check looks like this:

Received-SPF: Pass (svr01.domain.co.uk: domain of reply@sender.com designates 108.14.3.148 as permitted sender)

We will configure our rule to look for the text pattern “Pass ” in the Received-SPF header. Note the additional space on the end to prevent a false positive for any email addresses that include the string “pass”.

First, log into the Exchange Admin Center using an account which is a member of the Organization Management group then click on mail flow in the left pane:

image

Next, click on the + icon, select create a new rule and provide a name for your new rule like “Require SPF Pass”:

image

Once done, click on More options… to make the additional conditions and options visible. We will apply the rule if the sender’s domain is contoso.com or tailspintoys.com. Click on the Apply this rule if… drop down and select the senders’s domain is… then add your domains in the list:

image

Click OK when done. 

Our next step is to apply these rules to only email from outside the organization. To do this, click add condition and then select the sender is external/internal… Select Outside the organization:

image

Click OK. In this next part we’ll configure an action for email that is not an SPF pass. You can select one of many actions:

  • Redirect the email to another mailbox (e.g. a spam mailbox)
  • Forward the message for approval (by an administrator or other)
  • BCC the message to another address
  • Prepend the subject of the message with a string (to notify the user that this email is not from a trusted source)
  • Block the message (with or without an NDR)

In this example, we’ll block the message without sending an NDR to the sender. If you go with this approach, ensure that this sender is always sending email from IPs on their SPF record otherwise you will start to reject legitimate email. If they are not then it’s best to go with one of the less drastic approaches above.

Under the do the following heading, select Block the message…delete the message without notifying anyone as below:

image

Now this blocks all messages from tailspintoys.com and contoso.com originating from outside the organization. We now want to make an exception so that we allow only those emails that have a Pass in the Received-SPF header field. To do this, click on add exception then select A message header…matches these text patterns

image

Click on Enter text… and enter Received-SPF to provide the header name:

image

Click OK then click on Enter text patterns…. Set the text pattern to “Pass ” (yes, there is a space after the word Pass) then click the + icon:

image

Click OK then click on Save.

Conclusion


In this post, I’ve demonstrated how to set up a new transport rule in Exchange to ensure email from particular domains are only delivered if they pass the SPF checks.

Wednesday, 20 January 2016

Block spoofed email - Part 2 | Exchange 2010 - 2016

Introduction


In part 1, I demonstrated how to set up Exchange to block spoofed email where the sending domain has a valid SPF record using the -all mechanism (HardFail).

So, what happens when you want to block or identify SoftFails also? I’ll show you how to do this in these instructions.

First, make sure that you have gone through at least these steps from part 1 before continuing:
  • Create an SPF record for your domain configured with a hard fail
  • Configure the InternalSMTPServers property on your transport servers
  • Install the Anti-Spam agents on Exchange
Now that you've done that, we can continue. We’ll break these instructions down into three steps:
  • SPF results in message headers (how to identify SPF SoftFails)
  • How to block or mark an SPF soft fail email in Exchange 2010
  • How to block or mark an SPF soft fail email in Exchange 2013 or 2016

SPF results in message headers (how to identify SPF SoftFails)


Here’s an example of a junk email that made it through the SenderID check that we configured in part 1 because it was not actually an SPF HardFail:

Received: from direct-soho-210-158-67.cbn.net.id (210.210.158.67) by
svr01.domain.co.uk (192.168.0.8) with Microsoft SMTP Server id 14.3.224.2;
Wed, 13 Jan 2016 11:36:02 +0000
From: Avril Sparrowhawk <Avril.Sparrowhawk@lescaves.co.uk>
To: "mark@domain.co.uk" <mark@domain.co.uk>
Subject: CWIH8974 PAYMENT RECEIVED
Date: Wed, 13 Jan 2016 18:36:18 +0700
Message-ID: <57B2F503302A134BB06611F503C0E502143C82B4@domain.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.0.0.89]
Content-Type: multipart/mixed;
    boundary="_006_57B2F503302A134BB06611F503C0E502143C82B4LCDPMAIL2lescav_"

X-Original-To: accounts@trinityrestaurant.co.uk
X-Virus-Scanned: ClamAV using ClamSMTP
Return-Path: Avril.Sparrowhawk@lescaves.co.uk
MIME-Version: 1.0
X-MS-Exchange-Organization-AuthSource: svr01.domain.co.uk
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-PRD: lescaves.co.uk
X-MS-Exchange-Organization-SenderIdResult: SoftFail
Received-SPF: SoftFail (svr01.domain.co.uk: domain of transitioning
Avril.Sparrowhawk@lescaves.co.uk discourages use of 210.210.158.67 as
permitted sender
)


As you can see from the message headers, this is a SoftFail. The reason we can't use the Exchange SenderID Transport Agent to block this as we did in part 1 is because it doesn't have an option to reject an SPF SoftFail like it can do for a HardFail.

So, we can’t use the SenderID agent but we can create an Exchange Transport Rule to review the message headers for us and look for SoftFail in the Received-SPF header. I’ll demonstrate how to create this rule in Exchange 2010 - 2016 below.

How to block or mark an SPF SoftFail email in Exchange 2010:


Open up the Exchange Management Console using an account that is a member of the Organization Management group and expand down to Organization Configuration > Hub Transport:

image

In the right hand pane, click on "New Transport Rule":

image

Give your new transport rule a name such as "SPF SoftFail" and click Next:

image

On the next screen, select “when the message header contains specific words”:

image

Click on “message header” in the bottom pane, enter “Received-SPF” and click OK:

image

Now, click on “specific words” in the bottom pane, enter “SoftFail”, click Add then click OK:

image

Also tick the option “from users that are inside or outside the organization” and select “Outside the organization”. You should now see that this transport rule applies to messages when the Received-SPF header contains SoftFail and the message is from a sender outside the organization to prevent actions being taken for internal email relayed from servers that don’t have an IP included on the SPF record for your domain:

image

Go ahead and click Next. You’re now prompted with a list of actions to choose to apply to the email. You can apply any action you like such as:
  • prepend message subject with string (to notify the recipient that this email could be potentially harmful)
  • forward the message to addresses for moderation (e.g. to forward to an Administrator to check the domain is valid and configure an exception for the domain if needed then approve the email for delivery to the end user)
  • redirect the message to addresses (e.g. forward to a spam mailbox)
  • send rejection message to sender with enhanced status code (reject the message with custom error)
I'll demonstrate how to prepend a string to the subject line and also how to reject the email. 

To prepend the message subject with the string “POTENTIAL SPAM (SPF SoftFail)” to notify users that they should be vigilant when opening this email, tick "prepend message subject with string" and enter your custom string in the bottom pane as below:

image

If you want to block the email the instead of prepend a string to the subject line then in the actions window, instead of selecting “prepend message subject with”, select “send rejection message to sender with enhanced status code”:

image

Create a rejection message such as “SPF SoftFail” and select an enhanced status code such as "5.7.1":

image

Once done, complete the wizard, selecting the defaults.

If you’ve chosen to prepend a string to the subject line then SPF SoftFail emails will be marked like this email:

image

How to block or mark an SPF SoftFail email in Exchange 2013 or 2016:


Log into the Exchange Admin Center using an admin account that is a member of the Organization Management group then click on mail flow then rules:

image

Click on the + icon then click on “Create a new rule” and provide a name for your new rule such as SPF SoftFail:

image

Click on “more options…” to make the message header options visible
Once done, click on the “Apply this rule if….” drop down, select “A message header…” then select “matches these text patterns” as below:

image

Click on “Enter text…” and enter Received-SPF then click OK:

image

Then click on “Enter text patterns…” and enter SoftFail then the + icon then click OK:

image

We need to ensure that this rule only applies to external senders so we need to add a conditiona that the senders are outside the organization. This prevents problems with printers or other servers that are relaying through Exchange without having their IPs on the SPF record (if you’re using an SPF SoftFail on your record). To do this, click on “add condition” and select “The sender…is external/internal”:

image

Select “Outside the organization” then click OK:

image

We can now select an action for the message. As with the Exchange 2010 instructions, I’ll demonstrate how to prepend a string to the message subject and also how to reject the email:

To prepend a string to the message subject, select “prepend the subject of the message with..” (funnily enough!) and enter the text you want to add to the beginning of the subject line such as “POTENTIAL SPAM (SPF SoftFail)” then click OK then Save:

image

If you want to rather reject this email then instead of selecting the action “prepend the subject of the message with…”, select “Block the message…reject the message with the explanation” and enter an explanation such as SPF SoftFail:

image

Once done, click Save. Your rule is now enabled.

Conclusion


In part 2, I’ve demonstrated how to block or notify the end user of emails that fail the SPF checks but cause a SoftFail rather than a HardFail.
In an upcoming post, I’ll show you how to only accept emails from particular domains if they pass the SPF check.