On 16 Nov 2020, at 15:05, Laurent Bercot wrote:

So, the reason why I never followed the ucspi-tls thing is that I simply
don't like opportunistic TLS. A core tenet of my philosophy is that
dynamic stuff is inherently more dangerous than static stuff, and it is
harmful to have dynamic stuff just because we can; every addition of
dynamism should be properly justified.

I tend to agree. Every additional runtime state is an invitation to misunderstandings. It's also the case that when people and tools have come to expect those runtime states, _not_ providing them incurs its own costs and risks.

 starttls-wrapper would:

fixsmtpio(8) sits in this spot and does some of these things. One way to be sure the SMTP server has reset all internal state after STARTTLS is to kill and restart it, architecture permitting. fixsmtpio does exactly this. :-)

* on STARTTLS, drop the plaintext connection to qmail-smtpd, open a
secure connection to localhost:587 with the real tls-enabled server,
replay the start of the dialogue with it, then disappear into the
aether, leaving the client to speak with the real server.

Hmm. This doesn't match my initial expectations:

- Port 587 (1) either has always-on TLS or requires STARTTLS before proceeding, (2) requires AUTH, (3) allows relaying, (4) other submission-specific minutiae

- Port 25 (1) permits STARTTLS, (2) disallows AUTH, (3) disallows relaying, (4) other incoming-specific minutiae

- From qmail's point of view, submission and incoming have been distinct services, often provided by distinct programs

I get the idea, though, and could try to adjust the design to do more of what I'd want.

I wrote fixsmtpio under the assumption that qmail would never have an active upstream, so it'd be cheaper to maintain my own somewhat complex standalone program than to carry around yet another patch. That assumption has since turned false. I now suspect it'd be cheaper to merge UCSPI-TLS logic directly into qmail-smtpd and ofmipd and get rid of fixsmtpio. But that puts a lot of weight on ucspi-ssl.

I'd also like to break up qmail-remote to run its SMTP client under tcpclient, because then it could just as easily run under "sslclient -y" (if there were one, or the s6-networking equivalent), and then STARTTLS support would be simple to add to the client.

So that's why I'm wishing s6-networking would provide an independent (and almost certainly better factored) implementation of UCSPI-TLS: it would give us a boost in our efforts to modernize qmail. But I see why you're not wishing to, too.

- Amitai

Reply via email to