jcoffey-dev c557691059 Sign-in: never offer or take a bearer token on a clear-text connection ...

With plain-text sign-in allowed, IMAP, POP3 and ManageSieve offered
OAUTHBEARER and XOAUTH2 on unencrypted connections and accepted them.
SMTP submission did the same wherever its mechanism setting listed them,
and the default setting listed them on submission ports before
STARTTLS. ManageSieve also offered them on clear text with plain-text
sign-in off, though it then refused them. A mail app would send its
bearer token in the clear, where anyone on the network path could read
it and use it as the account until it expired, in any protocol and over
HTTP.

Bearer token mechanisms now need TLS (implicit, STARTTLS, or a proxy
that reports TLS) in all four protocols, whatever the plain-text or
mechanism settings say. They are left out of the greeting, CAPABILITY,
CAPA and EHLO lists on clear text, and a request for one is refused
before the token is asked for: IMAP with NO [PRIVACYREQUIRED],
ManageSieve with NO (ENCRYPT-NEEDED), POP3 with -ERR and SMTP with 538
5.7.11. Password sign-in keeps following the plain-text setting.
ManageSieve offers an empty SASL list on clear text when plain-text
sign-in is off, next to STARTTLS.

Test: on clear-text IMAP, POP3 and ManageSieve with plain-text sign-in
allowed, the greetings and capability lists offered OAUTHBEARER and
XOAUTH2 and AUTHENTICATE answered "+" or tried the token on main; SMTP
EHLO without TLS offered OAUTHBEARER where the setting allowed every
mechanism. Now none is offered, each request is refused, PLAIN is still
offered, and bearer sign-in over TLS still works.

2026-10-29 06:09:09 -07:00

..

src

Sign-in: never offer or take a bearer token on a clear-text connection

2026-10-29 06:09:09 -07:00

Cargo.toml

Import upstream v0.16.27, stripped

2026-10-18 13:51:24 -07:00