There's no magic in TCP. You could define an equivalent to STARTTLS that starts QUIC, but that's probably not ideal.
SMTP starts with DNS, so a SVCB record for SMTP could replace A/AAAA in the same way that HTTPS records have replaced the same for HTTPS. No TCP needed in that case, except as a fallback in case of QUIC problems. There are some interesting implications to work through in terms of the alias mode variant and how that interacts with MX, so I don't want to pretend this is trivial, but it seems like it might be viable. Once you have a QUIC connection, you also need how to work it. That's another non-trivial hurdle. On Thu, Feb 26, 2026, at 14:01, John R Levine 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
