Mailing List Archive

On Thu, 5 Aug 2021 at 01:36, Erwin Hoffmann <feh@fehcom.de> wrote:
>
> Hi together,
>
> it has been a while that people announce new developments here on this
> list or report bugs/features.
>
> Altough, Sysadmin day is one week back, I would like to introduce
>
> - sqmail-4.1.10
>
> here together with my other 'djbware' including fehQlibs-18 and
> djbdnscurve-38.
>
> Starting with the 4.1 release, integration of SMTP mail and DNS is
> getting tighter: TLSA/DANE lookup is supported by qmail-remote and
> provided by tinydns on the server side. The forthcoming releases will
> allow native DKIM support on both ends.
>
> I encourage everybody to go for a trial and get accustomed to both.
> Compatibility with your settings is given; though certainly
> enhancements like IPv6 require some careful inspections and
> adjustments.
>

Good work. I took a look and noticed that you used libsodium, instead
of the packaged nacl library. I tried the same for dnscurve and it
solved my compilation issue on Darwin.

I keep learning from your projects.

--
Regards Manvendra - http://www.indimail.org
GPG Pub Key
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC7CBC760014D250C

Hi Manvenda,

thanks for your warm words. It would be really good to focus on a single
qmail descendent. It seems, neither Kai Peter nor me do have time to really
pick up the loose ends and put together what was initiated as 'aqmail'.

Let me give you (and all who are interested) some outlook based on my ideas
and experiences:

a) Given s/qmail, openqmail and notqmail, the APIs are still the same, thoug
the coding foundation is already significant different: DJBs old style,
Qlibs and fehQlibs in may case. However merging Kai's and mine development
into a single Git tree (let's say starting from s/qmail + fehQlibs) would be
feasible and would provide the path for a community driven project.

b) Further differences arise from the TLS implementation, the use of qmail-
spp for SMTP user validation and in case of s/qmail the DNS backend (now
based on fehQlibs and djbdnscurve6). It is clear, that in the later case,
Dan would like to get rid of the Bind APIs still present in notqmail and
openqmail.

c) Currently, s/qmail includes the libsrs, which needs to be re-written and
will I need to go for the libdkim (provided in C++) support as well.

d) DJB has provided an add-on for OpenSSL(https://opensslntru.cr.yp.to)
providing post-quantum hardening for the TLS handshake. Together with
libdkim, I would like to get rid of the standard TLS libraries and use DJB's
ones. For ucspi-ssl I plan integration of those.

Given these developments, s/qmail (or aqmail or whatever) would be a real
alternative on the market, in case the project is picked up by a qualified
integration (pkgsrc, pacman etc.). Though s/qmail uses DJB's slashpackage
conventions, there should be a more smarter way and in case of a package
integration becomes obsolete.

e) What left (from my point of view) is an improvement on qmail's delivery
channels: Pipelining for qmail-remote and encryption support for
authenticated users. These are rough thoughts so ;-)

TLDR; for those who still with me, here are two links:

- https://www.usenix.org/conference/usenixsecurity21/presentation/poddebniak
- https://nostarttls.secvuln.info


Regards.
--eh.


On Wed, 11 Aug 2021 22:24:24 +0530, Manvendra Bhangui <mbhangui@gmail.com>
wrote :

> On Thu, 5 Aug 2021 at 01:36, Erwin Hoffmann <feh@fehcom.de> wrote:
> >
> > Hi together,
> >
> > it has been a while that people announce new developments here on this
> > list or report bugs/features.
> >
> > Altough, Sysadmin day is one week back, I would like to introduce
> >
> > - sqmail-4.1.10
> >
> > here together with my other 'djbware' including fehQlibs-18 and
> > djbdnscurve-38.
> >
> > Starting with the 4.1 release, integration of SMTP mail and DNS is
> > getting tighter: TLSA/DANE lookup is supported by qmail-remote and
> > provided by tinydns on the server side. The forthcoming releases will
> > allow native DKIM support on both ends.
> >
> > I encourage everybody to go for a trial and get accustomed to both.
> > Compatibility with your settings is given; though certainly
> > enhancements like IPv6 require some careful inspections and
> > adjustments.
> >
>
> Good work. I took a look and noticed that you used libsodium, instead
> of the packaged nacl library. I tried the same for dnscurve and it
> solved my compilation issue on Darwin.
>
> I keep learning from your projects.
>
> --
> Regards Manvendra - http://www.indimail.org
> GPG Pub Key
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC7CBC760014D250C
>
>
>

--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/

On Thu, 12 Aug 2021 at 00:36, Erwin Hoffmann <feh@fehcom.de> wrote:

Just my two cents.

> c) Currently, s/qmail includes the libsrs, which needs to be re-written and
> will I need to go for the libdkim (provided in C++) support as well.
>
I have been using libdkim since 2009. My qmail-dkim is based on it.
Over the years, I have found it full of bugs. The biggest problem was
the dns resolution. Ultimately, I replaced it with the dns_txt from
dns.c from qmail. It is in C++ and there are plenty of places where
there is no proper error handling. All the bug fixes I have done is
available here https://github.com/mbhangui/indimail-mta/tree/master/libdkim-x


> d) DJB has provided an add-on for OpenSSL(https://opensslntru.cr.yp.to)
> providing post-quantum hardening for the TLS handshake. Together with
> libdkim, I would like to get rid of the standard TLS libraries and use DJB's
> ones. For ucspi-ssl I plan integration of those.
>
Interesting

> Given these developments, s/qmail (or aqmail or whatever) would be a real
> alternative on the market, in case the project is picked up by a qualified
> integration (pkgsrc, pacman etc.). Though s/qmail uses DJB's slashpackage
> conventions, there should be a more smarter way and in case of a package
> integration becomes obsolete.
>

djb has done plenty good. slashpackage however will never pick up
IMHO. Package management systems form the major vendors (the major
ones RPM and APT hold the roost). With something like RPM, where you
can even specify permissions for every individual file, automate the
entire installation and make it easy for the casual user.

I have been busy with a few things.

1. qmta-send - I have combined qmail-send.c, qmail-lspawn.c,
qmail-rspawn.c, qmail-clean.c in a single executable. You lose the 3
way trust partitioning, but the setup because a lot easier with fewer
executables and fewer entries in /etc/passwd. This package allows a
full functional system with just 9 binaries.
2. slowq-send - rate limited qmail-send which allows any mathematical
expression for a target domain, to set the delivery rates and make
delivery to yahoo.com and other sites friendly.
3. daemontools - make it docker / podman friendly. Made changes to
svscan to make it a functional init system. It can now run as PID 1
and reap children not forked by it. It can also use /run file system
and work even if the your /service, etc is read-only. I'm so fed up
with the bloatware known as systemd that I am making svscan work
nicely with openrc (from gentoo). Also it works nicely with dnscache
and mounts it's own resolv.conf pointing to dnscache for all services
supervised under it. I made minor changes like a SIGCHLD handler and
using sigaction to set the handler. The original svscan is slow to
reap children, taking a full 5 seconds to do that.
4. libqmail: A common library for qmail (indimail-mta), ezmlm,
tinydnssec, daemontools, ucspi-tcp and almost every project that I
write for myself.

> e) What left (from my point of view) is an improvement on qmail's delivery
> channels: Pipelining for qmail-remote and encryption support for
> authenticated users. These are rough thoughts so ;-)
>

Looking forward to your qmail delivery channels

On Wed, Aug 11, 2021, at 2:06 PM, Erwin Hoffmann wrote:
> a) Given s/qmail, openqmail and notqmail, the APIs are still the same, thoug
> the coding foundation is already significant different: DJBs old style,
> Qlibs and fehQlibs in may case. However merging Kai's and mine development
> into a single Git tree (let's say starting from s/qmail + fehQlibs) would be
> feasible and would provide the path for a community driven project.

Hi, Erwin!

You've been no slouch with the work you've put into s/qmail, but it's not a community-driven project. Please correct me if I'm wrong, though; I'm not particularly familiar with s/qmail. I'm also well aware that most projects don't start out as community-driven projects, so I'm not intending to knock s/qmail in any way; I think you've done impressive work; I'm only trying to state the status of the project in this area.

As far as openQmail is concerned, I don't know anything about it, but the last commit on its GitHub page is from May 4, 2018, so it feels abandoned to me. Also, judging from the contributors list on the GitHub page (i.e., one person), it is not a community-driven project.

From your list, that leaves notqmail which, IMO, *is* a community-driven project. It's pretty young, started in mid-2019, some might even say it's a fledgling project, but its GitHub page lists seven contributors, and it's actively developed (the last commit was three days ago). The notqmail project has gone to great lengths to not make changes that would break existing qmail patches so as to not alienate anyone maintaining such patches. The intention is for notqmail to be an attractive option to switch to from qmail since patches should apply with little or no effort.

This is all to say that, to me, notqmail seems like the best choice for a solid community-driven project to gather around rather than thinking about trying to create yet another project to do similar things.

Kind regards,

Lewis

On Thu, 12 Aug 2021 at 23:29, Manvendra Bhangui <mbhangui@gmail.com> wrote:

> using sigaction to set the handler. The original svscan is slow to
> reap children, taking a full 5 seconds to do that.

I'm wrong about this. The original svscan doesn't have any problems.
It was my own previous version that had this problem.

Hi Lewis,

I'm with you with almost all of your points. And I'm also unhappy given the
current situation. Further, Manvendra, Amitai, Kai Peter and me are in close
contact; as you have seen from the reply to my initial thread.

In fact, Qmail is now > 20 ys 'on the market' and of course things have
changed a lot since then. While notqmail is focusing on the legacy
installation base, s/qmail considers itself more security-aware including
current features (except DKIM yet; which is not easy to accommodate for in
the qmail context).

Kai Peter an me tried to start 'aqmail' as a open and community project, but
- as I said - we are lacking simply time resources.

Unlike Postfix (Vienne) and Exim (Phil) we don't have a 'beloved dictator'
here to provide some guideline. Neither do we have a 'roadmap' for features;
nor a commonly accepted development pipeline (CI) or a deployment
procedure/packaging.

'20 years running Qmail' should tell us, that we need some code refreshments
from the base. Here, Kai, Manvendra, Fefe, skalibs, nemostar ... provide
current alternatives with different intentions: IPv6, strong typisation,
djbdns, ....

In short, on that detail level, things become quite complicated. Volunteers
required. Remember: Most if not all of Qmail decendents are public domain as
well.

Regards.
--eh.




On Thu, 12 Aug 2021 15:27:03 -0500, "J. Lewis Muir" <jlm@muirhq.com> wrote :

> On Wed, Aug 11, 2021, at 2:06 PM, Erwin Hoffmann wrote:
> > a) Given s/qmail, openqmail and notqmail, the APIs are still the same,
thoug
> > the coding foundation is already significant different: DJBs old style,
> > Qlibs and fehQlibs in may case. However merging Kai's and mine
development
> > into a single Git tree (let's say starting from s/qmail + fehQlibs)
would be
> > feasible and would provide the path for a community driven project.
>
> Hi, Erwin!
>
> You've been no slouch with the work you've put into s/qmail, but it's not
a community-driven project. Please correct me if I'm wrong, though; I'm not
particularly familiar with s/qmail. I'm also well aware that most projects
don't start out as community-driven projects, so I'm not intending to knock
s/qmail in any way; I think you've done impressive work; I'm only trying to
state the status of the project in this area.
>
> As far as openQmail is concerned, I don't know anything about it, but the
last commit on its GitHub page is from May 4, 2018, so it feels abandoned to
me. Also, judging from the contributors list on the GitHub page (i.e., one
person), it is not a community-driven project.
>
> From your list, that leaves notqmail which, IMO, *is* a community-driven
project. It's pretty young, started in mid-2019, some might even say it's a
fledgling project, but its GitHub page lists seven contributors, and it's
actively developed (the last commit was three days ago). The notqmail
project has gone to great lengths to not make changes that would break
existing qmail patches so as to not alienate anyone maintaining such
patches. The intention is for notqmail to be an attractive option to switch
to from qmail since patches should apply with little or no effort.
>
> This is all to say that, to me, notqmail seems like the best choice for a
solid community-driven project to gather around rather than thinking about
trying to create yet another project to do similar things.
>
> Kind regards,
>
> Lewis
>
>
>

--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/

Good Morning Manvendra, (not forgetting the 'r'),


On Thu, 12 Aug 2021 23:29:55 +0530, Manvendra Bhangui <mbhangui@gmail.com>
wrote :


>
> I have been busy with a few things.
>
> 1. qmta-send - I have combined qmail-send.c, qmail-lspawn.c,
> qmail-rspawn.c, qmail-clean.c in a single executable. You lose the 3
> way trust partitioning, but the setup because a lot easier with fewer
> executables and fewer entries in /etc/passwd. This package allows a
> full functional system with just 9 binaries.
> 2. slowq-send - rate limited qmail-send which allows any mathematical
> expression for a target domain, to set the delivery rates and make
> delivery to yahoo.com and other sites friendly.
> 3. daemontools - make it docker / podman friendly. Made changes to
> svscan to make it a functional init system. It can now run as PID 1
> and reap children not forked by it. It can also use /run file system
> and work even if the your /service, etc is read-only. I'm so fed up
> with the bloatware known as systemd that I am making svscan work
> nicely with openrc (from gentoo). Also it works nicely with dnscache
> and mounts it's own resolv.conf pointing to dnscache for all services
> supervised under it. I made minor changes like a SIGCHLD handler and
> using sigaction to set the handler. The original svscan is slow to
> reap children, taking a full 5 seconds to do that.
> 4. libqmail: A common library for qmail (indimail-mta), ezmlm,
> tinydnssec, daemontools, ucspi-tcp and almost every project that I
> write for myself.
>

While my development machine is FreeBSD (13); as you can see I've moved from
MacOS to Linux on the desktop (running Atrix Linux with runit; fine).

Yeah, systemD is a pain in the neck. I have a student project providing
Docker images for s/qmail services. Let's see.

Regarding your libdkim, I will have a look. I was already shocked about the
bad quality of libsrs and I assumed that libdkim is not much better. Thats
why I has hesitating to go for it without a good alternative. Sigh.


> > e) What left (from my point of view) is an improvement on qmail's
delivery
> > channels: Pipelining for qmail-remote and encryption support for
> > authenticated users. These are rough thoughts so ;-)
> >
>
> Looking forward to your qmail delivery channels

Again, this idea is almost now a decade old, when I was security advertiser
for a the new version of Germany's 'Epost' system; never came into
production.

I guess, you follow the other discussion here.

Regards.
--eh.

--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/

Lewis,

let me kick in here not as a developer but as a user.

I've been using qmail since the previous century now.
Qmail was our thing because it was stable, fast, and easy to configure.
We are a webhosting company, so we build a little webinterface where
users could manage dot-qmail-files for their domains.

As years went by, email changed a lot. Attachment grew, autoreply's
where needed, spamming and virusses came on the seen. Resulting in more
and more patches needed to the original Qmail.
About 15 years ago we tried several anti-spam programs like Spamassasin
and some qmail-patches.
Eventually we ended up with the assp-proxy for handling spam.

In 2016 we needed several new servers and as the original Qmail was dead
we searched for replacements.
We tried the eQmail from Kai, Indimail from Manvendra but both of them
where to difficult to integrate with our current backoffices.
Eventually we ended up with s/Qmail which was a perfect match.
It's very close to the original Qmail and has everything what is needed
for a MTA. Install and forget it.

There is really no need at all for all software to be community-driven.
Especially when it's something like a MTA. I see this as
"core-software", which is not a growing package but finished at one time.
IMHO s/Qmail has reached this point.

Personally I'm a little bit concerned about the latest developments like
greylisting, SPF-checks etc.
These antispam thing change very quickly, and before you know it you end
up with the a terrible scheme where everything is connected and you get
a spaghetti-coded program.
See assp itself for this. I have now 1139 lines in my assp.cfg and it's
becoming scary to update, as one wrong option could end up with many
false positive or negatives.

It should however be great that all these extra option should be
optional. As some of our servers act only as a mailinglist or secondary
MX there is no need for SPF-checks or greylisting there.
Allthough there are things which can only exists in the core itself like
SRS and DKIM.

So IMHO there is no need for a new qmail-alternative. s/Qmail is stable
and does what it need to do.
Hopefully it will be included once in all the linux-flaws, let's start
with Debian :-)


Best regards,
Pascal




Op 13/08/2021 om 07:28 schreef Erwin Hoffmann:
> Hi Lewis,
>
> I'm with you with almost all of your points. And I'm also unhappy given the
> current situation. Further, Manvendra, Amitai, Kai Peter and me are in close
> contact; as you have seen from the reply to my initial thread.
>
> In fact, Qmail is now > 20 ys 'on the market' and of course things have
> changed a lot since then. While notqmail is focusing on the legacy
> installation base, s/qmail considers itself more security-aware including
> current features (except DKIM yet; which is not easy to accommodate for in
> the qmail context).
>
> Kai Peter an me tried to start 'aqmail' as a open and community project, but
> - as I said - we are lacking simply time resources.
>
> Unlike Postfix (Vienne) and Exim (Phil) we don't have a 'beloved dictator'
> here to provide some guideline. Neither do we have a 'roadmap' for features;
> nor a commonly accepted development pipeline (CI) or a deployment
> procedure/packaging.
>
> '20 years running Qmail' should tell us, that we need some code refreshments
> from the base. Here, Kai, Manvendra, Fefe, skalibs, nemostar ... provide
> current alternatives with different intentions: IPv6, strong typisation,
> djbdns, ....
>
> In short, on that detail level, things become quite complicated. Volunteers
> required. Remember: Most if not all of Qmail decendents are public domain as
> well.
>
> Regards.
> --eh.
>
>
>
>
> On Thu, 12 Aug 2021 15:27:03 -0500, "J. Lewis Muir" <jlm@muirhq.com> wrote :
>
>> On Wed, Aug 11, 2021, at 2:06 PM, Erwin Hoffmann wrote:
>>> a) Given s/qmail, openqmail and notqmail, the APIs are still the same,
> thoug
>>> the coding foundation is already significant different: DJBs old style,
>>> Qlibs and fehQlibs in may case. However merging Kai's and mine
> development
>>> into a single Git tree (let's say starting from s/qmail + fehQlibs)
> would be
>>> feasible and would provide the path for a community driven project.
>>
>> Hi, Erwin!
>>
>> You've been no slouch with the work you've put into s/qmail, but it's not
> a community-driven project. Please correct me if I'm wrong, though; I'm not
> particularly familiar with s/qmail. I'm also well aware that most projects
> don't start out as community-driven projects, so I'm not intending to knock
> s/qmail in any way; I think you've done impressive work; I'm only trying to
> state the status of the project in this area.
>>
>> As far as openQmail is concerned, I don't know anything about it, but the
> last commit on its GitHub page is from May 4, 2018, so it feels abandoned to
> me. Also, judging from the contributors list on the GitHub page (i.e., one
> person), it is not a community-driven project.
>>
>> From your list, that leaves notqmail which, IMO, *is* a community-driven
> project. It's pretty young, started in mid-2019, some might even say it's a
> fledgling project, but its GitHub page lists seven contributors, and it's
> actively developed (the last commit was three days ago). The notqmail
> project has gone to great lengths to not make changes that would break
> existing qmail patches so as to not alienate anyone maintaining such
> patches. The intention is for notqmail to be an attractive option to switch
> to from qmail since patches should apply with little or no effort.
>>
>> This is all to say that, to me, notqmail seems like the best choice for a
> solid community-driven project to gather around rather than thinking about
> trying to create yet another project to do similar things.
>>
>> Kind regards,
>>
>> Lewis
>>
>>
>>
>

On Fri, 13 Aug 2021 at 12:32, Erwin Hoffmann <feh@fehcom.de> wrote:

> Regarding your libdkim, I will have a look. I was already shocked about the
> bad quality of libsrs and I assumed that libdkim is not much better. Thats
> why I has hesitating to go for it without a good alternative. Sigh.
>

you could check the opendkim project. http://www.opendkim.org/. I'm
going to take a look at it some day and if possible replace libdkim
with that.

On Fri, Aug 13, 2021, at 12:28 AM, Erwin Hoffmann wrote:
> In fact, Qmail is now > 20 ys 'on the market' and of course things have
> changed a lot since then. While notqmail is focusing on the legacy
> installation base, s/qmail considers itself more security-aware including
> current features (except DKIM yet; which is not easy to accommodate for in
> the qmail context).

Hi, Erwin!

I can see your point of view for all your points; thank you for sharing them!

There is one point, though, that I'd like to clarify just a little bit, and that is on the focus of notqmail. You said notqmail's focus is on the legacy installation base, but I'd like to say that while that is true, it's not the only focus. Maybe I misunderstood your point, but to be clear, by no means does the notqmail project intend to be stuck in the past. If you look at the project's Feature Wishlist

https://github.com/notqmail/notqmail/wiki/Feature-Wishlist

, you will see that indeed it aspires to support all the features of a modern email system.

Kind regards,

Lewis

Hi Lewis,

On Fri, 13 Aug 2021 07:54:44 -0500, "J. Lewis Muir" <jlm@muirhq.com> wrote :

>
> Hi, Erwin!
>
> I can see your point of view for all your points; thank you for sharing
them!
>
> There is one point, though, that I'd like to clarify just a little bit,
and that is on the focus of notqmail. You said notqmail's focus is on the
legacy installation base, but I'd like to say that while that is true, it's
not the only focus. Maybe I misunderstood your point, but to be clear, by
no means does the notqmail project intend to be stuck in the past. If you
look at the project's Feature Wishlist
>
> https://github.com/notqmail/notqmail/wiki/Feature-Wishlist
>
> , you will see that indeed it aspires to support all the features of a
modern email system.

I know that list ;-) Let's have a look and check:

* SMTP recipient validation - done by s/qmail: qmail-vmailuser (vpopmail,
vmailmgr); Recipients extension (since > 15 ys)
* TLS - done; TLS 1.3 supported together with multitenancy, TLSA lookup,
Cert pinning etc. (CRL + OCSP missing though) X.509 Client auth
* AUTH - done: qmail-authuser (incl. vpopmail, vmailmgr, Dovecot), qmail-
ldapam coming soon (available as PERL module though)
* IPv6 - done: incl. LLU capabilities
* SPF - done: natively provided by qmail-smtpd (incl. IPv6/CIDR)
* SRS - done qmail-srsforward/reverse modules
* DKIM - scheduled
* DMARC - not clear
* EAI - done
* SNI - do we need that?

Peter Gabriel would say: 'So what?'

s/qmail provides for all of those cases a DJB-code based reference solution.
We are not starting from 'Ground Zero'. Most of the work has been done
already. It seems, people try to reinvent the wheel several times.

Pls. check s/qmail's web site for other enhancements. There are plenty more.
The s/qmail source has a size of 350 KByte (tar archive).

Regards.
--eh.

--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/

On 13 Aug 2021, at 12:32, Erwin Hoffmann wrote:

> s/qmail provides for all of those cases a DJB-code based reference
> solution.
> We are not starting from 'Ground Zero'. Most of the work has been done
> already. It seems, people try to reinvent the wheel several times.

I know you know, but others here might not be aware how much I
appreciate your work. I've been relying on ucspi-ssl and ucspi-tcp6 for
production systems for years. And though I haven't yet tried s/qmail
myself, the longstanding existence and ongoing development of such a
full-featured ready-to-run qmail-derived system is a big reason why
there's room for a project like notqmail to try alternative approaches,
even when they might take a while to realize.

If it were a competition, no question, s/qmail is way out in front. But
I think our projects being active and distinct is mutually beneficial to
us, as well as to other folks who are still financially and/or
emotionally invested in qmail.

Thank you again, as always, and keep up the good work. We'll try to do
the same. :-)

- Amitai

Hi Amitai,


On 13 Aug 2021 15:13:44 -0400, "Amitai Schleier" <schmonz@schmonz.com> wrote
:

> On 13 Aug 2021, at 12:32, Erwin Hoffmann wrote:
>
> > s/qmail provides for all of those cases a DJB-code based reference
> > solution.
> > We are not starting from 'Ground Zero'. Most of the work has been done
> > already. It seems, people try to reinvent the wheel several times.
>

don't worry .... No competition; you know. s/qmail was born out of
completely different arrangement, adjusting qmail in the field to
accommodate with large customer's requirements (called Spamcontrol patch).
I started development of s/qmail (and the other IPv6 enhanced DJB products)
as a academic project teaching students IPv6 capabilities, good coding
principles, and efficiency.

Since the spirit and the code base is pretty much the same as notqmail,
simply take what you believe is worthwhile. Adjust it to your needs. Perhaps
my UI with the many '|' pipes seams inappropriate; change it!

This is it. Everybody is invited to contribute. There is nobody to blame
taking a different direction or even move slower.

Thanks for your contribution, Amitai. Thanks to the NetBSD community to
support me as well and occasionally point me towards the correct solution.
We mutually benefit from each other.

Fortunately today, the remaining Qmail community has now the choice of
several qmail substitutes adjusted for the current OSes and working well.

Best regards.
--eh.


> I know you know, but others here might not be aware how much I
> appreciate your work. I've been relying on ucspi-ssl and ucspi-tcp6 for
> production systems for years. And though I haven't yet tried s/qmail
> myself, the longstanding existence and ongoing development of such a
> full-featured ready-to-run qmail-derived system is a big reason why
> there's room for a project like notqmail to try alternative approaches,
> even when they might take a while to realize.
>
> If it were a competition, no question, s/qmail is way out in front. But
> I think our projects being active and distinct is mutually beneficial to
> us, as well as to other folks who are still financially and/or
> emotionally invested in qmail.
>
> Thank you again, as always, and keep up the good work. We'll try to do
> the same. :-)
>
> - Amitai
>
>
>

--
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/

Well said, Amitai!

John

Amitai Schleier writes:
> On 13 Aug 2021, at 12:32, Erwin Hoffmann wrote:
>
> > s/qmail provides for all of those cases a DJB-code based reference
> > solution.
> > We are not starting from 'Ground Zero'. Most of the work has been done
> > already. It seems, people try to reinvent the wheel several times.
>
> I know you know, but others here might not be aware how much I
> appreciate your work. I've been relying on ucspi-ssl and ucspi-tcp6 for
> production systems for years. And though I haven't yet tried s/qmail
> myself, the longstanding existence and ongoing development of such a
> full-featured ready-to-run qmail-derived system is a big reason why
> there's room for a project like notqmail to try alternative approaches,
> even when they might take a while to realize.
>
> If it were a competition, no question, s/qmail is way out in front. But
> I think our projects being active and distinct is mutually beneficial to
> us, as well as to other folks who are still financially and/or
> emotionally invested in qmail.
>
> Thank you again, as always, and keep up the good work. We'll try to do
> the same. :-)
>

--

John Conover, conover@rahul.net, http://www.johncon.com/