On 16 Nov 2020, at 23:46, Laurent Bercot wrote:
> 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).
Those are indeed some of our goals
(
https://github.com/notqmail/notqmail/wiki#what-are-the-projects-goals)
and some of the features we'll need to include
(
https://github.com/notqmail/notqmail/wiki#which-features-will-eventually-be-implemented)
to accomplish those goals. You're right to continue respirating normally
in the considerable meantime. ;-) It might be, as you say, an insane
amount of work. To me, it all feels incrementally reachable from where
we are, and crazy not to try.
For any given desirable feature, I think about questions like
- Imagine that one or more simple implementations already exist. What
would our code have had to look like to make this possible?
- What's the smallest possible interface required by this feature?
- How could the new code be fairly convincing at a quick glance?
- How will we automatically test it?
(I imagine these are familiar thoughts for you, too.)
By my lights, it seems possible-to-likely that the many changes notqmail
needs to make will gradually get easier as we ratchet composability.
> 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. :)
Agreed. I feel fairly strongly that TLS for notqmail must not introduce
a direct dependency on any crypto library; instead, we should remove any
remaining custom networking code and expand our existing dependency on
UCSPI. I've just recently written up one possible path for moving
stepwise from DJB's qmail-remote to a more featureful one:
https://github.com/notqmail/notqmail/wiki/Designs#outbound-starttls-auth-ipv6-etc
(I have vague early ideas for DKIM and SRS, mentioned at
https://schmonz.com/qmail/rejectutils/future and
https://schmonz.com/qmail/rfilter.)
>> 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'm definitely not looking to wedge any SMTP-specific code into
s6-networking! Even if I were, I wouldn't expect you to give it a
moment's consideration. :-p
What I'm looking for in s6-networking is a tiny interface usable by
_any_ UCSPI client or server, if and when _they_ decide it's time to
upgrade a plaintext connection to TLS.
UCSPI-TLS is such an interface. (Please ignore the qmail bits of the
Gifford-and-Brady patch, except insofar as it's useful to you to see how
UCSPI programs could take advantage.)
notqmail's SMTP client and server would decide when to call it. Other
UCSPI implementations of network application protocols with delayed
encryption could do the same. s6-networking would continue to know
nothing about any particular network application protocol.
s6-tlsclient and s6-tlsserver would continue to encrypt connections
immediately by default. Given new command-line options, they'd start up
unencrypted and wait to be told by the application if and when to switch
to encrypted.
Does this make more sense as a request? I'm hoping so.
- Amitai
Received on Tue Nov 17 2020 - 11:23:11 UTC