Interception and Redirection of Messages Using Transport Rules or Journaling


When looking for Exchange controls to copy messages for regulatory compliance needs, you may have come across both Transport Rules and Journaling and wondered, "Which one best serves the needs of my organization?" 

Both features have the capability to intercept and copy messages to another mailbox, but they differ in how they intercept messages and in what details are included in the copied message.  Transport Rules can be employed to satisfy needs for message review and monitoring, while Journaling can be employed to meet the regulatory compliance needs for message archiving.  The purpose of this article is to contrast these features' capabilities of message interception, and to help you identify which will best meet your particular compliance and control requirements.  For a broader understanding of these two Exchange features, please reference the links provided below.

Transport Rules-based message interception

Transport rules are applied when messages are sent or received in your organization.

Transport Rule = Condition + Action + Exception

First, a criteria is evaluated such as who the sender or receiver of the message is, or the keywords in a message.  If messages meet particular criteria (conditions and exceptions), then an action can be applied like 'block,' 'copy,' 'moderate,' or 'append a disclaimer to the message'.  Transport Rules are used to enforce message control and protection policies.

The Transport Rules agent runs on the Exchange Hub Transport server, evaluating every message against the set of Transport Rules.

If your goal is to clandestinely copy certain messages to a supervisory mailbox for post-send review, one could use the "Blind carbon copy (Bcc)" action. For example:

Conditions Apply rule to messages
sent to users that are 'Outside the organization'
and when the Subject field or message body contains 'Secret project code words'
Actions Blind carbon copy(Bcc) the message to 'contentreview@contoso.com'
Exceptions Except when the message is sent to a member of 'trustedpartner@contoso.com'

In this rule, external bound messages containing sensitive project key words are copied to a mailbox, where they will be reviewed periodically for policy violations, except for messages which are addressed to members of the trusted partner group.

If your goal in message interception is to have a supervisor review and approve the message before delivery, then you may want to use the moderation action (new in Exchange 2010). An example of how to configure a Transport Rule for moderation, using the Exchange Management Console (EMC):

Transport Rules Wizard

Figure 1: Transport rule conditions

Transport Rule actions

Figure 2: Transport rule actions

In the example rule above, members of the "Contractors" group are working on a sensitive project and corporate policy dictates that messages sent outside of the organization must be first approved by the user's manager before being delivered. The manager gets an approval request message for the intercepted message, and has the ability to approve or reject the message (via Outlook or OWA).

The advantage that Transport Rules presents is the rich set of conditions & exceptions to which one can scope the rule. One can create very specific rules to intercept messages based on recipients, senders, message content, and/or message properties. For additional details on Transport Rules see:

Journaling for compliance

The journaling feature was developed to meet the needs of enterprise class message archiving, often driven by legal and regulatory requirements, such as the Sarbanes Oxley Act, SEC Rule 17A-4, and other similar regulations. If an archive is required, then Exchange journaling can be used to create records of email communications, including BCC data, DL membership at the time of delivery, etc..  These records are then delivered via SMTP to the archive for de-duplication / discovery and production.

Similar to the Transport Rules agent, the Journaling agent also runs on Hub Transport servers (the Journaling agent runs after the Transport Rules agent), evaluating every message against the set of journal rules.

Journal rules are policies for intercepting and archiving messages to and from regulated users (or sets of users); the journal rule configuration allows one define the target user(s) and scope to global, internal, or external messages. For example:

Journal Rule properties

Figure 3: Journal rule properties

In the example journal rule above, all messages sent to or from User01 will be journaled. The journal reports are sent to the Journal mailbox for archiving.

In the example journal report below, the message, "Sales Forecast," from Test User01 was intercepted by the journal rule. A copy of the original message is attached to the journal report, and message metadata (e.g. recipient details) is included in the journal report body:

Journal report

Figure 4: A journal report includes message metadata and the original message as an attachment

Attaching a copy of the original message to the journal report ensures that the original headers and properties of the message are maintained, as opposed to a message copied by transport rules where some headers will be stripped and properties transformed on delivery. This is one significant difference between a message intercepted by Journaling and a message intercepted by Transport Rules. Other differences are provided in the next section below.

The other advantage that Journaling has over Transport Rules is in the message recipient meta-data provided in the journal report envelope. This lists all of the recipients in the SMTP envelope (P1 recipient list, RFC821), and how each recipient got on the message, including:

  • Distribution group expansion ("To: user01@contoso.com, Expanded: salesteam@contoso.com")
  • Forwarded recipients ("To: user03@contoso.com, Forwarded: user02@contoso.com")
  • BCC'd recipients ("Bcc: reporterdude@treyresearch.net")
  • Recipients added by Transport Rules or any other transport agent (not in the example above, but would be listed as "Recipient: someone@example.com"

Lastly, the journal report messages themselves are privileged messages, which will not be intercepted by transport rules, and can be configured such that they will never expire in a transport queue (e.g., will not NDR). Messages redirected or bcc'd by a Transport rule, on the other hand, are treated just like any other standard message in the system (e.g., can NDR if the target mailbox is unreachable).

For additional details on Journaling see:

Which feature should I use?

In most cases, this decision will probably pivot around how important it is for you to capture the meta-data around intercepted messages. In summary:

  1. Transport Rules support redirecting or BCC'ing messages to another user or mailbox for moderation or review.  This is not suitable for legal e-discovery due to missing metadata and the modified message contents (headers, etc).  This best suited for internal surveillance or corporate policy enforcement, where reviewing the message body content is the primary need.
  2. Journaling supports e-discovery archives and enables copying a full fidelity version of the message.  The journal reports contain BCC, DL membership, etc.  This is best suited for enterprise class archiving and regulatory compliance. If your organization wants to support e-discovery via a third party archive, you need to use Journaling.

Below is a chart of some typical requirements organizations have for message interception (be it for review or archiving), and how each feature meets those needs:

Requirement Transport Rule (Blind carbon copy) Journaling (Journal report)
Message ID:
Is the original submitted message ID preserved?
Yes, the bcc'd message has the same message ID as the original. Yes, in the journal report body and in the attached message.
Message Body:
Is the message body preserved?
Yes, the message body is untouched by the bcc action. Yes, in the attached message to the journal report.
Recipients in the SMTP Envelope:
Is all of the recipient data in the SMTP envelope (aka, P1 recipient list, RFC 821) preserved?
No, the delivered message only has the recipients in the message body (aka., P2 recipient list, RFC 822). Yes, in report body and in the attached message.
Recipients in the Message Body:
Are the recipients in the message body (aka., P2 recipient list, RFC 822) preserved?
Yes, in the bcc'd message headers. Yes, in the report headers and in the attached message.
DL Members:
Is group expansion information included?
No. Yes, in the report body.
BCC:
If the sender addressed BCC recipients, is information about those BCC recipients captured?
No, all bcc recipient (P1 recipient list) information is stripped when delivered.

Yes, in the journal report body and in the attached message.

Transport Rule Recipient Changes:
Are added recipients accounted for?
No, recipients added by transport rules after the bcc rule will not be accounted for in the bcc rule. Yes, the Journaling agent will detect any change in recipients made by Transport Rules or other agent, and will re-evaluate the journal rules against these new recipients.
Moderation:
Are moderation messages and events captured?
No, if the recipients on the message (e.g. moderated distribution groups) were first moderated, the transport rule for bcc would not capture the moderation activity. Yes, the journaling rule would capture approved and rejected messages.
De-duplication:
Are unnecessary duplicate messages prevented?
No, all duplicates will trigger the rule, potentially resulting multiple copies. Yes, duplicate reports to the same journal target address are minimized.
IRM Decryption:
Are IRM-protected messages decrypted in the delivered copy?
No, the bcc recipient will receive an encrypted message (and may not be able to read it). Yes, the Journaling agent can provide both a decrypted copy and an encrypted copy of the message, attached to the journal report.
*Requires configuring Journal Report Decryption
Loss prevention:
Is there a way to ensure delivery of the copied message?
No, if the Bcc target mailbox is unreachable, the Bcc'd message will eventually time out in the queue and fail delivery. Yes, on-premise deployments of Exchange, by default, will hold journal reports indefinitely in the queue until the journal mailbox is available again.
Alternatively, a journaling NDR address can be configured (required for datacenter tenants), to which undeliverable journal reports will be sent.
Comprehensive:
Are all message types evaluated?

No, the Transport Rules agent will not evaluate rules against system messages. Yes, the Journaling agent will evaluate all messages, including system messages.

Both Transport Rules and Journaling are powerful tools for the Exchange admin to meet message policy enforcement needs and regulatory compliance needs of your organization - understanding your organization's real archiving and control needs is key to picking the right technology.

- Steve Clagg




Comments (2)
  1. Jose Cumplido says:

    We are using journaling in Exchange 2010 and we are having a strange behaviour in the journal reports. Text  attachments appear with a content-transfer-encoding value of base64 but the text is being transfered in clear and all the binary attachments cannot be opened. This is working differently in Exchange 2007. A sample of this:

    –_005_95A98ED8683588459FEEEC140970F755026C065DDUCATIDCducatis_

    Content-Type: text/plain; name="imap-accounts.txt"

    Content-Description: imap-accounts.txt

    Content-Disposition: attachment; filename="imap-accounts.txt"; size=269;

    creation-date="Mon, 15 Feb 2010 16:20:49 GMT";

    modification-date="Mon, 15 Feb 2010 16:20:49 GMT"

    Content-Transfer-Encoding: base64

    adimp

    admin

    Admin1

    agente3

    agente4

    ….

    Is there any setting to avoid this?

    Thanks,

    Jose

  2. Steve Clagg says:

    Jose, I don’t think that there is a configurable setting for this behavior.  You should contact technical support and provide them with all of the reproducible details.

     

    http://support.microsoft.com/select/Default.aspx?target=assistance

Comments are closed.

Skip to main content