Re: qmail.org DEAD?

On 2 Jul 2019, at 12:13, Amitai Schleier wrote:

> I suspect a more fruitful question is, how could we arrive at an 
> active and agreed group of developers collaborating to ship sensible, 
> trustworthy, seamless, and therefore sufficiently authoritative 
> updates to qmail?

A couple updates, both off-list but public:

1. Russ Nelson wasn't aware that qmail.org had gone nxdomain, and said 
he'd take a look.

2. Dave Sill reminded me that qmail's design integrity and extremely low 
bug count are what made it special, and a modernized version that loses 
these characteristics wouldn't be worth much. I agreed (as I imagine we 
all do), and went on to muse on my design choices and future plans. 
Sharing that here:

-----

qmail's design is why it met our needs so well back then, and it's why 
I've found it worthwhile and possible to keep adapting it to the 
present. For example, the popular SMTP AUTH patch always felt hacky to 
me, so I finally wrote acceptutils 
(https://schmonz.com/qmail/acceptutils) to cohere with Russ's design for 
POP3 authentication. By matching the existing design, old programs 
gained new user-controlled features. And then I noticed I could easily 
handle TLS in acceptutils too (thanks to UCSPI-TLS in tcpserver) and get 
rid of the qmail-smtpd half of the popular TLS patch.

My plan to get rid of the other half is to break up qmail-remote, 
something like so:

- qmail-remoteip will do DNS lookups and determine where to connect
- qmail-remoteio is the SMTP client, reading stdin and writing stdout
- qmail-newremote matches the qmail-remote interface and coordinates the 
subprograms, running qmail-remoteio via tcpclient
- tcpclient can be ucspi-tcp6's tcpclient, or ucspi-ssl's sslclient
- sslclient will grow an UCSPI-TLS interface
- qmail-newremote will use UCSPI-TLS instead of the popular TLS patch
- Admins can choose qmail-newremote by applying a tiny QMAILQUEUE-like 
patch (https://schmonz.com/qmail/remote) and setting QMAILREMOTE to 
qmail-newremote

After that, my plan for outbound DKIM and SRS rounds into focus:

- qmail-rfilter (https://schmonz.com/qmail/rfilter) will be a lot like 
qmail-qfilter, but wrapping qmail-remote (or $QMAILREMOTE)
- DKIM signing is a Unix filter
- SRS rewriting for forwarded messages is a Unix filter
- Admins list them (or alternate implementations, or nothing) in 
control/remotefilters

For inbound accept/reject/tag decisions, I really like 
http://qmail-spp.sourceforge.net, and have published rejectutils 
(https://schmonz.com/qmail/rejectutils) that runs in that environment. 
For SPF, I use https://www.caputo.com/foss/qmail-spp-spf/.

Everything mentioned here is integrated into pkgsrc's qmail-run package, 
except for the stuff that doesn't exist yet :-)

I've deliberately avoided making my own fork; I like the design pressure 
of needing to produce small patches that will apply cleanly to an 
arbitrarily patched netqmail. If the handful of us who are still 
actively developing qmail-derived works don't come up with a way to join 
our efforts, I'll keep working on mine as time permits. I'm just hoping 
we can figure out how to put our heads together and make informed, 
conservative, consensus-driven changes the way you netqmail folks did.