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
