One approach would be take idea of https://datatracker.ietf.org/doc/html/rfc8314 and extend it include SMTP itself, which would bring QUIC along doing a happy eyeballs-like attempt at QUIC falling back to TLS-over-TCP falling back to TCP-port-25-STARTTLS falling back to TCP-port-25 plaintext, or as Martin suggested have DNS optimize those choices.
-d > On Feb 25, 2026, at 7:01 PM, John R Levine <[email protected]> wrote: > > If this is one of those frequently re-asked questions, my apologies in > advance, and pointers would be appreciated, but anyway: > > SMTP mail does opportunistic TLS. A session starts on a plain TCP connection > to port 25, then after a command or two the client says STARTTLS, the server > says something like "220 go ahead", then they do the TLS handshake on the > existing TCP connection and the rest of the session is encrypted. > > Someone suggested that a mail sevrver could use QUIC, but I don't see how > that could work. I suppose hypothetically when it sees the STARTTLS it could > drop the TCP connection and continue over UDP, but without extra mechanism > there'd be no way to tell what client UDP port number the session was > supposed to use. Am I missing something? Does anything upgrade existing > sessions to encrypted QUIC? > > There is a variety of mail submission that does the TLS handshake at the > beginning of the session which I suppose could start over QUIC, but that is > something else. > > TIA, > John Levine, [email protected], Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly >
