[Bug] SMTP Error 296 (Handshake failure) on Exim 4.98 (cPanel) - Fails on both SSL/TLS and STARTTLS

[Bug] SMTP Error 296 (Handshake failure) on Exim 4.98 (cPanel) - Fails on both SSL/TLS and STARTTLS

Description

I am unable to send emails using Mailspring with a corporate account hosted on a cPanel server running Exim 4.98.2. IMAP works perfectly, but SMTP fails immediately after the handshake with mailsmtp Last Error Code: 296 (Auth/Handshake failure).
I have performed extensive troubleshooting with the server administrator (root access), ruling out firewall blocking, IP reputation, or credential issues.

To Reproduce…

Steps to reproduce the behavior:

  1. Add an IMAP/SMTP account hosted on cPanel/Exim 4.98.

  2. Configure SMTP with either:
    Port 465 (SSL/TLS) + PLAIN Auth
    Port 587 (STARTTLS) + PLAIN/LOGIN Auth

  3. Attempt to send an email.

  4. Sending fails immediately.

Expected Behavior

The email should be sent. Other clients like Outlook and Thunderbird work perfectly with the exact same settings and network environment.

Screenshots

Setup

Scenario 1: Port 465 (SSL/TLS) The client connects but seems to disconnect right after receiving capabilities, refusing to send credentials.
----------SMTP----------
220-server.domain.com ESMTP Exim 4.98.2 #2 Mon, 26 Jan 2026
220-We do not authorize the use of this system to transport unsolicited,
220 and/or bulk e-mail.
OpenSSL version: OpenSSL 3.6.0 1 Oct 2025
init
EHLO [CLIENT_HOSTNAME]
250-server.domain.com Hello [CLIENT_IP]
250-SIZE 52428800
250-LIMITS MAILMAX=1000 RCPTMAX=50000
250-8BITMIME
250-PIPELINING
250-PIPECONNECT
250-AUTH PLAIN LOGIN
250 HELP
SASL_PATH:
SMTP Last Response Code: 250
mailsmtp Last Error Code: 296
mailsmtp Last Error Explanation: Unknown
mailsmtp Last Error Location: 10
mailsmtp Last Auth Type: 2
Scenario 2: Port 587 (STARTTLS) TLS negotiation succeeds (220 TLS go ahead), but it fails again at the Auth stage.
----------SMTP----------
connect server.domain.com 587

start TLS
STARTTLS
220 TLS go ahead
done
init after starttls
EHLO [CLIENT_HOSTNAME]
250-server.domain.com Hello [CLIENT_IP]

250-AUTH PLAIN LOGIN
250 HELP
mailsmtp Last Error Code: 296

  • OS and Version: Windows 10/11
    • Installation Method: website donwloaded
  • Mailspring Version: latest 1.17.2

Additional Context

OS: Windows 10/11
Mailspring Version: Latest
Server: cPanel / Exim 4.98.2
Verification:
We verified the server logs (Exim). When using Mailspring, the connection drops or times out.
We tested disabling SMTPUTF8 on the server side (Exim config), but Mailspring still returns Error 296.
Outlook Log (Success on same machine): Outlook connects via esmtpsa using TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256 and authenticates successfully (A=dovecot_login), proving the server and credentials are valid.
It appears to be an incompatibility within MailCore2 regarding the handshake/cipher negotiation with newer Exim versions.

Had the same issue: CRITICAL: SMTP Authentication Broken in 1.17.2 - Error 296 with Empty SASL_PATH - Bug Reports - Mailspring Community and looks like it was already reported on the day of latest update as well (just found out): Today’s update breaks SMTP AUTH after STARTTLS (IMAP works) - Bug Reports - Mailspring Community

Release 1.17.1 · Foundry376/Mailspring

Rolling back to 1.17.1 fixes the issue for now, hopefully they can fix it in the next release.

Hope that helps you out for now :wink:

1 Like

Hi folks, thanks for reporting this - I’m sorry this made it into production. This has been fixed in Mailspring 1.17.3, which was released Jan 31. The app should have already updated to that version, or you can grab it from the website.

I really appreciate your patience. If it’s any consolation, this was a result of a major upgrade to a new build pipeline and OpenSSL 3, which puts Mailspring on a solid foundation for another decade of security patches and new features.

We have automated tests that ensure mailsync can connect to IMAP and SMTP, but this particular problem didn’t surface until you /logged in/ to the SMTP server to send mail. I’ve updated our Github Actions to actually perform the login step so we can verify this never happens again.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.