No support for Proton Mail Bridge

Summary

Proton users that use the Proton Mail Bridge can currently not connect their email to OpenHuman. The IMAP/SMTP channel introduced in #4367 fails against the Bridge for three reasons, all of them in the vendored tinychannels crate. I am working on a PR over there (link below once it is up); this issue is about what OpenHuman needs on top of that so the fix actually reaches the UI.

Environment: OpenHuman 0.63.12 on macOS, Proton Mail Bridge 3.26.0. The setup form fails with IMAP connection failed — check the host, port, email address, and app password.

Problem

Proton Mail offers no direct IMAP / SMTP support, but instead provides a local "Mail Bridge" that exposes IMAP and SMTP on 127.0.0.1 (default ports 1143 and 1025) and then delegates to their own API. Its TLS certificate is self-signed with IP:127.0.0.1 as the only subject alternative name. Per default STARTTLS is enabled and can be changed to TLS (they still call it SSL) for both protocols.

The email provider in tinychannels (src/providers/email_channel.rs, connect_imap) cannot work with that for three reasons:

• It never issues STARTTLS. The connect is TCP, then an implicit TLS handshake, then LOGIN. Bridge on 1143 speaks plaintext first, so the handshake dies on the greeting. Switching Bridge to SSL mode removes this blocker (only).
• The host must parse as a DNS name. imap_host is converted into rustls_pki_types::DnsName, which rejects IP literals before any connection is made. rustls::pki_types::ServerName would accept both, but that is not what is used. Mind you: localhost does not help either, since the certificate carries no DNS name at all, so hostname verification fails on that one.
• The root store is webpki-roots only. There is no config to add a CA, pin a certificate, or (for loopback dev) skip verification. rustls could trust the Bridge certificate just fine - the crate simply does not let you tell it to.

Also the connect path live-verifies the IMAP login before it persists anything. So there is no hand-edit-the-config escape route: the same connect code fails at startup.

What I verified on my machine: Bridge accepts LOGIN both after STARTTLS and in plaintext on loopback, and SMTP already works with smtp_tls = false (AUTH PLAIN on 1025). In short: SMTP is not blocked, IMAP is.

Workaround considered

Probably (untested): Issue a real (e.g. Let's Encrypt) certificate for a name that resolves to 127.0.0.1, switch the Bridge to SSL mode and load that certificate through Bridge's custom certificate setting. Rinse and repeat on every bridge app update.

Proposed solution

In tinychannels: an imap_security mode (tls / starttls / none, default tls so nothing changes for existing configs), ServerName instead of DnsName so IP hosts work, and a trust override: pin a leaf certificate from a PEM file, add extra CA files, or an explicit accept_invalid_certs flag that is off by default and warns in the log when on. Same knobs for SMTP where cheap.

In OpenHuman:

• Map the new fields in crates/openhuman-core/src/channels/controllers/ops/connect/email.rs. build_email_config constructs EmailConfig with a full struct literal today, so it will not even compile against the new struct without a change.
• Expose them in the setup form: the email channel definition in crates/openhuman-core/src/channels/controllers/definitions.rs and its mirror in app/src/lib/channels/definitions.ts need a security mode select and a certificate path field. Defaults stay as they are (993, TLS).

Acceptance criteria

• IP hosts are accepted - 127.0.0.1 (and ::1) work as imap_host.
• IMAP security mode is selectable - TLS, STARTTLS or none; default TLS.
• A custom certificate can be pinned - path to a PEM file (i.e. /path/to/bridge.pem) for IMAP, ideally SMTP too.
• Skipping verification is an explicit opt-in - off by default, logged loudly when on, never implicit for loopback.
• The setup form exposes the above - and a hand-edited config.toml with the new keys works the same way.
• End to end: Bridge in its default STARTTLS mode, host 127.0.0.1, port 1143, pinned certificate - the connect succeeds and a new mail reaches the agent.

Related

• #4280
• #4367

---

Happy to provide a PR for tinychannels and here