[Bug] SMTP on port 465 always fails (STARTTLS used on implicit-TLS port)

[Paula129419]

Where in the app

Compose / send — drafts, replies, sending, Sent folder

What happened

Provider: IONOS (imap.ionos.de:993, smtp.ionos.de:465, Security SSL/TLS).
Receiving works. Sending fails every time with:

"SMTP connection to smtp.ionos.de:465 failed: response error: incomplete response"

The server is fine: from the same Mac, openssl s_client to
smtp.ionos.de:465 gives TLS 1.3, a 220 greeting and a normal EHLO reply.

Workaround that works for me: leave Security on SSL/TLS, IMAP 993, and
change only the SMTP port to 587.

Possible cause, from reading the source: AccountModal.jsx initialises
smtpSecure: false and nothing sets it to true; the Security dropdown
only changes imapSecurity. use_implicit_tls() in src-core/src/smtp.rs
lets the explicit flag win over the port, so port 465 is dialled with
STARTTLS instead of implicit TLS.

What you expected instead

Sending on port 465 works with implicit TLS, or the form offers a
separate SMTP security setting. The Security dropdown looks as if it
applied to SMTP too, but it only affects IMAP.

Steps to reproduce

1. Add an IMAP account with SMTP port 465 (e.g. smtp.ionos.de).
2. Compose a message and send it.
3. The send fails with "incomplete response"

MailVault version

2.18.1

Operating system

macOS (Apple Silicon)

OS version

27.0.1

How you installed it

DMG from mailvaultapp.com

Mail provider

Other — name it in the text above

How you sign in to it

IMAP with an app-specific password

How many accounts it affects

Every account

How often it happens

Every time

Did any mail get lost?

No — nothing is missing

Logs and screenshots

Before you post

• I'm on the latest release and checked the changelog
• I searched Bug Reports for the same thing
• No passwords, tokens, or other people's addresses in this report

[rokas-ambrazevicius]

Fix incoming... ETA: 2-4 hours. Building a test build with fix.

[rokas-ambrazevicius]

Thanks for the report and the source reading, the diagnosis was spot on. The account form saved smtpSecure: false for every account, and that flag overrode port 465, so the app tried STARTTLS on an implicit-TLS port. Port 465 now always connects with TLS from the start, including for accounts you already added, so you can switch your SMTP port back to 465 once you have the update. Port 587 keeps using STARTTLS. The fix ships in the next release.

[Paula129419]

Thanks for the quick fix. Port 587 works for me in the meantime.

[rokas-ambrazevicius]

Sorry, ETA: tomorrow morning-mid day. Found more minor issues and just saw the other issue ticket. Want to combine them into a single release fix.

[rokas-ambrazevicius]

I hope this one’s working perfectly for you? 😊

[rokas-ambrazevicius]

Fixed and released 👍

[Paula129419]

Updated and switched back to port 465, sending works now. Thanks for the fast turnaround!

Two observations:

After saving, the “Change server” dialog warned “Couldn’t verify DKIM (26 common selectors checked) … outgoing mail may be marked as spam”. For IONOS this warning is wrong. IONOS uses the selectors s1-ionos, s2-ionos and s42582890, and DKIM was set up correctly all along (dkim=pass in the received headers). It took me quite a while to find that out, because the warning reads as if something were broken on my side. I have changed account settings before and never saw this warning. Is the check new in this release? Please add the IONOS selectors.
Outlook behaved strangely. My first test mails from MailVault to an outlook.de address never arrived (no bounce, not in junk), while the same mail arrived at iCloud. After I sent one from Apple Mail, mails from MailVault arrived as well. I can’t tell whether that is coincidence or Microsoft’s filter.

[rokas-ambrazevicius]

Glad sending works on 465 now, that was the fix from the last release: port 465 always connects with TLS from the start, including for accounts you added earlier.

On your two observations:

DKIM warning. You’re right, it was a false alarm for IONOS. After you save server settings, MailVault looks up your domain’s DKIM key under a list of common selector names. It didn’t know IONOS’s s1-ionos and s2-ionos, so it found nothing and warned, even though your DKIM was set up correctly. Both are on the list now, and the fix ships later today. The check has been in the app since 2.7.0. It only runs after a server change, which is probably why you hadn’t seen it before. One caveat: s42582890 is specific to your account, so it can’t be on a shared list. If your domain only publishes under that one, the warning can still appear. The text says it may be a false alarm for a custom selector, and that is the case here.

Outlook. We reproduced this on our side. A correctly signed mail (SPF, DKIM and DMARC all passing) sent from MailVault to a brand-new Hotmail address was accepted and put in Junk. MailVault builds the message the same way as any other client, so nothing in it is wrong. Microsoft is very strict with the first mail from a sender to a recipient it has never heard from, and it can drop or quarantine it without a bounce. Your Apple Mail test fits that. Once Microsoft has seen the sender, or the recipient replies or marks a message as not junk, later mail arrives normally. If a mail from MailVault ever goes missing again, send us the time and recipient domain and we’ll look at the headers.

[rokas-ambrazevicius]

MailVault 2.19.2 is published now, with the DKIM fix. You can download it from the release page or update from inside the app. Snap users get it from the Snap Store stable channel.