How to troubleshoot mail flow rules used to inspect attachments

When troubleshooting mail flow rules related to attachments, it’s crucial to ensure the rules are set up correctly. At times, rules may not work as expected either due to misconfiguration or because behavior related to certain attachments isn’t immediately obvious. This blog will delve into some common issues encountered with attachment-related mail flow rules, provide a systematic approach to diagnosing issues, and offer practical solutions to rectify them. 

To address an issue with a message that wasn’t evaluated correctly, first begin by saving the message as a file.  We’ll use this file in later steps. Then let’s go through different investigation stages…

Confirm the defined file extensions in each of your mail flow rules

Utilizing one of the options below, inspect the rule’s properties in either PowerShell or the Exchange Admin Center (EAC).  This will provide you with an overall list of attachment extensions defined in your mail flow rules.

From PowerShell:

$rule = Get-TransportRule <rule guid or rule name>

$rule.AttachmentExtensionMatchesWords

$rule.ExceptIfAttachmentExtensionMatchesWords

From EAC:

• Log in at https://admin.exchange.microsoft.com/
• In the menu on the left side, navigate to “Mail Flow” and click on “Rules”.
• Locate each rule that inspects attachment extensions, and select it to view its details:

• If you have a longer list of attachments, you can expand it by clicking on the pencil icon:

Review extracted attachment extensions
Run the Test-Message cmdlet against the previously exported message that was not processed as expected.  This report will display attachment extensions found in the message that are being evaluated by a specific transport rule.  You can then compare to the information collected above.
Additional information related to running the Test-Message cmdlet is available in this article:  How to troubleshoot Exchange Online Transport Rules using the Test-Message cmdlet

Note the specific Test-Message output for the desired rule that is of interest in this case is:

Identify message attachments
To gain a better understanding of which attachments the message contains per the rule evaluation, run Test-TextExtraction from PowerShell to determine the attachments contained in the message.  This will require the original message file (.msg or .eml) that was not properly evaluated.

For example: 

The output of the Test-TextExtraction cmdlet will show all parts of the message separately. Every part of the message has its own StreamId, and every part of the message contains these 4 parameters:

• ExtractedStreamText contains text that was extracted from the message part.  
• StreamTextLength shows the number of the characters in the extracted text.  
• StreamName shows the attachment name with an extension and a path where it is located.
• StreamId represents the serial number of the attachment in the message.

For example, let’s analyze part of the message with StreamId = 6 (the dark blue section from the image above)

• The name of the attachment is “AttachmentTextFileInZipFile.txt”.
• Extension of this attachment is “.txt” which means it is attachments in text format.  
• Path to the attachment is: “Message Body/AttachmentZipFile.zip/AttachmentTextFileInZipFile.txt” which means that this attachment is nested in “AttachmentZipFile.zip” attachment.
• Extracted text from the attachment is: “This Text file is inside the .zip file.”

If you need to extend the output so you can see whole fields, run the command $te.ExtractedResults | fl.
And you will see an extended list like this:

Now that you have gathered both extracted results from the message and the values used in certain rules, you can compare and see whether the list of extracted attachment extensions contain values from the rule and if they do, then the rule should be matched.

In the example used in this article we can see the value from the rule itself:

The Test-Message output for the rule evaluation in this case is:

We can conclude that this rule should match because the Test-Message report has at least one attachment extension that is in the rule itself.

Additional cases where this investigation applies

In a very similar way, you can investigate scenarios where ContainsWords and MatchesPatterns predicates are used as well, such as:

• -AttachmentContainsWords/-ExceptIfAttachmentContainsWords
• -AttachmentMatchesPatterns/-ExceptIfAttachmentMatchesPatterns
• -AttachmentNameMatchesPatterns/-ExceptIfAttachmentNameMatchesPatterns

In addition, if you need further understanding on how to create patterns/regex that will suit your purpose, please see Regular expressions in mail flow rules.

Important notes

• If the mail flow rule has been changed (with the values that should be considered for the evaluation), you must wait for up to 30 minutes for the change to be applied before sending a message, otherwise the rule may not behave as expected. More on that here.
• Inline attachments, as well as pictures within message signatures are considered attachments as well.  More on that here.
• Attachments nested inside other attachments are also evaluated against mail flow rules, as documented here.

By following these steps, you can troubleshoot and understand the evaluation of attachment extensions against your mail flow rules.

References:

Milos Nestorovic