Transport Rules provides an organization with the tools needed to enforce messaging policies across their Exchange organization. You may be familiar with Transport Rules in Exchange Server 2007, and the ability to inspect different parts of a message such as subject, body, and headers for specific words and/or text patterns. If you are not familiar with Transport Rules, you can find an overview in this previous blog post or in the Exchange 2007 documentation on TechNet.
Now supporting attachments
In Exchange Server 2010, we have extended the word and text pattern matching functionality in Transport Rules to include the inspection of supported email attachments. Two new conditions (also known as 'predicates') have been added to Transport Rules:
- when an attachment contains words
- when an attachment matches text patterns
Transport Rules with one of these conditions will parse the body of an attached document (including headers and footers, but not including metadata document properties), looking for word or pattern matches within the document. This enables better control of the information that flows through an Exchange Server 2010 organization. For example, your organization may have a policy that forbids documents containing confidentiality disclaimers from being sent outside of the organization. Transport Rules can be established to enforce that policy. In this example, let's say that the organization wants to bounce back any email with attached documents that contain "Contoso Confidential" in the document (e.g., in the page header or footer of the document). We might have a transport rule configured like this:
In the previous example, we are relying on documents having some classification text already embedded in them. To further automate the leakage protection process, we may want to look for specific text patterns in the document. We can do this by using regular expressions to find text patterns in the attached document (Please see the Exchange 2007 TechNet documentation for details on the regular expressions supported in Exchange 2007 and Exchange 2010). For example, your organization has a policy that forbids the transmission of social security numbers in email, and this includes social security numbers in attached documents. We might have a transport rule configured like this:
In the previous two examples, we focused on blocking messages that matched our criteria. There are several other actions available in transport rules, that can be invoked by these new conditions. These include:
- IRM-protect the message (and attachments) with an AD RMS template
(IRM = Information Rights Management; AD RMS = Active Directory Rights Management Services) - Forward the message for moderation
- Apply message classification
- Apply disclaimer
- Copy the message to another address
- Silently delete the message
Which file types are supported?
Transport Rules attachment inspection supports the same file types as supported by Exchange Search. The attachment inspection feature relies on IFilters to get a text stream from the file attachments. The full set of IFilters installed with Exchange out of the box can be found in the server's registry, under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v14\MSSearch\Filters . File types include:
- Microsoft Office documents (e.g., doc/docx, xls/xlsx, ppt/pptx.)
- Email message formats (e.g., msg, eml, .)
- HTML and text formats
Note: for HTML and XML file attachments, Transport Rules only inspects the rendered content. It does not inspect content inside the markup tags (e.g. ).
How can I add support for additional file types?
Microsoft has tested and supports all of the default IFilters installed with Exchange Server 2010. Third-party IFilters can be added, which could extend the capability for inspecting additional file types. However, Microsoft has not tested third-party IFilters with Transport Rules, so it is highly advised that you fully test any third-party IFilters before deploying into your production environment. Additional files can be parsed by installing and registering the file type's IFilter on each Hub Transport server. For example, you can add support for inspecting PDF file attachments by downloading and installing the Adobe PDF IFilter. After that, simply register the IFilter DLL to the Exchange server registry location:
- Identify the CLSID of the installed IFilter (search under HKeyClassesRoot\CLSID\ in the registry, or get it from installation docs)
For example, the CLSID for PDF files is: {E8978DA6-047F-4E3D-9C78-CDBE46041603} - Create a new registry key under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v14\MSSearch\CLSID with the same name as the CLSID, and a default value which points to the full path of the IFilter DLL file.
For example, for PDF files, the default path of the PDF IFilter is: C:\Program Files\Adobe\Adobe PDF IFilter 9 for 64-bit platforms\bin\PDFFilter.dll - Create a new key under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v14\MSSearch\Filters with the name of the file extension that the filter will handle. Enter the default value for this key to be the CLSID of the IFilter
For example, for PDF files, the key you should create:
Name: .pdf
Value: {E8978DA6-047F-4E3D-9C78-CDBE46041603} - The Network Service needs to have read access to both of these keys. To check the permissions, and allow Read permissions for Network Service, right click on the CLSID and Filter keys, select "Permissions.." Network Service should be added with Read permissions allowed.
Now the Transport Rules engine will be able to inspect these file attachments for the key words and text patterns configured in the Transport Rule condition. The registry cache automatically refreshes every 30 minutes, but if you want the changes to be immediately applied, then restart the Exchange Transport Service on the Hub Transport Server where you made the change. At the Exchange Shell prompt:
Restart-Service msexchangetransport
Note: 3rd party IFilters need to be 64-bit capable for Exchange server to use them.
Note: you can also remove support for specific file types by deleting the keys corresponding to that file extension from the above registry locations.
What happens with attachments that are not supported?
The attachment inspection conditions will only evaluate files that have a corresponding IFilter registered for that file type. If there is no IFilter for a given attachment, then that file is treated as "unsupported". The 2 conditions above will not trigger the rule action on unsupported attachments. For some organizations this may be desired: only act on messages with files that can be inspected. Other organizations may want a stricter control, and may wish to special handle any attachments that cannot be inspected. For this case, we introduced another Transport Rule condition in Exchange Server 2010:
- when attachment is unsupported
For example, let's say that an organization wants to manually review any externally bound email with attachments that cannot be inspected by Transport Rules (e.g., with unsupported file types). We might have a transport rule configured like this:
This enables the compliance officer(s) to approve or reject the message for delivery to external recipients. You can also add your own exceptions in the rule to allow selected users to bypass the control (in the example above we've added an exception for members of the Trusted Senders group to be able to bypass the control).
What about encrypted files?
In general, Transport Rules will not be able to access the contents of user encrypted files. The keys needed to decrypt the content are not available to the server. Exchange Server 2010, however, does support integration with Active Directory Rights Management Services(RMS) such that Transport Rules can decrypt and inspect the contents of Information Rights Management(IRM) protected email and attached Office documentswithin an organization.
What about archive files?
Transport Rules attachment inspection won't support archive files in Exchange Server 2010. The Exchange team will look to add support for navigating and decompressing contents of archive files (e.g., arc, zip, tar, cab, etc.) in a future release. In the Exchange 2010 RTM release, archive files will be treated as "unsupported" files.
Can I block emails with attachments by file type?
Yes, there is a Transport Rule condition that can be used for this in Exchange Server 2007 and Exchange Server 2010:
- when any attachment file name contains text patterns
You can catch messages with attachment file types by adding the file extensions to match in this condition. For example:
Then set the rule action to bounce the message. Note that this only inspects the attached file name and not the attached file contents to determine the file type. If your goal is to prevent viruses by filtering out specific attachment types, regardless of how the file is actually named, then you may want to employ the Attachment Filtering Agentinstead.
Can I block attachments larger than a specific size?
Yes, there is a Transport Rule condition that can be used for this in Exchange Server 2007 and Exchange Server 2010:
- when the size of any attachment is greater than or equal to limit
You can catch messages with attachments larger or equal to specific size (in KB) and apply any of the Transport Rule actions. An organization may use this to prevent large files via email, and to encourage the use of SharePoint sites for collaboration instead.
Is the Transport Rule attachment inspection feature available in the Exchange Server 2010 Beta release?
No, it is not. The Transport Rule attachment inspection feature will be available in the Exchange Server 2010 final release.