Re: qmail.org DEAD?

Hi together,

I know, my docs are unreadable; but I share this with Exim and Postfix =
;-)


Let's talk about the bottom line:

a) qmail architecture:=20

Best ever. DJB explained that in "Some thoughts on security after ten =
years of qmail 1.0". We should be conservative here and shall stuck to =
those principles.

b) qmail coding:=20

Has been developed since then; look at ucspi-tcp and djbdns. Starting =
from Kai Peter's qlibs, I made an attempt to modernise those; including =
IPv6 and a DNS stub resolver while making it portable to almost any HW =
platform and OS. Felix von Leitner (fefe) did the same approach =
(https://www.fefe.de/djb/). qmail's DNS stub resolver is still pre =
ucspi-tcp and in particular bad.=20
qmail-1.03 does even not compile on recent OS without patching.=20

c) qmail scope:

qmail-1.03 is simple (E)SMTP; it lacks all modern features (Auth, TLS, =
SPF, DKIM, DANE, ....). It is simply not usable anymore as MTA today =
(apart from using it in a restricted environment).=20
Over the years, I tried to incorporate most to the lacking features; in =
particular Anti-Spam and Virus checking (Spamcontrol).=20

d) qmail installation:

Though it is easy, i receive complains about hard-coded UID; the queue =
is fixed to the local filesystem (inodes).
My slashpackage attempt for s/qmail may not be appropriate for system =
administrators expecting an 'apt install (s/)qmail'.=20


In short: We need a fresh start. Portability, scalability, performance, =
security, coverage, and easiness needed to be achieved (in arbitrary =
order).=20

Probably within the next months, I will release s/qmail based on my =
fehQlibs which are already now the base of the current ucspi-tcp6, =
ucspi-ssl and djbdnscurve6. The latter providing interfaces for =
OpenSSL/LibreSSL and NaCL/libsodium.=20

However, we need to match the expectations of the community and =
capabilities of the developers providing a mature product. This was =
certainly lacking the last two centuries.=20

Probably, these sentences were again unreadable, thus I rather shut my =
mouth :-)

Regards.
--eh.=20



> Am 03.07.2019 um 17:42 schrieb Amitai Schleier <[email protected]>:
>=20
> On 2 Jul 2019, at 12:13, Amitai Schleier wrote:
>=20
>> 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?
>=20
> A couple updates, both off-list but public:
>=20
> 1. Russ Nelson wasn't aware that qmail.org had gone nxdomain, and said =
he'd take a look.
>=20
> 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:
>=20
> -----
>=20
> 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.
>=20
> My plan to get rid of the other half is to break up qmail-remote, =
something like so:
>=20
> - 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
>=20
> After that, my plan for outbound DKIM and SRS rounds into focus:
>=20
> - 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
>=20
> 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/.
>=20
> Everything mentioned here is integrated into pkgsrc's qmail-run =
package, except for the stuff that doesn't exist yet :-)
>=20
> 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.
>=20

Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id 7E4034BE