RE: qmail.org DEAD?

Hello World!

Qmail is still alive and I would like it to continue for many years.
The cloud, the cloud, everything to the cloud. Let's claim that you can
compete against gmail and microsoft MTA servers, why and how.
I have been using qmail since 15 years ago. I've already mentioned it. =
My
development line was Qmail-LDAP starting from
qmail-ldap-1.03-20060201.patch.gz. Since then I have been applying the
different functionalities and patches that I have considered like SPF,
QMAILQUEUE, domainalias, bigquota, Greetdelay, DKIM and some others own.

It's true that I've always missed an integral solution that includes all
mail solution components. Qmail is one of them.
In a mail server solution. You (me) need
- MTA -> Qmail-LDAP with High availability (Qmail-cLuster)
- IMAP -> CourierIMAP
- Backend Users -> OpenLDAP <--> Not Vpopmail -- Not MySQL
- SSL / TLS -> OpenSSL (1.2)
- API Management users -> Own API Perl - LDAP <--> Not Vpopmail=20
- Antivirus -> Simscan tunned
- AntiSpam -> Spamassassin
- MailFilter --> Maildrop
- Scripting for statistics
- Backup
- Webmail Mailbox Access (HTTP/S) -> Own development
- Unix Service Management -> Daemontools
- TCP Client-Server API -> ucspi-tcp

The most similar reference I have found is https://notes.sagredo.eu/
The ideal would be to centralize all ideas inside a web like this (this =
or
other), although you, the bosses, have to agree on the main line of =
work.
Just that you know that there are many email administrators like me, =
that we
follow you and that we value your effort.

Regards.




-----Mensaje original-----
De: Erwin Hoffmann <[email protected]>=20
Enviado el: mi=E9rcoles, 3 de julio de 2019 22:07
Para: qmail <[email protected]>
CC: Amitai Schleier <[email protected]>
Asunto: 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).


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