Troubleshooting Transport Rules that are set to “Do not audit”

  • [アーティクル]

When creating a transport rule, please…. PLEASE, do not disable auditing. Your rule auditing setting should not look like this.

Unless of course, you have a security mandate about not auditing transport rules, then please continue on and disable auditing on transport rules. But for those that do not have a security mandate, please do not turn this off!

Why should I not turn it off?

I’m glad you I asked! With auditing disabled (unchecked), a transport rule will not appear in the standard message trace. That’s right, if this rule triggers on a message, and you run a standard message trace on the message, you won’t be able to see what rule triggered. This can make troubleshooting transport rules extremely difficult.

An interesting case

I recently worked with an organization that was not receiving any messages from one of their partners. The sender was not receiving an NDR, and the recipient did not receive the message. When running a message trace, we could see that a transport rule in the recipients’ tenant deleted the message, but the name of the transport rule wasn’t present in the message trace (we later discovered the reason why… auditing had been disabled on this transport rule). All we saw in the message trace was this.

 '[{LED=550 5.2.1 Message deleted by the transport rules agent};{MSG=};{FQDN=};{IP=};{LRT=}]'

If auditing had not been disabled, we also would have seen the name of the transport rule that triggered in the message trace.

The organization wanted to know what transport rule was deleting the message. The tricky part is that there were over 100 transport rules and a lot of them had the action of “delete message.” Going through these rules one by one to try and find the rule with criteria that matched the sending message would be extremely time consuming. If only there was another way.

Wait… there is another way!

Another way!

We pulled an extended message trace for the message and loaded it into Excel. In the custom data column, you can view the transport rules that are evaluated against the message. If you see S:TRA=ETRP, this means that a transport rule was evaluated, but did not trigger. I grabbed the following from an Extended Message Trace that we ran on the message.

In looking at all the rules that were evaluated, I counted about 50. Keep in mind that this organization has well over 100 rules. Since only 50 were evaluated, either a rule triggered with the option of “stop processing more rules,” or a rule triggered with the action of delete. When a rule triggers that has an action of delete, we stop processing subsequent rules.

In looking at the above, we can see the GUID of the last transport rule to trigger. To figure out what this rule is, we can run the following PowerShell.

 Get-TransportRule -Identity <GUID>

This returned the name of a rule, which suspiciously contained the text “Phishing Rule” in the name. In looking at the details of this rule we found it had an action of “Delete Message”, and criteria which matched the message that was deleted. Also…. Auditing was disabled on the transport rule, which is why it never showed up in the original message trace that was run.

Now that we have the transport rule, we could modify the criteria to prevent the false positive detection that is caused.

Help me find my rules that are set to Do Not Audit

If you would like to quickly see what rules you have that are currently set to Do Not Audit, you can run the following PowerShell.

 Get-TransportRule | Where-Object {$_.SetAuditSeverity -like "DoNotAudit"} | fl -property Name, SetAuditSeverity

Wrap up

There are many scenarios that may force you to disable auditing on some transport rules. But if you don’t’ have this justification, run the above PowerShell to verify that you have not accidentally disabled Auditing on any of your transport rules.
For more information, see my previous article on Auditing Transport Rules.

Cheers!

Comments

  • Anonymous
    October 24, 2017
    Deleting (dropping) an email with a transport rule is a bad idea.If if the intention is completely not allow an email, it is better to do "deliver the message to the hosted quarantine".That way it can be retrieved later, "just in case"
    • Anonymous
      November 24, 2017
      I fully support this comment!
  • Anonymous
    October 28, 2017
    Welcome back!Transport rule auditing checkbox is something that we see everytime, but gets most ignored.
  • Anonymous
    November 09, 2017
    Checked all of my ETRs after reading this and, lo and behold, had a couple set to "Do Not Audit".As always, great article.