Make TLS mode explicit per leg (IMAP and SMTP), and review the provider presets

[zaridan]

ImapConnectInput.secure is a single boolean applied to two independent connections. It is stored as one column (imap_mailbox_config.secure), sent as one field, and rendered as one "Use TLS" toggle in the connect form.

The two legs routinely differ. Every provider preset in the connect UI pairs IMAP on 993 (implicit TLS) with SMTP on either 465 (implicit) or 587 (STARTTLS).

What was already fixed, and what wasn't

PR #165 fixed the immediate defect: the IMAP leg now derives its TLS mode from imapPort (imapImplicitTlsForPort, RFC 8314 §3.3) instead of taking the shared flag. Before that, an Outlook or iCloud preset (imapPort: 993, smtpPort: 587, secure: false) attempted STARTTLS against an implicit-TLS IMAP port — those presets could never have connected.

That is a targeted fix, not the right end state. It leaves:

• A field whose name lies about its scope. secure now governs only SMTP, but nothing in its name, its column, or its UI label says so.
• TLS inferred rather than stated for IMAP. Port-derived is correct for every port in the presets, and standard, but it is still inference. An operator running IMAP on a non-standard port with implicit TLS has no way to say so.
• One toggle in the UI for two independent settings.

Acceptance

• ImapConnectInput carries per-leg TLS (e.g. imapSecure / smtpSecure), and imap_mailbox_config stores both. Migration 027 has not shipped, so it can be amended in place rather than stacked.
• The connect form presents TLS per leg, or presents a defensible derived default with an advanced override. This is the part that needs a product decision, not just an implementation.
• Presets are updated to state both values explicitly.
• imapImplicitTlsForPort either becomes the default-derivation helper behind the new field, or is removed — it should not survive as a second, competing source of truth.

Also needs a maintainer decision

The preset table's secure values and hostnames were corrected against nodemailer's documented behaviour by whoever wrote them, and the code comment flags that correction for review. Someone should confirm the preset values against each provider's current published settings before this ships to external operators — a wrong preset is a support ticket for every operator who picks it.

Found by CodeRabbit on PR #165 (2026-07-31); partial fix landed there.

[zaridan]

Update from PR #165 — three attempts, three different broken configurations

This is more urgent than it looked when filed. Deriving the IMAP leg's TLS mode from the shared secure flag plus a port was attempted three times in one review cycle, and every rule fixed one real configuration by breaking another:

Rule	Fixes	Breaks
pass secure to both legs	—	993 + secure:false — every Outlook/iCloud preset; STARTTLS on an implicit-TLS port
port === 993	the presets	1993 + secure:true — implicit TLS on a non-standard port
port === 993 || secure	non-standard ports	143 + secure:true — IMAP STARTTLS alongside SMTP on 465, an ordinary self-hosted setup

PR #165 ships the second rule, chosen because its failure is the rarest and least reachable: no preset produces a non-standard implicit-TLS IMAP port, and hitting it requires a deliberately unusual server. The third rule's failure is a configuration a self-hosting operator would meet on day one.

That choice is documented in imapImplicitTlsForPort's doc comment, along with all three rules and a test pinning the known gap, so nobody re-derives this from scratch or "improves" it by adding another operand.

The conclusion that matters

One boolean cannot describe two independent connections. No amount of cleverness in the derivation recovers the missing bit; each rule just relocates which operator is broken. This is not a tuning problem, and the next person to touch it should not attempt a fourth rule.

The fix is the per-leg fields this issue already describes. Raising priority accordingly — every day this stays derived is a day some operator's valid configuration is rejected.

Mitigating factor: every wrong answer fails loudly at connect time with a TLS error, not silently. No configuration is downgraded to cleartext.

Found by successive adversarial Codex passes on PR #165, 2026-07-31.

[zaridan]

A second field with the same flaw: username

The preset audit (2026-07-31, PR #175) turned up an identical "one field, two independent connections" problem next to the TLS one.

Apple publishes different usernames per leg for iCloud Mail:

• IMAP — "usually just the name of your iCloud Mail email address (e.g. johnappleseed, not johnappleseed@icloud.com)"
• SMTP — "your full iCloud Mail email address (e.g. johnappleseed@icloud.com, not johnappleseed)"

Source: Apple, iCloud Mail server settings for other email client apps.

ImapConnectInput.username is a single value handed to both legs, so an iCloud connection cannot express what Apple documents.

Why this is not filed as its own issue

It is the same defect as secure: one field describing two connections that routinely differ. Fixing TLS per-leg without fixing the username per-leg would leave the data model half-corrected, and whoever does the work should see both at once.

Not yet confirmed to be a live failure

Apple's own guidance says "if your email client can't connect using just the name, try using the full address." The full address may work for both legs, in which case the current single field is adequate for iCloud in practice. That is untested — nobody has connected an iCloud mailbox to Helpthread.

So: a known limitation of the data model, not a confirmed broken preset. Worth a real iCloud connection attempt before deciding how much the per-leg username matters.

Scope this adds

Whatever shape the per-leg fields take, they should cover both TLS and username — imapSecure/smtpSecure and imapUsername/smtpUsername, or a nested per-leg object. Migration 028 has shipped now, so this needs a real additive migration rather than an in-place amendment.