Re: qmail.org DEAD?

Hi,

it is nice to see what Amitai and Erwin did and plan for the future. 
Unfortunately non fits my needs and expectations. Just some examples:

eQmail has:
- Vermeulens TLS patch - no need for sslserver
- tcpserver is included (forked) - no need for ucspi-* in general
- SPF (qmail-spp plugin) and DKIM (libdkim forked) is fully functional - 
no need for another solution (Erwin did create a different SPF solution 
later on)
- it's own boot scripts (the client PID identification for tcpserver is 
solved) which fits to sysvinit - no need for daemontools

Just some, there are more. All is one consistent package plus some 
plugins. KISS, no patch anarchy.

Even if I will never switch to another MTA, there is the main question: 
Is it really worth the effort to invest into *qmail?

In general I'm open for new ideas and I want to make progress. So I want 
improve things and throw away old (unusable/unneeded/outdated) stuff. 
Like djb, I question - even existing - things. Today it seems we have a 
*qmail forks (private and public ones) flood - is this not the same as 
the patch anarchy in the past, isn't it?

If we answer the 'question of sense' positiv, how can we come together 
and coordinate the work? IMHO the first thing is that a council/lead is 
required and its decisions have to be accepted. But who is authority? 
How to come together as an upstream organization? I enjoy the work with 
Erwin but to be honest, there are big disagreements and differences. 
This prevents me to go forward as well (e)qmail is not the most 
important thing (project) in my life.

Again, to me a coordination and a (real) roadmap would be the most 
important requirement. Not individual duplicate solutions with 99 
percent identity of DKIM, SPF, TLS, Auth and so on. The correct way is 
in the middle always. Compromises have to be found. Is this possible? 
How does other opensource projects work? Could we adapt best practices 
from them? A lot of questions ...

Kai


On 2019-07-03 22:06, Erwin Hoffmann wrote:
> 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:
> 
> 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:
> 
> 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.
> qmail-1.03 does even not compile on recent OS without patching.
At the moment I'm only aware of the 'errno' issue, but this doesn't 
require patching.

> 
> 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).
> Over the years, I tried to incorporate most to the lacking features;
> in particular Anti-Spam and Virus checking (Spamcontrol).
> 
> 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'.
> 
> 
> In short: We need a fresh start. Portability, scalability,
> performance, security, coverage, and easiness needed to be achieved
> (in arbitrary order).
> 
> 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.
> 
> 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.
> 
> Probably, these sentences were again unreadable, thus I rather shut my 
> mouth :-)
> 
> Regards.
> --eh.
> 
> 
> 
>> Am 03.07.2019 um 17:42 schrieb Amitai Schleier <[email protected]>:
>> 
>> 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.
>> 
> 
> Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id 
> 7E4034BE

-- 
Sent with eQmail-1.10.3 beta - a fork of djb's famous qmail