Organization-wide message disclaimers "except For" stopped working

Steve Parry (SAMS) 0

I have a Mail Transport Rule (established following the principles here: https://learn.microsoft.com/en-us/exchange/security-and-compliance/mail-flow-rules/disclaimers-signatures-footers-or-headers).

This rule has been working fine, successfully not adding another disclaimer if part of the text in the disclaimer already existed in the Message.

A few weeks ago (specific date unknown) I found that the transport rule had stopped detecting that there was already the disclaimer text present, and therefore email trails were having numerous disclaimers added.

When I investigated last week I discovered that something seems to have changed, and the exclusion text (which definitely exists in the disclaimer) wasn't being triggered.

I tested this by copying the text I was searching for to before the "dash dash space" at the head of the disclaimer, for which the transport rule worked as expected. Putting the search text after the "-- " failed, as did removing the "-- " altogether.

Does anyone have any ideas or suggestions?

Thank you!

1 answer

Jake Zhang-MSFT 5,670 Reputation points Microsoft Vendor

2024-09-09T08:37:06.0533333+00:00
Hi @Steve Parry (SAMS) ,

Welcome to the Microsoft Q&A platform!

It sounds like you have a well-thought-out mail transport rule to manage your email disclaimers, but something has changed, causing issues. Let's break down some potential troubleshooting steps and solutions to address this.

Potential Causes and Solutions:

Format and Punctuation Changes:

Your detailed testing indicates that the presence of -- (dash dash space) might be creating an issue.

Ensure that there have been no changes in formatting or hidden characters within the disclaimer text. Sometimes, even an invisible character can cause mismatches.

Email Encoding:

If the encoding of emails has changed (e.g., from plain text to HTML), it might affect how text is detected. Verify that the transport rule applies to the correct encoding.

Rule Order and Conditions:

Double-check the order of your transport rules. They are processed in order, and a preceding rule might be affecting the processing of your disclaimer rule.

Review all conditions and exceptions in the rule to make sure they still match your requirements. 4. Recent Updates or Changes:

Check if there were any recent updates or changes to your email server or platform that might affect mail transport rules. Microsoft Exchange and similar platforms often receive updates that can change behavior slightly.

Testing and Isolation:

As you indicated, the problem seems to be with the text detection after -- . Try simplifying the disclaimer temporarily to isolate the issue.

Test different variations of the disclaimer, such as removing or altering the problematic text. This can help pinpoint the cause.

Steps to Test and Validate:

Verify Rule Configuration:

Access the rule settings in your Exchange admin center.

Ensure that the text matching condition is exactly as intended.

Create a Test Rule:

Create a simplified test rule with a basic disclaimer without the -- and see if it is detected correctly.

Gradually introduce elements of the original disclaimer until you identify the breaking point.

Log and Monitor:

Enable logging for your mail transport rule (if available). Sometimes detailed logs can provide insights into why the match fails.

Contact Support:

If the issue persists, consider reaching out to Microsoft Support or consulting Exchange community forums. Document your findings and tests to provide them with detailed context.

Example Transport Rule Update:

Modify Disclaimer Text:

Ensure that your disclaimer template does not contain problematic characters.

Example:

-- Legal Disclaimer: This email and its attachments are confidential...

Testing Scenario:

Create emails that test just before and just after the -- to isolate the change.

Please feel free to contact me for any updates. And if this helps, don't forget to mark it as an answer.

Best,

Jake Zhang
Please sign in to rate this answer.
Steve Parry (SAMS) 0 Reputation points

2024-09-10T07:13:10.6966667+00:00

Thank you Jake. Still working through isolating the problem. Hopefully replay back tomorrow with more detail.

Steve Parry (SAMS) 0 Reputation points

2024-09-11T04:17:09.71+00:00

Hi Jake.

Thank you for your detailed reply.

The text of the disclaimer hasn't changed since it was set up 11 July 2024, until I started investigating the issue recently! The disclaimer is in HTML, has gone through an HTML validator, and I copied the HTML into notepad and back again just to ensure it was clear of any yukky characters.

The rule is Rule 0.

Having conducted some more tests (see below) I'm now thinking the dash dash space was a red herring to me, perhaps caused by my not realising that rule changes (annoyingly) take a variable amount of time to come into force (from a few seconds to 15 minutes in my subsequent testing), and can get implemented to new mails and reply emails at different times. This may have misled my interpretation of test results.

For my most recent testing I was careful to ensure I was identifying the disclaimer text actually being used by adding a unique test identifier into the disclaimer text!

From that testing, it seems to me now that "Except If" alphanumeric string will not be found if:

the string is inside round, curly or square brackets at the end of the disclaimer text.

there is no space character inside the brackets.

the last word or number sequence within the brackets is not searched as a whole string (unless it contains a space).

All very weird and I hope that there is a logical explanation for these symptoms!

Any thoughts?

Cheers

...Steve

FYI The detail of my test cases and results are below:

Original disclaimer text: "If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future. [v20240906]"

Original "Except If" string (that used to work): "message and follow with its deletion, so that we can ensure such a mistake does not occur in the future. [v202"

Test of "Except If" Phrases:

"future. [v20240910]" Works "future. [v202" Fails "[v20240910]" Works "[v202" Fails "0910" Fails

Remove the "[" and "]" from the disclaimer text (and the "Except if" string) in case they were causing the error.

"future. v202" Fails "future. v20240910" Works "v20240910" Works "v202" Fails "0910" Fails

Add a space in the version number to read "v202 40910" (no square brackets) in the disclaimer text (and the "Except if" string) in case there was a number string issue (whole word for numbers?).

"v202" Works "future. v202" Works

Reinstate [ and ] in disclaimer text, leaving space after number

"future. [v202" Works "[v202" Works

Reinstate the whole, original search string with square brackets (leaving space in the disclaimer text - "[v202 40910]")

"message and follow with its deletion, so that we can ensure such a mistake does not occur in the future. [v202" Works

Remove the space from the disclaimer text - "[v20240910]".

"message and follow with its deletion, so that we can ensure such a mistake does not occur in the future. [v202" FAILED. (issue confirmed)

Repeated all tests with round and curly brackets - same results.

Jake Zhang-MSFT 5,670 Reputation points Microsoft Vendor

2024-09-12T08:55:13.9666667+00:00

Hi @Steve Parry (SAMS) ,

Thanks for your response!

According to your description,you’ve been very thorough in your testing. The behavior you’re describing does seem quite peculiar.

Here are a few thoughts that might help explain the symptoms you’re seeing:

It appears that the system might be treating text within brackets differently, especially at the end of the string. This could be due to how the search algorithm parses and indexes text. Brackets might be considered delimiters, causing the enclosed text to be treated as a separate token.

The presence or absence of spaces within the brackets seems to affect the search results. This suggests that the search algorithm might be splitting the text into tokens based on spaces and other delimiters, and then searching for exact matches of these tokens.

The failure of partial matches (e.g., “v202” failing while “v20240910” works) indicates that the search might require complete tokens to match. This could be a design choice to avoid false positives in searches.

The delay in rule changes taking effect could be due to caching or propagation delays within the system. This is common in distributed systems where changes need to be synchronized across multiple servers or services.

Given these points, here are a few suggestions for further testing or potential workarounds:

Ensure that the disclaimer text and the “Except If” string are formatted consistently, including spaces and brackets.

Try testing with different delimiters (e.g., dashes, underscores) to see if they affect the search behavior similarly.

If possible, check the documentation for the search algorithm or system you’re using. It might provide insights into how text is tokenized and indexed.

Please feel free to contact me for any updates. And if this helps, don't forget to mark it as an answer.

Best,

Jake Zhang

Jake Zhang-MSFT 5,670 Reputation points Microsoft Vendor

2024-09-17T06:17:45.91+00:00

Hi @Steve Parry (SAMS) ,

Please kindly consider this comment as a warm follow up, I want to know if your problem has been solved. If you still have any other questions, please feel free to comment here and I'm glad to provide further support.If the above info is helpful to this question, you can click "Accept Answer". Have a nice day!

Best,

Jake Zhang

Steve Parry (SAMS) 0 Reputation points

2024-09-17T07:02:33.6+00:00

Hi Jake.

No it isn't solved, and I haven't found time to test the different delimiters you suggested - sorry.

The workaround ('Reinstate the whole, original search string with square brackets (leaving space in the disclaimer text - "[v202 40910]") ') means that the disclaimers are now being processed correctly, but it's not a solution to the actual issue.

Cheers

...Steve

Jake Zhang-MSFT 5,670 Reputation points Microsoft Vendor

2024-09-19T08:17:30.96+00:00

Hi @Steve Parry (SAMS) ,

Don't worry, Steve! Given the complexity of the problem, here are some additional steps you can consider if you have time:

Testing different delimiters may help determine if the problem is with a specific character. Trying parentheses, curly braces, and square brackets with and without spaces may provide more insight.

Another approach may be to use a custom header to mark emails that have a disclaimer added. That way, transport rules can check for the presence of this header instead of relying on text matching in the body of the email.

If possible, using regular expressions (regex) in transport rules may provide more flexibility in matching patterns, including patterns within parentheses. This can help accurately detect disclaimer text.

Best,

Jake Zhang

Jake Zhang-MSFT 5,670 Reputation points Microsoft Vendor

2024-10-01T09:35:43.6366667+00:00

Hi @Steve Parry (SAMS) ,

Any updates so far? If you have solved your problem, could you share with us? Maybe it will help more people with similar problems. Don't forget to mark it as answer, this will be easy for other community members to find the useful one. Thanks for your understanding.

Best,

Jake Zhang
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Organization-wide message disclaimers "except For" stopped working

1 answer

Potential Causes and Solutions:

Steps to Test and Validate:

Example Transport Rule Update:

Your answer