How to block inbound and outbound external mail flow for internal users.

Introduction

For the sake of this article, I created a fictitious organization which I will name MSExchange.org, and a user-name which I will name Anderson.Patricio. Through this article we are going to manage the users ability to send or receive internet messages. These are some of the topics that we are going to cover in this article:

• Block any incoming mail to that user
• Block that user from sending outbound messages
• Allow that user to send messages to a specific user outside
• Allow the user to receive external messages from a specific domain
• Allow that user to send messages to a specific domain only

The main idea here is to provide some possible ways to accomplish this kind of task, for your personal environment or for the entire network. You can also combine more than one of the possible scenarios above to accomplish your requirements.

Managing the inbound traffic to a specific user

There are several ways to manage the incoming traffic to a specific user. We can create Transport Rules, configure Recipient Filtering, change at mailbox level and so on.
The first option is to use Transport Rules. This feature allows us to create a rule to return a NDR to the sender, for example, saying that this specific user does not have permission to receive Internet mail. This can be done as follows:

1. Open Exchange Management Console
2. Expand Organization Configuration
3. Click on Hub Transport
4. Click on Transport rules tab
5. On Toolbox Actions, click on New Transport Rule…
6. In the Introduction page, define a name for the rule and click Next
7. In the Conditions page. Select the from users inside or outside the organization item and sent to people item as well. In the step 2 box, you can define the previous items’ value. To do this, make sure that the Outside value is selected for the first one and for the second one you added the user mailbox that will not be able to receive Internet mail. When done, click on Next
8. In the Actions page, select the option send bounce message to sender with enhanced status code, you can go to Step 2 box, and change the text of the message and status code as well. (Figure 1)

Figure 1

9. In the Exceptions page. Let’s just click on Next, New and Finish.

A second option is using Recipient Filtering anti-spam agent, it is enabled by default in an Edge Transport Server. However, if you are using the Hub Transport role to receive internet mail you need to enable the Anti-Spam Transport Agents, you can find how to do that in this following MSExchange.org article.
Either way, the process to configure the Recipient Filtering is very similar to the previous one. We are going to cover those changes in a Hub Transport, which are as follows;

1. Open Exchange Management Console
2. Expand Organization Configuration
3. Click on Hub Transport
4. Click on Anti-spam tab
5. Double click on Recipient filtering
6. Click on Blocked Recipients tab
7. Check the Block the following recipients option and type in the internal users that you want blocking Internet mail (Figure 2)

Figure 2

The result, as you may expect, is that any message sent from the Internet to anderson@msexchange.org will return a NDR saying that the user does not exist in our organization.
Well, sometimes blocking external incoming traffic to a user is not enough and you want to make the restriction a little tighter. Restricting a user to only receive messages from his boss and no other email client is one such example.
Note:You can also accomplish this requirement by using Transport Rules, however the objective of this article is to give extra options and so, I opted to configure it at mailbox level.
The configuration process is as follows:

1. Open Exchange Management Console
2. Expand Recipient Configuration
3. Click on Mailbox
4. Double click on the mailbox that you want to restrict
5. Click on Mail flow settings tab
6. Click on Message Delivery Restriction and click on Properties
7. On this page, we are able to restrict the user to accept or reject message from specific users. This user can only accept messages from authenticated users (Figure 3)

Note:
Any message coming from the Internet is not authenticated.

Figure 3

Managing outbound traffic

So far we have seen several ways to block inbound traffic directed towards specific internal users, now it is time to block their ability to send internal/external messages. When we speak about restriction, we are speaking about the Hub transport architecture combined with Transport Rules, which when combined do a great job in this sort of management. Therefore, a simple and easy way to mange outbound traffic is by using Transport rules, and this is how you set it up:

1. Open Exchange Management Console
2. Expand Organization Configuration
3. Click on Hub Transport
4. Click on Transport rules tab
5. On Toolbox Actions, click on New Transport Rule
6. In the Introduction page. define a name for the rule and click on Next
7. In the Conditions page, select the from people item and from people inside or outside the organization item. In the Step 2 box you can define the previous items values, make sure that on the first one (from people link) you selected all users that are not allowed to send messages out, and on the second one the value Outside is selected
8. In the Actions page, select the option send bounce message to sender with enhanced status code, you can go to Step 2 box and change the text of the message and status code as well. In this case we are going to change the text to “You are not allowed to send external messages". (Figure 4)

Figure 4

The result will be that any message sent by our test user will generate an NDR on his mailbox and the end-user will be able to see the information about the internal policy that we have just added in our Transport rule (Figure 5).

Figure 5

Dealing with exceptions…

Deploying rules in your organization is really nice but we already know that there is always something and/or some exception which must be created down the road. Technically speaking it is not a big deal and it is included during the transport rule creation process.
However, if you look closely at all the transport rules that we have created so far, there is no built-in rule to allow an internal user to send messages to a specific external domain. You do have the option to create a contact and specify that contact in the exception but it is not possible to do that when the requirement is an entire domain. Let us say that the requirement is that an internal user is able to send messages to any recipient at either Microsoft.com or live.com, well that is a big deal because if the users has a lot of contacts on those domains the contact creation will be painful and unmanageable.
Let us edit the transport rule that we created to block external messages from our organization, and instead select the item except when the text patterns appears in a message header in the Exceptions page. Click on the message header link; type in TO and click on the text patterns link and finally, type in @domain.com$ (where @domain.com can be substituted by any domain that you have in your requirements).
We are going to use a RegEx expression to match the domain(s) that we want to be accepted from our current transport rule. When you see the expression “@domain.com$”, any text that contains that string will be matched, for example: user1@domain.com, userXX@domain.com. However if the user tries user1@domain.com.fr it would not work.
The exception that we added to the transport rule in order to allow internal users to send messages to a specific domain can be seen in the Figure 6.

Figure 6
Now, using the concept we have just seen, we can create an exception for the Inbound Internet mail by editing the existent transport rule and adding the item except when the text patterns appears in a message header item in the Exceptions page. Then, you need to add the text “FROM” on the message header link, and in the list of the domains accepted using the same pattern that we used before (@domain.com$). A summary of this change can be seen in the Figure 7.

Figure 7
These exceptions were created using Transport Rules. If you have in place Sender Filtering or mailbox settings they would not be applied. Keep that in mind when you create your plan to deploy this kind of restriction in your environment.