How to restrict a user from sending or receiving any emails

I came across this interesting question over on technet last week:

Hi,

Is there a way to restrict Mailbox owner from sending internal and external mails?
Are there any restrictive permissions which can be set on the user object in AD which will deny the user from sending any mails from his mailbox. The user should be able to receive and read the mails from the mailbox.

I have tried the option to set the sending limit of the user to 1 KB however i need to know if we can achieve this using permissions.

Mahendra

At first glance you may think that this is tricky to implement and requires messing around with permissions or server settings but as long as you are using Exchange 2007 or Exchange 2010 it is easy to implement (and more importantly, easy to manage!), and it is a great way to introduce how to work with Transport Rules.

Warning for Exchange 2003 users:

As you may have spotted there is a requirement here of at least Exchange 2007 or newer, unfortunately because we will be making use of one of the new features in Exchange 2007 – Transport Rules, this solution wont work on Exchange 2003. If you use Exchange 2003 then your only option is to use delivery restrictions on your send connector, and this puts extra load on your server and will only block external emails, to block internal emails is even more of a pain as your only option is to set the user you want to block as an exception on every user in your organisation (under Exchange General > Delivery Restrictions in ADUC).

So now we have that warning out of the way lets continue 🙂

Now that we have the Hub Transport role in Exchange 2007 we have a central location through which all email flows which makes it an ideal place to enforce rules and company policies. Thankfully, Microsoft also thought of this and implemented a new feature called Transport Rules which allows us to do all sorts of things to emails as they flow through the server.

As Transport Rules run on every Hub Transport server they are found under the Organization Configuration section of the Exchange Management Console.

As you can see, one of the popular uses for Hub Transport rules is to apply a standard disclaimer for the entire organisation (or to apply different ones depending on criteria you choose). To create a new rule either select the New Transport Rule option from the Actions Pane or right click underneath an existing rule, this will launch the Transport Rule Wizard.

When you create a new rule I would always recommend that you give it a descriptive name and make use of the Comment field as it is quite easy to end up with a large number of rules even if you are a small organisation and if you take a few extra seconds to document them now it makes it a lot less painful when you have to come back in a few months time and try and remember what they all do and what they are used for!

Now we can go on to the fun bit and start deciding who we want to apply the rule to.

Now we have to decide what conditions will trigger the rule, you can make these as simple, or as complex as you like, my advice would be to have multiple simply rules rather than one giant rule that does everything not just because lots of simple rules are easier to read and understand, but because as you will see shortly, having multiple simple rules allows us to provide meaningful feedback to the end user explaining not just what happened, but why, rather than just giving them a generic error message that means nothing.

As you can see in my example below, I have kept things simple and only intend to trigger the rule if I attempt to send an email from my account, as you can see there are many other options available making Transport Rules an attractive way to implement many organisation wide policies.

Now we know what will trigger our rule we need to decide what to do with the message, in this case we want to drop the message and stop it from being delivered but rather than just drop the message silently we can choose to send a Non-Delivery Report back to the sender explaining why the message was dropped. It is always worth spending a little extra time in situations like this and putting together a meaningful error message to return to the end use, especially if you intend to make wide use Transport Rules to drop messages for whatever reason as an easy to understand error message will either prevent the need for a call through to IT Support asking what the error means, or will make it much easier for IT Support to quickly see what has happened and explain this to the user.

When deciding on an error it is also worth including an accurate Enhanced Status Code so that the status code matches as close as possible your reason for dropping the message, you can find a list of status codes in this Microsoft KB article, in this case of this example the default 5.7.1 is valid as it is a permanant failure as the user is not permitted to send email, as you can see aswell, there is a more useful error message indicating that the user is not allowed to send email and to contact Brian. While not perfect, the error message at least offers a point of contact and so has to be better than a generic message. We can also then go on to set exceptions to the rule and finally create it.

Hopefully this has given you a basic introduction to working with Transport Rules and has shown how useful they can be, if anyone has any questions or comments do get in touch, either via the comments section below or drop me a note on twitter!