>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. :-)
Yeah, that would work too. My proposed scheme kills the originally
spawned smtpd and connects to an existing tlsserver spawning its own
smtpd, but if you'd rather not have an existing tlsserver and directly
spawn a tlsd (or sslio or whatever it's called) + smtpd, it's also
valid.
>- 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
To be honest, I've never even tried submission with qmail. It required
a lot more patching and configuration that I was comfortable with. So
I'm not knowledgeable about all the details. But again, what I wrote was
only an outline, and if you're saying that protocol specifics make it a
bad match, then it can be changed, and the starttls wrapper can spawn
its own tls tunnel + smtpd instead of piggybacking to an existing
service.
>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.
Yeah, well, color me unenthusiastic. It's a good thing, don't get me
wrong, but it's like, 20 years late, and the amount of work necessary to
bring qmail up to speed with the garbage truck that is e-mail in 2020
is absolutely insane. So I'm not holding my breath or keeping my hopes
up that qmail will soon be usable as a user-friendly full-featured MTA
that does not need any patching, that builds easily, that is packaged
in mainstream distributions, and that will actually get mail through
any provider (keywords: SPF, DMARC, DKIM).
> 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 also think it's the right thing, because STARTTLS is
protocol-specific
so its handling belongs in the SMTP server. However, doing this right
requires configurability of the TLS layer executable, because
hardcoding a dependency to OpenSSL in the qmail-smtpd binary is a big
no-no.
>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.
Yes, it would be pretty nice. That's one of the things that the
notqmail
team should be working on. :)
>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.
Well, again, STARTTLS is protocol-specific, so it's difficult to
support in a generic networking package. ucspi-tls sounds like a
misnomer
to me; it's really ucspi-ssl + starttls-for-qmail. I can provide modern
versions of the ucspi-ssl programs, and if you need something special
for
the starttls part, we can discuss it, but I would first need to know
exactly what your requirements are. :)
--
Laurent
Received on Mon Nov 16 2020 - 22:46:26 UTC