Exchange Transport Rules, update

| 2 Comments
Remember this from a month ago? As threatened in that post I did go ahead and call Microsoft. To my great pleasure, they were able to reproduce this problem on their side. I've been getting periodic updates from them as they work through the problem. I went through a few cycles of this during the month:

MS Tech: Ahah! We have found the correct regex recipe. This is what it is.
Me: Let's try it out shall we?
MS Tech: Absolutely! Do you mind if we open up an Easy Assist session?
Me: Sure. [does so. Opens sends a few messages through, finds an edge case that the supplied regex doesn't handle]. Looks like we're not there yet in this edge case.
MS Tech: Indeed. Let me try some more things out in the lab and get back to you.

They've finally come up with a set of rules to match this text definition: "Match any X-SpamScore header with a signed integer value between 15 and 30".

Reading the KB article on this you'd think these ORed patterns would match:
^1(5|6|7|8|9)$
^2\d$
^30$
But you'd be wrong. The rule that actually works is:
(^1(5$|6$|7$|8$|9$))|(^2(\d$))|(^3(0$))
Except if ^-
Yes, that 'except if' is actually needed, even though the first rule should never match a negative value. You really need to have the $ inside the parens for the first statement, or it doesn't match right; this won't work: ^1(5|6|7|8|9)$. The same goes for the second statement with the \d$ constructor. The last statement doesn't need the 0$ in parens, but is there to match the pattern of the previous two statements of having the $ in the paren.

Riiiiiight.

In the end, regexes in Exchange 2007 Transport Rules are still broken, but they can be made to work if you pound on them enough. We will not be using them because they are broken, and when Microsoft gets around to fixing them the hack-ass recipes we cook up will probably break at that time as well. A simple value list is what we're using right now, and it works well for 16-30. It doesn't scale as well for 31+, but there does seem to be a ceiling on what X-SpamScore can be set to.

2 Comments

Exchange 2010's Regex function is also buggy in applying OR statements:

This pattern should hit any numbers from 27 to 999:
(^2(7$|8$|9$))|
(^3(\d$))|
(^4(\d$))|
(^5(\d$))|
(^6(\d$))|
(^7(\d$))|
(^8(\d$))|
(^9(\d$))|
(^\d(\d\d$))
But Exchange has a problem with the additional number of digits at the very last entry (^\d(\d\d$)). It is required to create a separate rule for that 3-digit entry.

Chris

I have to clarify my previous message. Could someone look into this?

Thank you.

Exchange 2010 incl. Update Rollup 1 - Regex.

Combinations or Expressions with OR pipe | simply do NOT work as expected. Status as of Exchange 2010 incl. Update Rollup 1. 18.03.2010.

This pattern should hit any numbers from 27 to 999:
(^2(7$|8$|9$))|
(^3(\d$))|
(^4(\d$))|
(^5(\d$))|
(^6(\d$))|
(^7(\d$))|
(^8(\d$))|
(^9(\d$))|
(^\d(\d\d$))
But Exchange has a problem with the additional number of digits at the last entry (^\d(\d\d$)). It is required to create a separate rule for that 3-digit entry.
To make it more magic, the following pattern works: (^\d(\d\d$))|(^\d(\d$))
It asks for a 2-digit or a 3-digit string.