when will we have MS Outlook server side rules that work like in MS Exchange???
Problem reported by Gabriele Maoret - SERSIS - 3/28/2026 at 1:47 AM
Submitted
This has been requested many times (and it was even promised it would be implemented...), but I'll say it again...

Currently, the biggest complaint from those switching from MS Exchange to SmarterMail is that MS Outlook rules are NOT synchronized with those on the SmarterMail server (sever-side rules), whereas previously (with MS Exchange) they were perfect.

How much longer will we have to wait for this FUNDAMENTAL feature?

I regularly receive dozens of requests about this every month...
Gabriele Maoret - Head of SysAdmins and CISO at SERSIS
Currently manages 7 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 6 on-premise for customers who prefer to have their mail server in-house)
+1
Roger Replied
+1
echoDreamz Replied
+1 though I’ve given up hope. 
Scott Johnson Replied
Based on the attitude of support I believe this to be a never.  Current version now have server side rule execution issues. 
Douglas Foster Replied
Consider these obstacles:

Protocol was a proprietary Microsoft protocol.
 between Outlook and Exchange,  probably never documented, and thus would have to be reverse engineered.

Microsoft is killing Outlook Classic so they can route email through their servers using New Outlook 

Because of Outlook changes, SnarterTools is developing a tight relationship with EmClient.

To my mind, that leaves no business case for investing in your request.   Give them a million dollars and they might change their mind 


Sagar Replied
+1.. lots are promised and even said approved  but never showed up in release note.
Gabriele Maoret - SERSIS Replied
+1 again...
Gabriele Maoret - Head of SysAdmins and CISO at SERSIS
Currently manages 7 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 6 on-premise for customers who prefer to have their mail server in-house)
Scott Johnson Replied
Protocol is easy.  Already works for both Outlook and eMClient.  Rules can be created and stored.  Just are never used nor sync'd to web rules

This has it built in and runs on Linux.
Douglas Foster Replied
Outlook integration aside, I think you can view the new routing rule feature as the starting point for their server side rule system.
but is there anywhere we can see how to configure that?? Much of the documentation is several builds behind the current....
Scott Johnson Replied
Server side rules already exist.  For whatever reason they are named differently in different locations.

User Level is content filtering
Domain Level is content filtering
Server level it is call Routing rules

Name them the same.  They are rules and have been called that since the inception of Exchange

The issue is not a question of the engine's existence.  Just of integrating with email clients other than the web interface.  Not even a question of creating, editing or storing for email clients.  It already does.  Both Outlook and eMClient can view, edit, create and store the same set of rules on the server if tis defined as Exchange.  The rules created by either of these clients are visible/editable to the other. 

These rules are not used nor sync'd with the ones from the web interface that for some reason is stored/identified differently and does function (almost if you avoid the new bugs and don't used features that admittedly never worked right "Tim Uzzanti - The way wildcards worked before wasn't searching for strings the correct way"). 

As it is today the rules created in the web interface are stored and executed server-side and the the rules created and managed by OutLook and eMClient are store but never used and kept separate from those created with the web interface.  Best guess (purely a guess) there was a choice made to not support 100% of the rules that OuLook/eMClient supported so the split.  Complete list of rule options here.

Andrew Barker Replied
Employee Post
While SmarterMail has Routing Rules and Content Rules that overlap with Microsoft's rules system, there are some differences that are preventing us from integrating the two.

Before getting to the issues, it should be noted that routing rules don't really have any relevance to this topic. Routing rules are applied by SmarterMail's spool and serve as a way to define how a message should be handled to reach it's destination. Content filtering is the closest to Microsoft's rules since both apply to a message at the time of delivery.

The first issue is Microsoft's distinction between server-side and client-side rules. Based on our testing, the distinction is made based on the conditions and actions that are configured for the rule. From what I've been able to find, there is no documented list of which conditions and actions make a rule switch from being a server-side rule to being a client-side one.

This leads into another complication. Because one of the available actions is to stop processing additional rules, and because server-side and client-side rules can be mixed together, the server actually has to evaluate both server and client-side rules in order to determine which rules to apply. At the next sync, the server then tells the client which rules it needs to apply for a given message. In order to support that, SmarterMail would need to do the processing all at once, and then store information about the client-side rules that should be applied by the client.

Supporting Microsoft's rule system would also require a significant change to how Content Filters operate. Right now, when a message is being delivered, SmarterMail will only apply the first domain-level content filter that applies to the message and the first user-level content filter. Microsoft's rules, on the other hand, continue processing until there are no more rules or an action indicates rule processing should stop.

Another issue is that Outlook only allows creating rules with AND conditions while SmarterMail supports the ability to design a rule to use either AND or OR conditions. While not a problem for processing the rules, it would be an issue with syncing the rules and allowing users to fully manage their rules in Outlook.

All that is to say, while SmarterMail does currently store the binary data that defines the rules created by Outlook, integrating that rule processing into SmarterMail's current process would require a significant amount of work.

Andrew Barker
Lead Software Developer
SmarterTools Inc.
www.smartertools.com 

Get to work then :)

Your userbase wants it to happen. Its important in regards to SM beeing an Exchange Alternative.

So is groups :)
Matt Petty Replied
Employee Post
Isn't Microsoft trying to kill their own client? Will the new outlook even be able to do this stuff?
Matt Petty
Senior Software Developer
SmarterTools Inc.
Scott Johnson Replied
may answer your question.  Andrew, your interpretation may be off.  Whether the rule-based operation is performed in Exchange (on the server) or by Outlook (on the client) is entirely dependent on whether or not such actions are part of the functionality of Exchange or Outlook. Client-side rules (those that depend on Outlook to be processed), require that an Outlook client store the rule and be open when the rule is triggered, whereas server-side rules are those rules that can be processed directly via the Exchange server.  Same functions are in eMClient. The Server does NOT have to evaluate both server and client-side rules in order to determine which rules to apply.  The server knows nothing about client side rules two separate engines.  Local rules work today without the server's knowledge. 

The AND/OR is more complex.  The simplest and cleanest way tis to sync/display rules from Outlook/eMClient with AND and flag with those that have OR conditions as unavailable for sync/display for clients .  So any rule created/viewed in Outlook is an AND on all conditions.

The Stop processing was a function of a greater control.  The Microsoft way made the rules system and explicit OR between rules not an OR between conditions within the same rule.  This allowed for an OR case by allowing two rules in sequence to be processed thereby negating the need to create OR conditions within the rule.  This allowed for a rule with one condition to process a message followed bay a second that may add additional processing based on additional conditions to the same message. More diverse.

All of this is only applied per mailbox so domain/server processing is not involved.
Andrew Barker Replied
Employee Post
Scott, my previous post reflects both the behavior we've observed working with MAPI and the design of the MAPI protocol itself. Client-side and server-side rules all sync to the server together as rules — they aren't synced separately. In fact, you can see (though not edit) client-side rules in the Exchange web interface alongside the server-side rules. MAPI also includes a property on each rule indicating whether it should be applied client-side. And since a server-side rule with a "stop processing rules" action will prevent lower-priority client-side rules from firing (and vice versa), the rules are clearly not isolated from each other. That interaction wouldn't be possible if they were isolated.

In our testing — both with SmarterMail's MAPI implementation and by observing traffic between Outlook and our private Exchange test server — the server analyzes the rules for each message, applies the server-side actions, and tracks which rules the client still needs to process. Exchange handles this with "Deferred Action Messages," which carry the IDs of the client-side rules to apply. When syncing a new email, Outlook requests any deferred action messages from the server and then processes the referenced client-side rules.

Also, while Microsoft's documentation states that rules are considered client-side if any action can only be done client-side, that doesn't seem to be entirely accurate. In some recent testing, a rule that assigns a category to emails from a specific sender was designated client-side — even though the server is capable of assigning categories. That's the kind of case I was pointing to in my previous post.

Andrew Barker
Lead Software Developer
SmarterTools Inc.
www.smartertools.com 

Scott Johnson Replied
Well just did this.  Created a local rule, eMClient.  Went to a second client attached to same account.  No new local rule.  Create local rule Outlook. Went to other device no new rule.  Rules stay local to system created on as far as I have seen since Office 2010. now I would not argue that the server sends MAPI info to process those local rules.  As far as Web client side.  Is it not treated the same as any other client.  We have never seen client only rules created in the web interface show up or be executed on a Outlook desktop client

Then again maybe I am just full of it and there is "magic" LOL that is hidden.  I have never found a way to recover client-only rules once a config for an account is lost.  MS has specifically told us that those were stored client side and without the previous config there is not way to recover.  We hade this issue on a large enterprise migration of several servers and a few thousand clients.  We could migrate all of the server-side rules but no client-side. 

Reply to Thread

Enter the verification text