Mailing List Archive

On 30 Jun 2019, at 16:56, Erwin Hoffmann wrote:

> I just realised, that qmail.org is dead, thus no IP address is
> associated with 'www.qmail.org':
>
> server can't find www.qmail.org: NXDOMAIN

Ouch. At least netqmail can still be found at http://netqmail.org,
though we'll have to wonder how much longer.

> Anybody still looking for qmail support may look at my s/qmail & co:
>
> https://www.fehcom.de/ipnet/djbware.html

In addition to supporting Dr. H's ongoing work, mine is here:
https://schmonz.com/qmail. Please consider drip-funding my efforts at
https://www.patreon.com/schmonz and/or hiring me for your qmail
consulting needs, including custom development.

- Amitai

On 30 Jun 2019, at 17:57, Amitai Schleier wrote:

> On 30 Jun 2019, at 16:56, Erwin Hoffmann wrote:
>
>> I just realised, that qmail.org is dead, thus no IP address is
>> associated with 'www.qmail.org':

I've mirrored a mirror and checked it into git:
https://github.com/schmonz/qmail.org

Here's my qmail.org-mirror mirror: http://qmailorg.schmonz.com/

If anyone has a known recent mirror directly from qmail.org, please me
know so I can compare (and catch up if needed).

Thanks,

- Amitai

On 2019-06-30 22:56+0200, Erwin Hoffmann wrote:
> I just realised, that qmail.org is dead, thus no IP address is
> associated with 'www.qmail.org':
>
> server can't find www.qmail.org: NXDOMAIN
>
> I don't know, whether this is a big loss - the information on this
> page was not updated anymore since years.

Mirror is still working:

<http://www.usenix.org.uk/mirrors/qmail/top.html>

Russell updated it a while back with a fix for delivered-to spam. I
think the main problem with the updates was when QMR fell out of
maintenance.

JMS patches still work ok, but AFAICS the only major pain points will be
as TLS versions moves forward.

It's a real shame that install laziness is winning as people opt for
Exim or Postfix.

--
Best regards,
Ed http://www.s5h.net/

On 1 Jul 2019, at 13:03, Ed wrote:

> Mirror is still working:
>
> <http://www.usenix.org.uk/mirrors/qmail/top.html>

Cool, that matches what I managed to fetch from another mirror. I guess
https://github.com/schmonz/qmail.org is up-to-date, then.

What if we turned this into a git-backed ikiwiki site, with full history
preserved, so those of us with motivation can continue maintaining it?
If there's interest and perceived benefit, I'll gladly host it.

> It's a real shame that install laziness is winning as people opt for
> Exim or Postfix.

Making qmail extremely easy to install, configure, and update has been
an explicit goal of my efforts, most notably these:

- rejectutils: https://schmonz.com/qmail/rejectutils
- acceptutils: https://schmonz.com/qmail/acceptutils
- pkgsrc qmail-run: https://schmonz.com/qmail/pkgsrc-qmail-run

Some comments I've gotten from users:

- "An awesome MTA finally has the awesome getting-started experience
that it deserves."
- "Damn, you made it easy to get this stuff up and running."

This blog post about my recent work includes a video demo of building,
installing, and starting qmail from source-based packages using pkgsrc
on Debian 9:
https://schmonz.com/2019/01/07/2018q4-qmail-updates-in-pkgsrc/ Needless
to say, it's even easier and faster on platforms for which pkgsrc
provides binary packages.

It's my hope that more folks who love qmail -- and more folks who might
try qmail if it were easy to try -- find their way to pkgsrc and its
qmail-run package. I've put a lot of care into it, and it would be
gratifying to hear more stories from people who are using and
appreciating it.
- Amitai

Hi,

thanks to all!

However, just maintaining the content of some outdated software repositories with a lot of broken links is certainly not enough.

We need fresh start! (and a maintainer).

Regards.
--eh.

BTW: The outage of qmail.org (Russel Nelson's site) and DJB seems to be orchestrated. DJB refers already to mirrors here:
http://cr.yp.to/qmail.html


> Am 01.07.2019 um 19:39 schrieb Amitai Schleier <schmonz@schmonz.com>:
>
> On 1 Jul 2019, at 13:03, Ed wrote:
>
>> Mirror is still working:
>>
>> <http://www.usenix.org.uk/mirrors/qmail/top.html>
>
> Cool, that matches what I managed to fetch from another mirror. I guess https://github.com/schmonz/qmail.org is up-to-date, then.
>
> What if we turned this into a git-backed ikiwiki site, with full history preserved, so those of us with motivation can continue maintaining it? If there's interest and perceived benefit, I'll gladly host it.
>
>> It's a real shame that install laziness is winning as people opt for
>> Exim or Postfix.
>
> Making qmail extremely easy to install, configure, and update has been an explicit goal of my efforts, most notably these:
>
> - rejectutils: https://schmonz.com/qmail/rejectutils
> - acceptutils: https://schmonz.com/qmail/acceptutils
> - pkgsrc qmail-run: https://schmonz.com/qmail/pkgsrc-qmail-run
>
> Some comments I've gotten from users:
>
> - "An awesome MTA finally has the awesome getting-started experience that it deserves."
> - "Damn, you made it easy to get this stuff up and running."
>
> This blog post about my recent work includes a video demo of building, installing, and starting qmail from source-based packages using pkgsrc on Debian 9: https://schmonz.com/2019/01/07/2018q4-qmail-updates-in-pkgsrc/ Needless to say, it's even easier and faster on platforms for which pkgsrc provides binary packages.
>
> It's my hope that more folks who love qmail -- and more folks who might try qmail if it were easy to try -- find their way to pkgsrc and its qmail-run package. I've put a lot of care into it, and it would be gratifying to hear more stories from people who are using and appreciating it.
> - Amitai
>

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

On 1 Jul 2019, at 18:44, Erwin Hoffmann wrote:

> However, just maintaining the content of some outdated software
> repositories with a lot of broken links is certainly not enough.
>
> We need fresh start! (and a maintainer).

I can think of only two ways we might arrive at an active and agreed
maintainer:

1. DJB announces progress on qmail 2
2. DJB names a successor

Maybe there are other ways. 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?

I don't know the answer to this question either, but I have some
educated guesses:

- We choose our own little group (like the folks who chose each other to
produce netqmail)
- Our starting point is the most recent netqmail
- Our revision control history is public (such as on GitHub), and our
commits are emailed to a public list (probably a new one for the
purpose)
- Our design discussions are public (such as on this list)
- Before changing or adding code, we ensure it's covered by automated
tests
- Before fixing a bug, we write a regression test
- On every push, automated tests are run in public and their results are
publicly available
- We ship the automated tests with the code, so users can run the tests
on their own systems
- Over time, automated tests cover more of the system and get run on
more and more platforms

Folks who have been part of open source projects, does this sound like
it could work? What would you change, add, remove, or otherwise suggest?

Folks who wish there were sufficiently authoritative updates to qmail:
does this sound like a development process you might be able to trust
and that might produce updates you'd want to track?

> BTW: The outage of qmail.org (Russel Nelson's site) and DJB seems to
> be orchestrated. DJB refers already to mirrors here:
> http://cr.yp.to/qmail.html

I don't think this is the case. The links to mirrored copies of the
qmail tarball have been there for many years, and the link to
www.qmail.org is still present.

On 7/2/2019 12:13 PM, Amitai Schleier wrote:
> On 1 Jul 2019, at 18:44, Erwin Hoffmann wrote:
>
>> However, just maintaining the content of some outdated software
>> repositories with a lot of broken links is certainly not enough.
>>
>> We need fresh start! (and a maintainer).
>
> I can think of only two ways we might arrive at an active and agreed
> maintainer:
>
> 1. DJB announces progress on qmail 2
> 2. DJB names a successor
>
DJB is not interested - hasn't been for years.

> Maybe there are other ways. 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?
>
> I don't know the answer to this question either, but I have some
> educated guesses:
>
I used qmail for many years, great program. When I began using 64 bit
Linux qmail was no longer viable for me. Now I use Postfix and Dovecot
because "it just works" and I never have to patch it.

I tried several times to install Erwin Hoffman's apparently very good
software but I couldn't understand the writings (I can't say manuals)
and so was never successful.

The best I can see is if you're good with qmail you should do something.
If you choose not to do something I'm pretty sure you're not going to
find any "new blood" ready to assemble new pieces from old.

Larry Weldon

Thus said Erwin Hoffmann on Sun, 30 Jun 2019 22:56:41 +0200:

> I don't know, whether this is a big loss - the information on this
> page was not updated anymore since years.

I think it's a loss. There were many good links that could only be found
there. Hopefully it can be recovered from one of the mirrors.

Andy
--
TAI64 timestamp: 400000005d1bb384

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.

On Tue, Jul 2, 2019, at 11:35 AM, Amitai Schleier wrote:
> Folks who have been part of open source projects, does this sound like
> it could work? What would you change, add, remove, or otherwise suggest?

Hi, Amitai!

That list looks great!

One addition to the list that I would suggest is to come up with a new name for the project. I'm not thrilled to suggest this, but I think that when the group of people put together netqmail, it was a help that they gave it a name and called it something other than qmail. (I also found it nice that they included "qmail" in the name to help clearly communicate what it is.) Once they did that, everyone could refer to it by name and know exactly what that meant (i.e., qmail + the listed patches).

Another addition to the list that I would suggest is to make it easy to configure (the build), build, and install. Doing all that by hand is a pain right now. You've done an excellent job of automating all of that with the pkgsrc qmail-run package, but obviously that requires using pkgsrc, and I worry that that is a big enough barrier to entry for some people that they won't consider it.

Even though I'm not a big fan of Autotools, being able to do "./configure && make && make install" is pretty convenient, and a lot of package management systems support it. If not actually Autotools, it could be an Autotools workalike. Or something else, even though not as standard as the Autotools interface, assuming it requires running just a few commands, would really be a big improvement.

This would also increase the chance of the software being included in other OS package repositories (e.g., Homebrew, RHEL, Ubuntu, Arch, Gentoo, Alpine, etc.) which would also be a big plus. It's certainly convenient for someone intending a production deployment, but it's also convenient for someone wishing to try it out.

It's also convenient for someone writing a tutorial. There are a number of tutorials on the Internet on how to install and configure software X on operating system Y. For example, DigitalOcean seems to host a number of these (not surprisingly since I assume they hope people will use their services for hosting), and a Google search (e.g., "how install postfix rhel") will often find them. When a tutorial author can write, e.g., "First, install Postfix: # yum install postfix", that's really easy compared to what they'd have to write without a binary package being available in the OS's package repository.

> Folks who wish there were sufficiently authoritative updates to qmail:
> does this sound like a development process you might be able to trust
> and that might produce updates you'd want to track?

Yes!

Regards,

Lewis

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.

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 <schmonz@schmonz.com>:
>
> 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

On 2019-07-03 22:06+0200, Erwin Hoffmann wrote:
> In short: We need a fresh start. Portability, scalability,
> performance, security, coverage, and easiness needed to be achieved
> (in arbitrary order).

I don't think a fresh start would do much good for those who trust the
architecture. I propose building on something like JMS1's combined patch
set. John was keen to prevent a stock script, like QMR which often
created unwise admins.

There is merit to John's approach. There is also merit to the feature
kitchen sink of postfix. I would like to help with efforts, but I
wouldn't want to help reinvent the wheel.

--
Best regards,
Ed http://www.s5h.net/

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
- 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 <feh@fehcom.de>
Enviado el: mi?rcoles, 3 de julio de 2019 22:07
Para: qmail <qmail@list.cr.yp.to>
CC: Amitai Schleier <schmonz@schmonz.com>
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:

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.

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 <schmonz@schmonz.com>:
>
> 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

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 <schmonz@schmonz.com>:
>>
>> 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

On 2019-07-03 21:28, J. Lewis Muir wrote:
>
> Another addition to the list that I would suggest is to make it easy
> to configure (the build), build, and install. Doing all that by hand
> is a pain right now. You've done an excellent job of automating all
> of that with the pkgsrc qmail-run package, but obviously that requires
> using pkgsrc, and I worry that that is a big enough barrier to entry
> for some people that they won't consider it.
>
pkgsrc _is_ a big barrier on systems other than NetBSD.

> Even though I'm not a big fan of Autotools, being able to do
> "./configure && make && make install" is pretty convenient, and a lot
> of package management systems support it. If not actually Autotools,
> it could be an Autotools workalike. Or something else, even though
> not as standard as the Autotools interface, assuming it requires
> running just a few commands, would really be a big improvement.
>
eQmail uses the "./configure && make && make install" way already. Even
if it not uses autotools or a similar framework. It is very simple
implementation.

> This would also increase the chance of the software being included in
> other OS package repositories (e.g., Homebrew, RHEL, Ubuntu, Arch,
> Gentoo, Alpine, etc.) which would also be a big plus. It's certainly
> convenient for someone intending a production deployment, but it's
> also convenient for someone wishing to try it out.
>
As a Gentoo user I have an ebuild for that in my overlay. But at least I
can (and want to) do the packagers job for Gentoo only, beside some (to
me) questionable things from the Gentoo upstream.

> tutorial author can write, e.g., "First, install Postfix: # yum
> install postfix", that's really easy compared to what they'd have to
> write without a binary package being available in the OS's package
> repository.
Again, to be able to use 'yum' - this should be the work of packagers.

>
> Lewis

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

On Jul 5, 2019, at 7:58 AM, Kai Peter <kp@lists.openqmail.org> wrote:
>> On 2019-07-03 21:28, J. Lewis Muir wrote:
>> tutorial author can write, e.g., "First, install Postfix: # yum
>> install postfix", that's really easy compared to what they'd have to
>> write without a binary package being available in the OS's package
>> repository.
> Again, to be able to use 'yum' - this should be the work of packagers.

Yes, agreed; I’m just saying that having an easy configure (of the build), build, and install would make it more likely to be packaged for other package management systems and therefore easier to install on more OSes and easier to document for those OSes.

Regards,

Lewis

On 2 Jul 2019, at 15:41, Andy Bradford wrote:

> Thus said Erwin Hoffmann on Sun, 30 Jun 2019 22:56:41 +0200:
>
>> I don't know, whether this is a big loss - the information on
>> this
>> page was not updated anymore since years.
>
> I think it's a loss. There were many good links that could only be
> found
> there. Hopefully it can be recovered from one of the mirrors.

From Russ (again, off-list but public): "It's not *down* down, it's
just a four hour drive away from me now. I'll get to it."

In the meantime, Ed's mirror is one that's up-to-date:
http://www.usenix.org.uk/mirrors/qmail/top.html