What happens to Legacy Software of SmarterMail prior to Build 9526 (Jan 30, 2026) NOW?

Problem reported by Howell Dell - 2/3/2026 at 1:21 AM

Submitted

I know a lot of folks are sensitive about cost but at this point your organization has NO business running an older version of SmarterMail, 3CX, SonicWALL or X anything with known CVEs baked in. Even Ubuntu 24 had a ~10 Year old bug in Telnet with Auth Bypass that was just discovered a few months ago!!! Who is running Telent in 2026? Supposedly 80K Telnet's are open to the world! Why? If anyone does not want to run SmarterMail themselves then DM me and maybe I can HELP.

#1: I assume SmarterMail is NOT going to back port these CVE fixes and fix all or some of the now Legacy Versions of SmarterMail??!! Maybe a huge RED BANNER is needed or simply remove all these versions OR double or triple opt in?

If NOT then some user that is out of scope on these CVEs is not going to know about these issues and cause more harm in that all these OLD versions of SmarterMail prior to Build 9526 (Jan 30, 2026) are effectively defective! This should become a version Build demarc that we are starting over (Build 10000?) -- this is a watershed moment?

#2: Also, SmarterMail should now be looking at connections at the Web Server level and I'm seeing a lot of garbage of hackers trying to throw other things like wordpress, sql injection, and python scripts at the web server. I just scanned my new logfiles since the weekend and see ~4K python scripts (including "*.env*" requests) and ~9K PHP requests. Can we leverage all of this data as a honeypot that feeds into the IDS to block more bad actors? I am sure we will see more force-reset-password attempts and other things that don't belong in the future. We also have the https://modsecurity.org project to leverage as well.

#3: What about SmarterMail running its own file scanner of the installed files and with hashes can shutdown into a safe mode if a problem exists or when a file shows up in the wrong place. Most of SmarterMail Internals should be RO?

8 Replies

Reply to Thread

J. LaDow Replied

2/3/2026 at 7:18 AM

Re: Filtering the webmail / attack scans:

All of that extra "scanning" noise for stuff like PHP, wordpress crap, .env files, etc... Those are broad-range "scanning" attacks seeing what you're running. Those have been hitting servers long before the SM vulnerabilities -- that's literally script kiddies scanning servers looking for common apps or vulnerabilities. That same scanning hits our public web servers on a level that rivals the AI bots in scraping... Our WAF logs hits to certain files in those scans they try to hit and then our IDS dq's the IPs for minimum 90 days... Running a third party WAF at the proxy server level in either IIS or Apache would be the best way to protect against most of that garbage.

Re: Smartermail "backports" / older versions:

There won't be backports of fixes because of the rolling release schedule, and the legacy versions are essentially useless because they're vulnerable -- just to answer two notes.

MailEnable survivor / convert --

Howell Dell Replied

2/3/2026 at 11:41 AM

Yes, that is what I expected -- no back ports. Thus all legacy versions have no value before SmarterMail Build 9526 (January 30, 2026).

On the other hand, broad-range "scanning" attacks can be used as honeypot to block source IPs and this Cloud be a new IDS WAF category. I had some +600 force password resets.

J. LaDow Replied

2/3/2026 at 11:57 AM

We block multiple bad user agents at the server level in IIS. It needs to be the top entry in the rewrite rules section before the other rules are picked up. It doesn't kill all the hits, but it definitely catches a lot of them. Then we have our IDS which watches the IIS logs - it also looks for those same user agents and then blocks the IP for min. 90 days. Your mileage may vary.

Be aware that a lot of "uptime agents" ahve user agent strings like Go-http-client (looking at you, Plesk)...

<rule name="BAD-UA" patternSyntax="ECMAScript" stopProcessing="true">
    <match url=".*" />
        <conditions logicalGrouping="MatchAny">
            <add input="{HTTP_USER_AGENT}" pattern="Trident\/7\.0" />
            <add input="{HTTP_USER_AGENT}" pattern="Go-http-client" />
            <add input="{HTTP_USER_AGENT}" pattern="python-requests" />
        </conditions>
    <action type="AbortRequest" />
</rule>

MailEnable survivor / convert --

Howell Dell Replied

2/3/2026 at 2:50 PM

You said "have our IDS which watches the IIS logs". What IDS home grown or something else?

J. LaDow Replied

2/3/2026 at 3:02 PM

It's a mostly homegrown solution that relies mainly on RegEx patterns - we use it to weed out a lot of the basic attack stuff and send blocklist adds to our edge. Depending on what server/log files it's scanning determines how it responds. The mail server is setup to be way more sensitive than our web servers.

At the server level, we have DigitalRuby's IPBanPro for country and ASN blocking. Helps a lot when we see abusive providers show up in the logs - and just DQ the whole ASN. Depending on what clients are on what servers, we do the country blocking as well.

It's a war --

MailEnable survivor / convert --

John Quest Replied

2/3/2026 at 5:09 PM

Just to clarify, legacy builds would be more like pre Build 6919 (12/11/2018) or pre build 8025 (12/21/2021)

Jay Dubb Replied

2/4/2026 at 8:12 AM

@J. LaDow - how happy are you with IPBan Pro?

We're trying the community edition to get a feel for how effectively it detects and blocks by IP, before committing to the paid version with extra features.

J. LaDow Replied

2/4/2026 at 8:41 AM

When you get your "recipes" tuned right, it's VERY useful. Is it a one-stop solution? No - but it can definitely quiet things down.

In our case, we have some policies on what users can have for usernames and aliases - that way, we can listen for attempted abusive logins and just insta-ban the IPs the moment they're seen. We get some of usage out of the country filter because there are only a select few countries our client base operates in - so there's no need to respond to either end user IPs or mail servers in those countries. Additionally, we restrict logins from outside countries via SmarterMail's Country Filter, then when an attempted login shows up from a banned country, we insta-ban the IP with the log monitoring. We also use the ASN filters when we see lots of abusive IPs or spam attacks and no legitimate mail. Again - it doesn't catch everything but it definitely makes a dent in the noise.

Cons: I am no fan of the web-interface for it. But there is an API hidden in there. I'm working on revamping some of our integration and when I get documentation for the API that will help. The online documentation is pretty abysmal but I mean there's not much to it if you spend a little time on your regex. I could share some of the recipes we use

They have what they call DataCenter edition which allows you to basically have a remote/shared web interface for however many servers you decide to install it on. Additionally it's cross-platform so it will run on the Linux boxes as well.

When you install it, I can't stress enough to make sure the first thing you do is safelist your own IPs and save/restart it - so they get locked in.

MailEnable survivor / convert --

Back to Community Threads

Please leave this box unchecked

Reply to Thread

Enter the verification text