Build 9686 (Jul 9, 2026)
Question asked by kevind - 7/10/2026 at 7:37 AM
Unanswered
New Build available! Let us know if it works for you so the rest of us can feel comfortable upgrading. 🙂

  • Changed: Windows installer now supports custom username/password for service installation and logon.
  • Fixed: [HA] [HUB] ACME Certs can fail renewal under certain conditions.
  • Fixed: [HA] [HUB] Denial of Service IDS rules are getting double incremented.
  • Fixed: [HA] Hub setup has errors when a new hub joins.
  • Fixed: [HA] Suspending the leader hub can cause nodes to go inactive.
  • Fixed: Bulk attaching domains does not validate the domain names correctly.
  • Fixed: Calendar webcal subscriptions incorrectly parse event end times.
  • Fixed: In some cases, outgoing emails stay in the Drafts folder after sending from webmail.
  • Fixed: Linux path validation for domain primary path does not work as expected for new domains.
  • Fixed: Occasionally emails that contain certain unicode characters in the Subject fail to sync (EWS).
  • Fixed: Outlook (IMAP) does not sync emails to webmail when a folder has special characters in the name.
  • Fixed: Server can hang at startup under certain conditions.
Installed. All ok...
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)
TOAST.net Replied
Installed on our test server this morning. Everything looks good so far. 
NOthing to see here as of now. Spamfoo is also running with very low ressource usage.
Christian Schmit Replied
Installed. All ok so far.
Sagar Replied
I have version of 9672, and after this smartermail service crashed. will this new version able to fix this issue:
Faulting application name: MailService.exe, version: 100.0.9672.29678, time stamp: 0x69e20000
Faulting module name: mscoreei.dll, version: 4.8.9221.0, time stamp: 0x68531e97
Exception code: 0xc00000fd
Fault offset: 0x000000000000f7af
Faulting process id: 0xEE0
Faulting application start time: 0x1DD0882A30E0848
Faulting application path: C:\Program Files (x86)\SmarterTools\SmarterMail\Service\MailService.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscoreei.dll
Report Id: 441c0390-9ea6-43eb-8990-a71127fcaa55
Faulting package full name:
Faulting package-relative application ID:

Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: MailService.exe
P2: 100.0.9672.29678
P3: 69e20000
P4: mscoreei.dll
P5: 4.8.9221.0
P6: 68531e97
P7: c00000fd
P8: 000000000000f7af
P9:
P10:


Sébastien Riccio Replied
9672 has been retired because it had a quite annoying issue. You should use at least 9673, but I guess 9686 is the best bet at the moment.
Sébastien Riccio
System & Network Admin

Go to 9686. It's actually the best release.
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)
Sagar Replied
Upgraded to current version but again same issue..
Event 1000 Application Error 
Faulting application name: clamd.exe, version: 1.5.2.0, time stamp: 0x69a7ae58 
Faulting module name: libclamav.dll, version: 0.0.0.0, time stamp: 0x69a7ae49 
Exception code: 0xc0000409 
Fault offset: 0x00000000000d1fd1 
Faulting process id: 0x2550 
Faulting application start time: 0x1DD12862D114EA8 
Faulting application path: C:\Program Files (x86)\SmarterTools\SmarterMail\Service\Clam\bin64\clamd.exe 
Faulting module path: C:\Program Files (x86)\SmarterTools\SmarterMail\Service\Clam\bin64\libclamav.dll 
Report Id: 10dd741f-05e1-4d96-a812-ea9e151567ab 
Faulting package full name: 
Faulting package-relative application ID: 



============================ 
Event 1023  .NET Runtime 
Application: MailService.exe 
CoreCLR Version: 10.0.726.21808 
.NET Version: 10.0.7 
Description: The process was terminated due to an internal error in the .NET Runtime at IP 0x00007FFF69ABCB74 (0x00007FFF69750000) with exit code 0x80131506.
J. LaDow Replied
@Sagar 
The second "APPCRASH" entry is different from the first. The first shows a .NET framework error - which shouldn't be happening regarding SmarterMail because SM relies on .NET CORE now, not the .NET Framework that is part of Windows OS.

The second crash shows an issue stemming from something related to the CLAM-AV installation on your system that came with SmarterMail.

Maybe look for any CLAM-AV logs and check for any errors in there.

When installing your updates, are you stopping and waiting for the MAILSERVICE.EXE to fully clear and shutdown? Has a server reboot occurred prior to restarting SmarterMail after your upgrade?

What is the status of your .NET runtimes you have installed on your server? SmarterMail requires .NET 10 runtimes to function properly. I think that with the crash variance, I would look at making sure .NET installs are clean and working.
MailEnable survivor / convert --
Sagar Replied
@J. LaDow , during installation, service was auto shutdown and after completed, I did reboot the sever as well. There is no any specific relevant log in CLAM_AV under C:\Program Files (x86)\SmarterTools\SmarterMail\Service\Clam\log
Sagar Replied
In the case of  .NET i have not manually install either framework or core. I follow the steps of smartermail to install automatically during the installation process. I am opening ticket with support hope they can look and identify the issue. It feels uneasy knowing they only work limited hours
BMark Replied
Hello,

After updating to Build 9686 (July 9, 2026), some routing rules that action in "message quarantined" no longer seem to work as they used to. Has this happened to anyone else?
I don't see any errors in the logs, but they don't work as they used to.

Mark
Kyle Kerst Replied
Employee Post
@BMark I did some quick tests with a system level routing rule that triggers on a specific from address and quarantines the message, and this looks to be working as expected for me on the latest release: 
[2026.07.15] 07:44:29.977 [16204409] Removed from SpamCheckQueue (0 queued or processing)
[2026.07.15] 07:44:31.376 [16204409] Applied 1 routing rule(s) to incoming message: KKERST ROUTING TEST
[2026.07.15] 07:44:31.377 [16204409] Delivery finished for sttesting2023@gmail.com at 7:44:31 AM	[id:16204409]
Is it possible another antispam engine is blocking or otherwise affecting the message before the routing rule gets a chance to engage?
Kyle Kerst
Lead Internal Network/System Administrator
SmarterTools Inc.
BMark Replied
Hello Kyle,

thanks for checking,
I'm investigating, but so far I haven't found the cause. The only difference between before and after was the build update and SpamFoo activation.

For example, a rule that no longer works is the one that searches for text in the content and quarantines the messages:
Options:
- All conditions met
- Incoming messages
- Wildcards enabled
Conditions:
- is whitelisted > false
- contains in the body > multiple strings per line
Actions:
- quarantine

Can you test if this rule works for you?

Mark
David Fisher Replied
Simon Andan-Dedic Replied
Employee Post
@David Fisher 
I've dealt with a couple tickets about this recently, and thought I could provide some clarity on the changes:
Recent updates to SmarterMail tightened the parsing logic for wildcard evaluations to ensure better accuracy and performance. Because of this, older filters that have the wildcard setting enabled but don't strictly require it can get bypassed by the new engine.
Disabling that setting on any filters that don't use wildcards such as (* and ?), has been the fix for this.

@BMark 
If you open a ticket, we can analyze the rule further, but this has been the main issue brought up in recent tickets and community posts.
Simon Andan-Dedic
System/Network Administrator
SmarterTools Inc.
Can we get a example syntax for the different rules that works??
David Fisher Replied
@Brian Bjerring-Jensen - VonBjerring GmbH 

  I think what @Simon Andan-Dedic is saying and from my experience, if you are using a wildcard rule and that rule is for "*.world" it is not going to work, as ".world" would match, so the wildcard is not needed and it breaks it by not matching.

  Not sure where in the release notes it lists this, or if the help site has been updated, but seems it needs to do a check and if you hit save it will error saying wildcard is not needed.

  Hopefully things like shop-*.com would catch a wildcard instance, but I haven't had time to test that.

  So maybe the rule of thumb is the string cannot start with a wildcard * or maybe even cannot end with a wildcard * as it automatically includes things before and after.

Kyle Kerst Replied
Employee Post
@BMark Yes absolutely we can test this for you and let you know what we find out. I do believe its likely related to the wildcard change as we recently corrected a problem involving wildcard usage and this lead to changes in how people use them. 
Kyle Kerst
Lead Internal Network/System Administrator
SmarterTools Inc.
BMark Replied
Thanks Kyle and everyone for the feedback.
I can confirm that by removing the wildcards, the routing rules started working again, so I confirm that the problem was as you suggested.

So, is it no longer possible to use wildcards? Or what is the new method allowed?

We've always used wildcards in other sections, such as custom anti-spam rules and the Security > SMTP Blocks section. Do they still work as before, or do they no? And in the latter case, all the rules don't work?

Mark

Reply to Thread

Enter the verification text