Unable to setup SM IMAP account in MacMail & Outlook for Mac
Problem reported by Jarod Clark - 7/11/2024 at 10:13 AM
Submitted
I have an issue getting Mac clients set up with IMAP in MacMail and Outlook for Mac.
We're using build 8451 on our server.
The IMAP ports are set for:
Incoming 993 with SSL
Outgoing 587 with SSL
We're using the same name for both incoming and outgoing servers.

Thinking that it may be the SM version causing the issue, I tried setting up MacMail using our test account on the SM Linux Beta server I have setup with build 8930. I had the same exact issue.
The MacMail client will connect to the incoming server, but not to the outgoing server. The Mac mail connection doctor shows "Connection and login to server succeeded" for the incoming IMAP server.
The Mac mail connection doctor shows "Trying to log in to this SMTP account failed. Verify that the username and password are correct". They are correct, I've double and triple checked.

I believe this an issue with Somoma 14.5, but I'm unsure what has changed with that version in regards to IMAP.
The client did reach out to Apple and they replied with this.
"A server setting is not compatible with Sonoma 14.5. Check your firewall and antivirus."

A Google search did not give any insight. I didn't find any thing in this forum regarding this issue either.

Any help would be appreciated.

Kyle Kerst Replied
Employee Post
You could be facing a mismatch between the versions of TLS/SSL the Mac supports and the TLS/SSL versions supported by the Windows server that hosts SmarterMail potentially. Do you know if they have a common cipher suite available?
Kyle Kerst Acting IT Manager SmarterTools Inc. www.smartertools.com
Jarod Clark Replied
Hi Kyle,

I checked and both our server and MacOS Sonoma support TLS 1.2, TLS1.3 and the same cipher suites.
Any other thoughts?
Have you guys tried to set up an IMAP account with MacOS Sonoma?
George Rauscher Replied

SOLVED -> (UPDATE MACOS & OUTLOOK, newest version)

This needs urgent attention – we are losing customers.

I can confirm this problem 100%. I’ve spent hours testing every possible configuration, and nothing works anymore on macOS.

Environment / setup tested:

– SmarterMail Build 9413 on Linux

– Tested from multiple Macs (Intel and M2)

– macOS 14.6, 14.7, 15.0, 15.7.1

– Clients: Apple Mail, Outlook for Mac (16.79, 16.90, 16.101), eM Client, Mailspring, Thunderbird

– All fail in the same way: connection opens, TLS handshake aborts immediately

Diagnostics performed:

– nc -vz mail.********.app 993/465 → connection succeeded

– openssl s_client -connect mail.*****.app:993 -tls1_3 → tlsv1 alert protocol version

– Tested -tls1_2 → same result

– Set up local TLS proxies (HAProxy and Caddy) with custom certificates and proper OpenSSL termination → Outlook and Apple Mail still fail, because they reuse the macOS TLS stack internally

– Thunderbird using OpenSSL under Windows or Linux works fine

– iPhone/iPad (iOS 17/18) works fine

– Webmail works fine

Conclusion:

The problem is 100% reproducible and limited to macOS clients using Apple’s LibreSSL 3.3 TLS library. It affects Apple Mail, Outlook for Mac, and any other client that relies on the system TLS stack.

The same SmarterMail server is fully functional for Windows, iOS, and all OpenSSL-based clients.

This has already cost me three customers and over five hours of troubleshooting, for nothing. This is a worst-case scenario for anyone hosting SmarterMail for macOS users.

We really need an official statement or a hotfix (temporary TLS compatibility mode, fallback to TLS 1.2, anything). Right now macOS customers cannot use SmarterMail with any desktop client at all.

George A. RauscherMember of the German Society for Criminology (Deutsche Gesellschaft für Kriminalistik e. V.)Member of "LEVA" Law Enforcement and Emergency Services Video Association, Inc.intelligent piXel GmbHExperts in forensic criminologyEnzianstr. 4a82319 Starnberg0800 - 999 8 99 88 (free*)Website: www.intelligent-pixel.comManaging Director: George A. RauscherAuthorized Representative: Dr. Louise MorgottTax Number: 143 / 150 / 31010HRB 207 679 / Munich Local Court
Zach Sylvester Replied
Employee Post
Hey George, 

Thank you for the details. If you go to Settings->Protocols then disable system default and enable only TLS 1.2 does that resolve the issue?


Kind Regards, 

Zach Sylvester Software Developer SmarterTools Inc. www.smartertools.com
George Rauscher Replied
Solution, Smatermail Linux


Severe Bug in Whitelist: activating “TCP Proxy” disables IMAP for all customers

I discovered a critical and fully reproducible bug in SmarterMail (current Tahoe build).

The issue occurs the moment a single IP address is added to the Whitelist with “TCP Proxy” enabled.

Steps to reproduce

  1. Log in as System Administrator.
  2. Go to Security → Whitelist.
  3. Add any public IP address and activate the checkbox “TCP Proxy”.
  4. Save.

Immediately after saving, IMAP access stops working for all users on the system, regardless of their own IPs.

Every connection, from any customer, even from completely unrelated networks fails with:

* NO Server is busy, try again later.
Proxy protocol header not received.
IP xxx.xxx.xxx.xxx rejected for proxy. Reason: not a configured proxy.

No other changes are required to trigger this. The effect is global and instant.

Impact

  • IMAP becomes unavailable for every mailbox on the server.
  • Clients using Apple Mail, Outlook, Thunderbird, etc. cannot connect.
  • Removing or editing the Whitelist entry immediately restores full IMAP functionality.

Root cause

Enabling “TCP Proxy” on a single Whitelist entry appears to switch the entire IMAP listener (port 993 / 143) into Proxy Protocol mode.

Instead of applying the setting only to the specific IP, SmarterMail expects Proxy Protocol headers from all incoming connections.

Normal clients do not send those headers, so the server rejects every connection.

Verification

This behaviour is reproducible on a clean SmarterMail Tahoe installation with no load balancer and default configuration.

The logs show consistent errors until the Whitelist entry with “TCP Proxy” is deleted.

Why this is a critical bug

  • One checkbox for one IP address can disable mail service for all customers.
  • The error message “Server is busy” is misleading.
  • The UI gives no indication that “TCP Proxy” changes the behaviour of the entire port.

Expected behaviour

“TCP Proxy” should apply only to the IPs explicitly configured with that option.

Other IPs should continue to connect normally without Proxy Protocol headers.

Temporary workaround

Remove the Whitelist entry or uncheck “TCP Proxy” and restart SmarterMail.

IMAP connectivity for all customers returns immediately.

Request to SmarterTools

Please fix this behaviour and add a clear warning in the UI:

“Enabling this option activates Proxy Protocol mode on the entire service port.
Only enable this for IPs that actually send Proxy Protocol headers (e.g. from a load balancer).”


This bug can take down IMAP for every user on the system in seconds.

It should be addressed with high priority. I'm sone for today ;-(

After deleting that single Whitelist entry where “TCP Proxy” was enabled, IMAP immediately started working again for all customers.

Every mailbox, including those with completely different IP addresses, could connect normally again.

This confirms that one Whitelist entry with “TCP Proxy” active globally forces the IMAP service into Proxy Protocol mode and blocks all direct client connections until the entry is removed.

----- update -----

For troubleshooting Customer #1, I first added his IP address to the Whitelist to rule out any possible blocking by SmarterMail. While doing so, I accidentally checked the “PROXY” option. This immediately caused IMAP to stop working entirely.


Result: total panic.

George A. RauscherMember of the German Society for Criminology (Deutsche Gesellschaft für Kriminalistik e. V.)Member of "LEVA" Law Enforcement and Emergency Services Video Association, Inc.intelligent piXel GmbHExperts in forensic criminologyEnzianstr. 4a82319 Starnberg0800 - 999 8 99 88 (free*)Website: www.intelligent-pixel.comManaging Director: George A. RauscherAuthorized Representative: Dr. Louise MorgottTax Number: 143 / 150 / 31010HRB 207 679 / Munich Local Court
Zach Sylvester Replied
Employee Post

Hey George,

Thanks for the update. Was this the root cause of the issue you were seeing with Mac computers connecting to the server, or is it a separate issue? If it’s separate, did my suggestion have any effect?

Kind regards,

Zach Sylvester Software Developer SmarterTools Inc. www.smartertools.com
George Rauscher Replied
The single whitelist entry stops smartermail working correctly for all users ;.( thats the root cause. After deleting the single whitelist ip, the whole system works fine again, Sylvester. Isn't it crazy?
George A. RauscherMember of the German Society for Criminology (Deutsche Gesellschaft für Kriminalistik e. V.)Member of "LEVA" Law Enforcement and Emergency Services Video Association, Inc.intelligent piXel GmbHExperts in forensic criminologyEnzianstr. 4a82319 Starnberg0800 - 999 8 99 88 (free*)Website: www.intelligent-pixel.comManaging Director: George A. RauscherAuthorized Representative: Dr. Louise MorgottTax Number: 143 / 150 / 31010HRB 207 679 / Munich Local Court
Gabriele Maoret - SERSIS Replied
THIS IS NOT BUG...

read here :


To mitigate config errors that can be really disruptive , I suggest SmarterMail team to add a BIG AND RED warning and a DOUBLE CONFIRM REQUEST when activate TCP PROXY option in White List
Gabriele Maoret - Head of SysAdmins and CISO at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)

Reply to Thread

Enter the verification text