What Rule Touched my Email Message Tracking – Exchange Stuff

TLDR || ERTP = email did not match rule. ETR = email DID match rule – Then match the <GUID> to a rule (get-transportrule <GUID> | fl description) and you’ve worked out the rule. + sometimes you need to look deeper into tracking because messages bifurcate when they have multiple recipients and are processed separately. To find the bifurcated things message track harder bro.

Back story

At work my team fixes things busted on the servers. We don’t help educate the customer how to use the servers. Education belongs to the internet and or other teams here. Few days ago a ticket was raised to my team with “NDR caused by rule – tell us what rule” I closed the ticket with ” homie don’t play that, customer self-service – message tracking, agentinfo, eventdata – it is all there” – Next day the ticket came back with “customer needs help” Normally I’m pretty helpful, but I have a personal rule created out of pain about Transport rules – NEVER TOUCH A RULE | once you touch a rule you OWN THE RULE FOR LIFE

Following my own rules, I closed the ticket again and said “no call someone who teaches nothing is wrong here.” But, having a hard time letting go I kept working on the ticket and wanted provide the answer. Looking through the message tracking in the case I was not able to work out which rule was NDRing the message. Customer had ~27 rules configured to NDR things. The NDR could have been any one of them. I spent a few hours trying to work out which one then, ended up saying F-it and asked for help to work out the rule. Help and I eventually ended up talking with the transport Devs and we still had a hard time working out what was going on. – By now I’m a few hours into working it out, reading code, and talking to people and still don’t have much of a clue yet. Another of my rules, if you have to search for more than 20 minutes to find an answer then you must write the answer. – Now I’m writing about working out rules and researching what all of the letters mean.

Some learning about Reading Transport rules

In my head I thought I’d figured out read message tracking to work out which rule hit a message. Then this case. Below I’ll layout what I thought I understood with some of the new learning tossed in then after the wall of GUIDS I’ll explain what hit in the side of the face on this issue caused the confusion.

Message tracking

We tracked the message based on sender and subject. This KB covers what all of the words mean much better than I can cover them. Each EventId below represents transport doing something to a message. We care about rules touching messages, so we care about the AGENTINFO EventId.


The Agentinfo block shows data about the agents touching a message during Categorization. Again, this KB covers what all of the words mean much better than I can cover them. When you are analyzing rule application the data you care about resides in the EVENTDATA field of the AGENTINFO event which is a super messy not simple to read field.

Eventdata stuff cleaned up

The Eventdata stuff is far from simple to read being all full of numbers and letters not meaning much to normal humans, plus piles of GUIDS, and bad wrapping after the cut and paste from PowerShell. I cleaned it up a bit removing all of the extra spaces, and added a line break every time ], showed up in the data string. After cleaning the data, it becomes a bit simpler to read – see below. Things you’ll want to know to help reading the wall of GUIDS:

  • TRA = Transport Rules Agent – simply saying the rules agent is doing the thing, vs AMA = Anti-malware agent doing the thing. We care about TRA for rules
  • ETRP = Exchange Transport Rule Performance information. It’s showing how long it took the rule to be processed against message.
  • ETR = Transport Rule or Data loss prevention (DLP) rule hit the message and was applied

In the EventData below we start with some AMA anti-malware events [1]. The second one tells us we have an attachment on the file. The next two AMA events tell us which anti-malware engines we are using and which signature file the engines used to touch the message. After the AMA events we are onto the TRA rule agent events filled with piles of ETRP performance events. Mixed in there is a single ETR, rule was processed event. Then some other stuff at the bottom. Our problem, the message in the ticket I was working on was NDRed based on message rule. The rule matching GUID e5qacqe7-897e-447q-8qe7-f5c19qc3c1q8 is not an NDR rule, it’s an apply a footer rule – enter the confusion.

[AMA,EV|engine=K|v=0|sig=19.4.2016 17:11:0|name=|file=]
[TRA,ETR |ruleid=e5qacqe7-897e-447q-8qe7-f5c19qc3c1q8|st=12/11/2015 4:05:17PM|action=SetHeaqer|sev=1|mode=Enforce]
[CompCost, |AMA=0|ETR=0]
[DeliveryPriority, Normal]
[AccountForest, XXXXXX.com]}

The problem tracking

The problem was caused by insufficient tracking data provided in the case. We only had a single AGENTINFO event and the AGENTINFO event did not indicate an NDR rule was hitting the message. We know the message being NDRed because we had an NDR. After a bunch of digging and talking to DEV it turns out we had not performed enough message tracking. If you look at the recipients in the message tracking blob, you’ll notice there are more than 1 recipient is external – I anonymized the addresses and GUIDS in the data , so internal vs. external is not obvious. When a message is sent to an internal recipient and some external recipients the message bifurcates into multiple messages. You have to find all of those streams to find the ETR hitting your message.

Appendix Kev

More data about what the words and letters mean / how to read logs was obtained from the following sources, which might or might not be things you have access to.

[1] not reddit ask me anything events.

Leave a Reply