Build 9575 (March 20, 2026)

Brian Bjerring-Jensen - VonBjerring GmbH Replied

3/22/2026 at 2:45 AM

Upgraded. No issues so far other than an email missing with .ics attachment.

Michael Replied

3/22/2026 at 10:12 AM

Still working on emergency ticket. We detached all domains. Then we re-attached one by one to find that one domain is causing service to max out CPU and memory. When that one domain is loaded, the CPU and memory climbs like crazy and the server becomes unresponsive requiring a reboot. Would be interesting to know if anyone else is having a similar issue. Seems more ideal that SM control it's memory and CPU usage when performing intensive upgrades.

D

Dave Replied

3/22/2026 at 11:37 AM

Is it a big domain or did something happen somewhere in one of the users / files?

D

Douglas Foster Replied

3/22/2026 at 11:49 AM

Seems like we would all benefit if ST created a tool to check for anomalies in json files. These problems seem to get resolved as being caused by dirty data, but we don't know in advance that we have hidden data problems that will break an upgrade.

Michael Replied

3/22/2026 at 1:17 PM

After a really long 24 hours we found the culprit. It was the "archive-searches.json" file. This file is located in the archived messages folder defined for the problem domain. The domain in question has a lot of archive searches. There must be some corruption in that file (support is looking into it). It seems this file keeps track of those searches and something within it was causing start up problems. 3 cheers to Dillon on the emergency support team who dug in and suck with it over the weekend and helped to find the issue. It's great to get this critical domain back online. If you have domains with lots of archived search data you may want to keep this in mind if you run into CPU or memory issues on the update.

Brian Bjerring-Jensen - VonBjerring GmbH Replied

3/22/2026 at 1:48 PM

How to tell if you have that?

D

Dave Replied

3/24/2026 at 5:31 AM

Just had one of my servers hang at about 3 AM EST this morning.

Could not log into webmail or do much else. All the logs I checked stopped at the same time.

Mailservice did not have a lot of RAM used CPU was hovering @ about 10% but nothing was responding.

Restarted the service and all seems better now.

J

Jay Dubb Replied

3/24/2026 at 5:59 AM

Security: Improved SMTP authentication to avoid spoofing.

Anyone have more information on this line item? We have a number of clients who authenticate to the server with their mailbox credentials, but send with a From address of various aliases. From info@, sales@, accounts@, and so forth-- which are aliases on their domain, not individual mailboxes. Does the "avoid spoofing" part break that in any way?

Derek Curtis Replied

3/24/2026 at 6:49 AM

Employee Post

@Jay -- no, that fix will not impact the behavior. It was simply a fix to prevent whitelisted IPs from spoofing without authentication.

Derek Curtis

CCO

SmarterTools Inc.

www.smartertools.com

S

SmP Replied

3/24/2026 at 1:51 PM

@Michael, did they say if they're releasing a detection /fix for it in a forthcoming release? We're holding off on upgrading to the 9575 build as we can't have extended downtime.

J

Jay Dubb Replied

3/25/2026 at 6:46 AM

@Derek Curtis - you may want to verify that. Something changed for sure. We took the 9575 upgrade last night, and the automated emails generated by our billing system did not go out. We have the sending server's IP whitelisted (as it has been for the past 8 years) and the SMTP logs show:

[2026.03.25] 03:04:08.080 [10.128.1.26][54990325] IP in whitelist
[2026.03.25] 03:04:08.080 [10.128.1.26][54990325] IP in authentication bypass

What seems to have changed is this. Our billing system tries to authenticate to the mail server with default (management web interface, not valid on Smartermail) credentials when no email credentials are supplied in the SMTP setup. In the past the authentication would show as FAILED with these bogus (to smartermail) credentials, but the email would be permitted due to Authentication Bypass enabled for that IP:

[2026.03.15] 03:04:08.308 [10.128.1.26][63299038] Authenticating as *********
[2026.03.15] 03:04:08.308 [10.128.1.26][63299038] Authentication failed - login failed domain or user not found *********
[2026.03.15] 03:04:08.308 [10.128.1.26][63299038] rsp: 535 Authentication failed
[2026.03.15] 03:04:08.433 [10.128.1.26][63299038] cmd: RSET
[2026.03.15] 03:04:08.433 [10.128.1.26][63299038] rsp: 250 OK
[2026.03.15] 03:04:08.434 [10.128.1.26][63299038] cmd: AUTH LOGIN

[2026.03.15] 03:04:08.436 [10.128.1.26][63299038] rsp: 235 Authentication successful
[2026.03.15] 03:04:08.436 [10.128.1.26][63299038] Authenticated as **********
[2026.03.15] 03:04:08.479 [10.128.1.26][63299038] cmd: MAIL FROM:<**********@ourdomain.com>

[2026.03.15] 03:04:08.479 [10.128.1.26][63299038] senderEmail(1): **********@ourdomain.com
[2026.03.15] 03:04:08.479 [10.128.1.26][63299038] rsp: 250 OK <**********@ourdomain.com> Sender ok

--- and the SMTP transaction would succeed. We don't know why "235 Authentication successful" would happen immediately after failure, because the credentials were not valid anywhere on Smartermail. We assumed it had to do with Authentication Bypass being enabled.

After upgrading to 9575 last night, all transactions from our billing system are rejected:

[2026.03.25] 03:04:08.080 [10.128.1.26][54990325] IP in whitelist
[2026.03.25] 03:04:08.080 [10.128.1.26][54990325] IP in authentication bypass

[2026.03.25] 03:04:08.278 [10.128.1.26][54990325] Authentication failed - login failed LOGIN_FAILURE_DOMAIN_NOT_FOUND
[2026.03.25] 03:04:08.278 [10.128.1.26][54990325] rsp: 535 Authentication failed
[2026.03.25] 03:04:08.280 [10.128.1.26][54990325] cmd: RSET
[2026.03.25] 03:04:08.280 [10.128.1.26][54990325] rsp: 250 OK
[2026.03.25] 03:04:08.281 [10.128.1.26][54990325] cmd: AUTH PLAIN c2Vrd4RcB5kuZWt3ZXRhAG5hb3h0YXJ6
[2026.03.25] 03:04:08.281 [10.128.1.26][54990325] Authenticating as *********
[2026.03.25] 03:04:08.281 [10.128.1.26][54990325] Authentication failed - login failed
[2026.03.25] 03:04:08.281 [10.128.1.26][54990325] rsp: 535 Authentication failed
[2026.03.25] 03:04:08.282 [10.128.1.26][54990325] cmd: RSET
[2026.03.25] 03:04:08.282 [10.128.1.26][54990325] rsp: 250 OK
[2026.03.25] 03:04:08.678 [10.128.1.26][54990325] disconnected at 3/25/2026 3:04:08 AM

We had to convert our billing alias accounts@ourdomain.com into an actual mailbox (with forwarding, so multiple recipients still receive email to accounts@) and added those credentials to the billing system so tonight's batch does not fail, but I wanted to put this out in case others are running into the same problem after taking 9575.

Andrew Barker Replied

3/25/2026 at 8:20 AM

Employee Post

Based on your explanation, this appears to be an expected result of the security change.

Whitelisting an IP for Bypass SMTP Authentication is intended to make it so that messages received from that source are treated as if the SMTP session was authenticated, even if it wasn't. Prior to 9575, SmarterMail was not keeping good track of whether a session was authenticated or bypassing authentication, which could result in the behavior you observed before upgrading. Since the security change made SmarterMail keep better track of which state the session is actually in, it closed the unintended ability to authenticate as an alias from an IP that is allowed to bypass SMTP.

Note that this change should not interfere with the ability to send as an alias over SMTP. When sending from an authenticated client using an alias as the from address, the client will authenticate with the user's username and password, but will provide the alias as the message sender. When evaluating the MAIL FROM, SmarterMail will confirm that the authenticated user has permission to send as the alias.

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

FrankyBoy Replied

3/26/2026 at 6:59 PM

We would like to report an issue encountered after upgrading to SmarterMail build 9575.

## Context

One of our clients reported a problem opening certain PDF attachments through webmail.

At first, we suspected an issue with the sender, as the problem seemed limited to PDFs from a specific source. However, further investigation showed that the issue started immediately after upgrading to version 9575.

## Description of the issue

- When opening a PDF via webmail:
- the file does not display correctly
- it is offered for download as a PNG file instead of a PDF
- When using “Download all”:
- the extracted PDF file is empty (blank page)
- However, when opening the same email in Outlook:
- the PDF displays correctly
- the file is intact

## Tests performed

- Browsers tested:
- Chrome
- Firefox
- Edge
→ same behavior in all cases

- Cross-check:
- Webmail (9575) → issue occurs
- Outlook → works correctly

## Validation

We performed a rollback to version 9560, and:
- the issue disappears completely
- the same emails and attachments work normally in webmail

This leads us to believe that this is a bug introduced in build 9575, possibly related to how certain PDF attachments are handled or rendered.

We opened a ticket - Smartertool's Team asnwer :

Hello,

Thank you for these details. I was able to replicate this behavior.

I've escalated this issue to our development team for further review. Unfortunately I'm unable to provide a timeline for when the development team will address this as it may take them some time to research and review the problem and implement a solution. However, we will provide you with periodic updates on the progress of the resolution to your issue. We also ask that you keep an eye on the release notes of future builds for information relating to this functionality.

Thank you

John Quest Replied

3/27/2026 at 10:41 AM

On that particular PDF, have you saved it to somewhere, then ran a VirusTotal scan on it and then reviewed all details? Have you opened the PDF with Notepad++? Maybe there is something in particular that sender is doing in generating those PDFs that is uncommon or such.

As an example: (Not related to SmarterMail at all) A certain company was sending in POs in a PDF. Those PDFs were triggering both my custom REDPDF filter as well as ClamAV heuristics scan. Turns out that their Word Template was adding 3 URLs that were purely local only that the original person that created the template had, which by modern security were completely considered malicious. That company went and recreated the template that they use and wala, problem solved.

14 Replies

Reply to Thread