Mailing List Archive

2014-12-11 17:49 GMT+01:00 ed <ed-qmail@s5h.net>:
> Hi Everyone,
>
> Since 2007 when qmail was placed in the public domain, I was expecting
> to see netqmail, jms, or other combined patch set author to bundle qmail
> and call it something else.
>
> When I look around today, I cannot see any heavily maintained patch set,
> it seems to me that things have gone really quiet since 2008.
>
> Who's looking after things?

http://www.fehcom.de/qmail/qmail.html

Daniel

Am 11.12.2014 um 17:57 schrieb Daniel Cegiełka:

> http://www.fehcom.de/qmail/qmail.html

Yes, Erwin ist one of the most active qmail devs as of today.

I have started a git repo at https://github.com/gurubert/qmail where I
tried to combine as many patches as I know. As always other projects
came and this was no priority any more.

Regards
--
Robert Sander
gurubert.de

Daniel,

On 2014-12-12 03:57, Daniel Cegiełka wrote:
> 2014-12-11 17:49 GMT+01:00 ed <ed-qmail@s5h.net>:
>> Hi Everyone,
>>
>> Since 2007 when qmail was placed in the public domain, I was expecting
>> to see netqmail, jms, or other combined patch set author to bundle
>> qmail
>> and call it something else.
>>
>> When I look around today, I cannot see any heavily maintained patch
>> set,
>> it seems to me that things have gone really quiet since 2008.
>>
>> Who's looking after things?
>
> http://www.fehcom.de/qmail/qmail.html


Good to know!

"Unfortunately, my forthcoming book about Qmail, Daemontools, UCSPI, and
DJBDNS in German language has been canceled by the publisher."

Why not do an ePub book? - I can help if you like - I do them for my SF
site: http://domain-sf.com

Regards,

Phil.

--
Philip Rhoades

GPO Box 3411
Sydney NSW 2001
Australia
E-mail: phil@pricom.com.au

> Good to know!
>
> "Unfortunately, my forthcoming book about Qmail, Daemontools, UCSPI,
> and DJBDNS in German language has been canceled by the publisher."
>
> Why not do an ePub book? - I can help if you like - I do them for my
> SF site: http://domain-sf.com
>
> Regards,
>
> Phil.
>

The last qmail book was not reviewed before it went to press, a major
expense. I don't suppose self publishing on the Internet pays well.

Major protocols are not supposed to be exciting like installing a new
desktop. You don't do an experiment without a RFC in the applicable
professional group. Qmail has slowed development because it is a mature
product with mature installation tools and add-ons. A RPM with a central
control file might be nice <shrug>, selinux could be tightened
considerably and systemd is an acceptable substitution I suspect. That
was me fiddling with a perfectly fine product to no real advantage.

Hi together,


I almost most missed this thread (Apple’s Mail App is awful).

Since I was referenced regarding qmail, here are my statements (however, don’t nail me):

1. I currently prepare a fork of qmail including my own developments + IPv6. Patching qmail is getting too difficult because of the dependencies.

The state of the project can be found here:

http://www.fehcom.de/ipnet/sqmail.html

ucspi-tcp (done) and ucspi-ssl (still missing some necessary ingredients like OSCP …) is done and fully functional on 64 bit platforms + IPv6 support.

You find it here: http://www.fehcom.de/ipnet/ipnet_en.html

In case I find some quiet hours (the next days) I will build qmail + IPv6 support.
Progress will be reported on the above web site.

Those ones, who are interested about the current state may subscribe to my EZMLM list.


Further plans are to support QMTPS (to provide a distributed qmail system, ie. as cloud solution). Here, I asked IANA to provide some ports for this protocol. This is still pending.



However, DNS is still missing. DJBDNS + CurveDNS is a working solution but requiring IPv6 support + EDNS(0) + …..

Unfortunately, Till’s web page disappeared, but I do have backups and some rough implementation. Though much more work needs to be done.


2. My publication efforts absorbed much of my spare time the last 14 month.

A (german) book about TCP/IP is finished and will be available next year. This will include for example DNSCurve as well.

http://www.fehcom.de/pub/tipn.html


Some of my material will be made public on my web sites.
See: http://www.fehcom.de/qmail/smtptls.html


Regarding my Qmail book project — this is 10 years old. Though the basics still remain (ie. including a nice explanation about Daemontools — Poettering should certainly read it) it is simply outdated according to current wisdom.



3. Apart from these activities, a port of my software is available for FreeBSD — unfortunately is/was broken due to additional third party patches.


The best way to support me currently is simply to use my software and report bugs or successes + requirements. I need to get triggered/fed by the community.


Best regards.
—eh.




Am 12.12.2014 um 09:15 schrieb Philip Rhoades <phil@pricom.com.au>:

> Daniel,
>
> On 2014-12-12 03:57, Daniel Cegiełka wrote:
>> 2014-12-11 17:49 GMT+01:00 ed <ed-qmail@s5h.net>:
>>> Hi Everyone,
>>> Since 2007 when qmail was placed in the public domain, I was expecting
>>> to see netqmail, jms, or other combined patch set author to bundle qmail
>>> and call it something else.
>>> When I look around today, I cannot see any heavily maintained patch set,
>>> it seems to me that things have gone really quiet since 2008.
>>> Who's looking after things?
>> http://www.fehcom.de/qmail/qmail.html
>
>
> Good to know!
>
> "Unfortunately, my forthcoming book about Qmail, Daemontools, UCSPI, and DJBDNS in German language has been canceled by the publisher."
>
> Why not do an ePub book? - I can help if you like - I do them for my SF site: http://domain-sf.com
>
> Regards,
>
> Phil.
>
> --
> Philip Rhoades
>
> GPO Box 3411
> Sydney NSW 2001
> Australia
> E-mail: phil@pricom.com.au
>

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

Hi Erwin,

that sounds like really great news, might I raise two questions ;)

1) From your website "s/qmail will be available in Dan Bernstein's
package format" - might be I am ignorant, but what does that mean?

2) Is there any official source to grab the code? I would really like to
see this on github

If you provide 2 - I would volunteer to create a gentoo package and run
it as testing mx for some not-so-important domains.

Oli


Am 12.12.2014 um 23:39 schrieb Erwin Hoffmann:
> Hi together,
>
>
> I almost most missed this thread (Apple’s Mail App is awful).
>
> Since I was referenced regarding qmail, here are my statements (however, don’t nail me):
>
> 1. I currently prepare a fork of qmail including my own developments + IPv6. Patching qmail is getting too difficult because of the dependencies.
>
> The state of the project can be found here:
>
> http://www.fehcom.de/ipnet/sqmail.html
>
> ucspi-tcp (done) and ucspi-ssl (still missing some necessary ingredients like OSCP …) is done and fully functional on 64 bit platforms + IPv6 support.
>
> You find it here: http://www.fehcom.de/ipnet/ipnet_en.html
>
> In case I find some quiet hours (the next days) I will build qmail + IPv6 support.
> Progress will be reported on the above web site.
>
> Those ones, who are interested about the current state may subscribe to my EZMLM list.
>
>
> Further plans are to support QMTPS (to provide a distributed qmail system, ie. as cloud solution). Here, I asked IANA to provide some ports for this protocol. This is still pending.
>
>
>
> However, DNS is still missing. DJBDNS + CurveDNS is a working solution but requiring IPv6 support + EDNS(0) + …..
>
> Unfortunately, Till’s web page disappeared, but I do have backups and some rough implementation. Though much more work needs to be done.
>
>
> 2. My publication efforts absorbed much of my spare time the last 14 month.
>
> A (german) book about TCP/IP is finished and will be available next year. This will include for example DNSCurve as well.
>
> http://www.fehcom.de/pub/tipn.html
>
>
> Some of my material will be made public on my web sites.
> See: http://www.fehcom.de/qmail/smtptls.html
>
>
> Regarding my Qmail book project — this is 10 years old. Though the basics still remain (ie. including a nice explanation about Daemontools — Poettering should certainly read it) it is simply outdated according to current wisdom.
>
>
>
> 3. Apart from these activities, a port of my software is available for FreeBSD — unfortunately is/was broken due to additional third party patches.
>
>
> The best way to support me currently is simply to use my software and report bugs or successes + requirements. I need to get triggered/fed by the community.
>
>
> Best regards.
> —eh.
>
>
>
>
> Am 12.12.2014 um 09:15 schrieb Philip Rhoades <phil@pricom.com.au>:
>
>> Daniel,
>>
>> On 2014-12-12 03:57, Daniel Cegiełka wrote:
>>> 2014-12-11 17:49 GMT+01:00 ed <ed-qmail@s5h.net>:
>>>> Hi Everyone,
>>>> Since 2007 when qmail was placed in the public domain, I was expecting
>>>> to see netqmail, jms, or other combined patch set author to bundle qmail
>>>> and call it something else.
>>>> When I look around today, I cannot see any heavily maintained patch set,
>>>> it seems to me that things have gone really quiet since 2008.
>>>> Who's looking after things?
>>> http://www.fehcom.de/qmail/qmail.html
>>
>>
>> Good to know!
>>
>> "Unfortunately, my forthcoming book about Qmail, Daemontools, UCSPI, and DJBDNS in German language has been canceled by the publisher."
>>
>> Why not do an ePub book? - I can help if you like - I do them for my SF site: http://domain-sf.com
>>
>> Regards,
>>
>> Phil.
>>
>> --
>> Philip Rhoades
>>
>> GPO Box 3411
>> Sydney NSW 2001
>> Australia
>> E-mail: phil@pricom.com.au
>>
>
> ---
> Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id: 7E4034BE
>
>


--
Protect your environment - close windows and adopt a penguin!

Hi Oliver,


Am 13.12.2014 um 14:05 schrieb Oliver Welter <mail@oliwel.de>:

> Hi Erwin,
>
> that sounds like really great news, might I raise two questions ;)
>
> 1) From your website "s/qmail will be available in Dan Bernstein's package format" - might be I am ignorant, but what does that mean?

The tar-ball will be installed according to DJB’s slashpackage instructions — as with ucspi-tcp6. The name space is already allocated.

>
> 2) Is there any official source to grab the code? I would really like to see this on github

Well. I don’t have any ‚official‘ plans to do so. Usually, i provide the source in the tar-ball and publish the source using Doxygen.
Have a look at:

http://www.fehcom.de/ipnet/ucspi-ssl.html



>
> If you provide 2 - I would volunteer to create a gentoo package and run it as testing mx for some not-so-important domains.
>

Great. Irrespectively of the current Debian discussion regarding upstart/systemd, some useful start-up scripts ready for installation shall come with the software. I have a set of scripts used for user/group setup and to generate basic supervise run scripts.

I think, Robert Sander has some systemd scripts already in his git repository.

As soon, as i have a working beta, I can send you the s/qmail package.

Thank you.

Best regards.
—eh.


> Oli
>
>
> Am 12.12.2014 um 23:39 schrieb Erwin Hoffmann:
>> Hi together,
>>
>>
>> I almost most missed this thread (Apple’s Mail App is awful).
>>
>> Since I was referenced regarding qmail, here are my statements (however, don’t nail me):
>>
>> 1. I currently prepare a fork of qmail including my own developments + IPv6. Patching qmail is getting too difficult because of the dependencies.
>>
>> The state of the project can be found here:
>>
>> http://www.fehcom.de/ipnet/sqmail.html
>>
>> ucspi-tcp (done) and ucspi-ssl (still missing some necessary ingredients like OSCP …) is done and fully functional on 64 bit platforms + IPv6 support.
>>
>> You find it here: http://www.fehcom.de/ipnet/ipnet_en.html
>>
>> In case I find some quiet hours (the next days) I will build qmail + IPv6 support.
>> Progress will be reported on the above web site.
>>
>> Those ones, who are interested about the current state may subscribe to my EZMLM list.
>>
>>
>> Further plans are to support QMTPS (to provide a distributed qmail system, ie. as cloud solution). Here, I asked IANA to provide some ports for this protocol. This is still pending.
>>
>>
>>
>> However, DNS is still missing. DJBDNS + CurveDNS is a working solution but requiring IPv6 support + EDNS(0) + …..
>>
>> Unfortunately, Till’s web page disappeared, but I do have backups and some rough implementation. Though much more work needs to be done.
>>
>>
>> 2. My publication efforts absorbed much of my spare time the last 14 month.
>>
>> A (german) book about TCP/IP is finished and will be available next year. This will include for example DNSCurve as well.
>>
>> http://www.fehcom.de/pub/tipn.html
>>
>>
>> Some of my material will be made public on my web sites.
>> See: http://www.fehcom.de/qmail/smtptls.html
>>
>>
>> Regarding my Qmail book project — this is 10 years old. Though the basics still remain (ie. including a nice explanation about Daemontools — Poettering should certainly read it) it is simply outdated according to current wisdom.
>>
>>
>>
>> 3. Apart from these activities, a port of my software is available for FreeBSD — unfortunately is/was broken due to additional third party patches.
>>
>>
>> The best way to support me currently is simply to use my software and report bugs or successes + requirements. I need to get triggered/fed by the community.
>>
>>
>> Best regards.
>> —eh.
>>
>>
>>
>>
>> Am 12.12.2014 um 09:15 schrieb Philip Rhoades <phil@pricom.com.au>:
>>
>>> Daniel,
>>>
>>> On 2014-12-12 03:57, Daniel Cegiełka wrote:
>>>> 2014-12-11 17:49 GMT+01:00 ed <ed-qmail@s5h.net>:
>>>>> Hi Everyone,
>>>>> Since 2007 when qmail was placed in the public domain, I was expecting
>>>>> to see netqmail, jms, or other combined patch set author to bundle qmail
>>>>> and call it something else.
>>>>> When I look around today, I cannot see any heavily maintained patch set,
>>>>> it seems to me that things have gone really quiet since 2008.
>>>>> Who's looking after things?
>>>> http://www.fehcom.de/qmail/qmail.html
>>>
>>>
>>> Good to know!
>>>
>>> "Unfortunately, my forthcoming book about Qmail, Daemontools, UCSPI, and DJBDNS in German language has been canceled by the publisher."
>>>
>>> Why not do an ePub book? - I can help if you like - I do them for my SF site: http://domain-sf.com
>>>
>>> Regards,
>>>
>>> Phil.
>>>
>>> --
>>> Philip Rhoades
>>>
>>> GPO Box 3411
>>> Sydney NSW 2001
>>> Australia
>>> E-mail: phil@pricom.com.au
>>>
>>
>> ---
>> Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id: 7E4034BE
>>
>>
>
>
> --
> Protect your environment - close windows and adopt a penguin!
>

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

It would be great to have (S)RPM based distribution of qmail
and related supporting packages.

-C

On Sat, Dec 13, 2014 at 07:47:47PM +0530, Chitta Mandal wrote:

> It would be great to have (S)RPM based distribution of qmail
> and related supporting packages.

For anyone who'd like to create such packages, and/or anyone who's
open to using other package systems, I suggest taking a look at the
qmail and qmail-run packages in pkgsrc:

<URL:http://pkgsrc.se/mail/qmail>
<URL:http://pkgsrc.se/mail/qmail-run>

They include build-time options for several common patches and
dependencies, generally follow Life With Qmail, document how and
why that sometimes isn't true, and are actively maintained (by me).
The packages are probably as cross-platform as pkgsrc itself; I
mainly use them on NetBSD, but I can recall having used them on at
least Mac OS X and Linux, and may be forgetting others.

Like Erwin, I'd be grateful to hear experience reports and suggestions
from folks who use (or try to use) these packages.

- Amitai

I have SPEC files for most of the qmail suite, I hope to release them this week.

This allows you to easily build deployable RPMs for:
CDB
DJBDNS
DAEMONTOOLS
FASTFORWARD
NETQMAIL
UCSPI-TCP




-----Original Message-----
From: Amitai Schlair [mailto:schmonz@schmonz.com]
Sent: Saturday, 13 December, 2014 6:53 AM
To: Chitta Mandal
Cc: qmail@list.cr.yp.to
Subject: Re: The current state of qmail

On Sat, Dec 13, 2014 at 07:47:47PM +0530, Chitta Mandal wrote:

> It would be great to have (S)RPM based distribution of qmail and
> related supporting packages.

For anyone who'd like to create such packages, and/or anyone who's open to using other package systems, I suggest taking a look at the qmail and qmail-run packages in pkgsrc:

<URL:http://pkgsrc.se/mail/qmail>
<URL:http://pkgsrc.se/mail/qmail-run>

They include build-time options for several common patches and dependencies, generally follow Life With Qmail, document how and why that sometimes isn't true, and are actively maintained (by me).
The packages are probably as cross-platform as pkgsrc itself; I mainly use them on NetBSD, but I can recall having used them on at least Mac OS X and Linux, and may be forgetting others.

Like Erwin, I'd be grateful to hear experience reports and suggestions from folks who use (or try to use) these packages.

- Amitai

Scott,


On 2014-12-16 03:11, Scott Brynen wrote:
> I have SPEC files for most of the qmail suite, I hope to release them
> this week.
>
> This allows you to easily build deployable RPMs for:
> CDB
> DJBDNS
> DAEMONTOOLS
> FASTFORWARD
> NETQMAIL
> UCSPI-TCP


Excellent! I have my own re-install script which has evolved over many
years but RPMs would be great!

Regards,

Phil.



> -----Original Message-----
> From: Amitai Schlair [mailto:schmonz@schmonz.com]
> Sent: Saturday, 13 December, 2014 6:53 AM
> To: Chitta Mandal
> Cc: qmail@list.cr.yp.to
> Subject: Re: The current state of qmail
>
> On Sat, Dec 13, 2014 at 07:47:47PM +0530, Chitta Mandal wrote:
>
>> It would be great to have (S)RPM based distribution of qmail and
>> related supporting packages.
>
> For anyone who'd like to create such packages, and/or anyone who's
> open to using other package systems, I suggest taking a look at the
> qmail and qmail-run packages in pkgsrc:
>
> <URL:http://pkgsrc.se/mail/qmail>
> <URL:http://pkgsrc.se/mail/qmail-run>
>
> They include build-time options for several common patches and
> dependencies, generally follow Life With Qmail, document how and why
> that sometimes isn't true, and are actively maintained (by me).
> The packages are probably as cross-platform as pkgsrc itself; I mainly
> use them on NetBSD, but I can recall having used them on at least Mac
> OS X and Linux, and may be forgetting others.
>
> Like Erwin, I'd be grateful to hear experience reports and suggestions
> from folks who use (or try to use) these packages.
>
> - Amitai

--
Philip Rhoades

GPO Box 3411
Sydney NSW 2001
Australia
E-mail: phil@pricom.com.au

RPMs have to be maintained. This can be a major pain especially with
distributions and test beds like fedora that try every new thing known
to the linux community with few compatibility checks.

In regards to the script mentioned I add the following on machines with
systemctl

To have qmail/netqmail server run under systemd, one needs to create a
service configuration file

#vi /lib/systemd/system/qmail.service
[Unit]
Description=qmail/netqmail service
Requires=network.target
After=local-fs.target network.target

[Service]
Restart=always
PIDFile=/var/run/qmail.pid
ExecStart=/usr/local/bin/svscan /service
ExecStop=/var/qmail/bin/svc -dx /service/* /service/*/log
Type=simple
NonBlocking=yes

[Install]
WantedBy=multi-user.target

NOTE: You can use your own variation in ExecStart to start svscan
(using it with readproctitle, etc)

# systemctl enable qmail.service
The above command will create a link in
/etc/systemd/system/multi-user.target.wants

(symbolic link created)
lrwxrwxrwx 1 root root 36 Jul 20 18:18 qmail.service ->
/lib/systemd/system/qmail.service

Then create/edit /etc/init/svscanboot.conf
### start of /etc/init/svscanboot.conf ########
start on runlevel 2
start on runlevel 3
start on runlevel 4
start on runlevel 5
stop on runlevel 0
stop on runlevel 1
stop on runlevel 6
respawn
exec /command/svscanboot
### end of /etc/init/svscanboot.conf ########

To start qmail/netqmail do
# systemctl start qmail.service
To stop qmail/netqmail do
# systemctl stop qmail.service

svc -u/-d and qmailctl still work fine

On 12/15/2014 10:19 PM, Philip Rhoades wrote:
>
> Excellent! I have my own re-install script which has evolved over
> many years but RPMs would be great!
>
> Regards,
>
> Phil.
>

The current state of qmail is quite easily described - fading.

Those who have big installations based on qmail don't really use qmail
as an MTA anyway, but rather as a colelction of building blocks for
their own MTA (or rather, Mail System, it is much more than an MTA).
They effectively have forked qmail.
Those aren't very visible - why would they?
I have such a setup and I am aware of a couple more.

Where qmail has been used as an MTA it either has been replaced
already or is to be replaced once something "major" changes around it.
qmail as-is just doesn't cut it any more, you need recipient
verification in the SMTP dialogue, you pretty much need TLS, and so
on, the list is quite long by now. Add that qmail is not in most
package management systems and very "different" to configure and
maintain.

qmail was EXTREMELY important at its time, last not least one of the
first, if not THE first, visible privilege seperation implementation.

That was almost 20 years ago.
The world has changed, qmail hasn't.

--
Henning Brauer, hb@bsws.de, henning@openbsd.org
BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, VMs/PVS, Application Hosting

Hello Erwin,

I recently upgraded to Spamcontrol 2.7.32. Here is what bothered me most:

-No support for greylisting. I know there are several solutions to have
support for TLS + greylisting but something integrated into your patch
would probably be much less work to get running. I currently use the hermes
smtp proxy with self-developed patches.

-I had to install ucspi-ssl, which uses esoteric packaging, building and
installation processes requiring additional effort.

-My previous old qmail with Spamcontrol did not have bigtodo and I did not
spend days contemplating the upgrade (only hours). So my queue was a bit
broken after upgrading. The only tool that seems to be able to convert
to/from bigtodo seems to be queue-repair (Python) but it seems to choose
wrong permissions and file modes for some files and will not remove files
without counterpart in queue/mess like queue-fix does. There is a bigtodo-
patch for queue-fix floating around in mailing list archives that I use now.

I certainly agree with Henning Brauers last mail. Nobody without very special
demands or legacy issues would choose the royal PITA of living with qmail.

BTW: German privacy regulators are threatening mail server admins that do not
use TLS with PFS with fines.

Regards,

Michael Brunnbauer

On Fri, Dec 12, 2014 at 11:39:35PM +0100, Erwin Hoffmann wrote:
> Hi together,
>
>
> I almost most missed this thread (Apple???s Mail App is awful).
>
> Since I was referenced regarding qmail, here are my statements (however, don???t nail me):
>
> 1. I currently prepare a fork of qmail including my own developments + IPv6. Patching qmail is getting too difficult because of the dependencies.
>
> The state of the project can be found here:
>
> http://www.fehcom.de/ipnet/sqmail.html
>
> ucspi-tcp (done) and ucspi-ssl (still missing some necessary ingredients like OSCP ???) is done and fully functional on 64 bit platforms + IPv6 support.
>
> You find it here: http://www.fehcom.de/ipnet/ipnet_en.html
>
> In case I find some quiet hours (the next days) I will build qmail + IPv6 support.
> Progress will be reported on the above web site.
>
> Those ones, who are interested about the current state may subscribe to my EZMLM list.
>
>
> Further plans are to support QMTPS (to provide a distributed qmail system, ie. as cloud solution). Here, I asked IANA to provide some ports for this protocol. This is still pending.
>
>
>
> However, DNS is still missing. DJBDNS + CurveDNS is a working solution but requiring IPv6 support + EDNS(0) + ???..
>
> Unfortunately, Till???s web page disappeared, but I do have backups and some rough implementation. Though much more work needs to be done.
>
>
> 2. My publication efforts absorbed much of my spare time the last 14 month.
>
> A (german) book about TCP/IP is finished and will be available next year. This will include for example DNSCurve as well.
>
> http://www.fehcom.de/pub/tipn.html
>
>
> Some of my material will be made public on my web sites.
> See: http://www.fehcom.de/qmail/smtptls.html
>
>
> Regarding my Qmail book project ??? this is 10 years old. Though the basics still remain (ie. including a nice explanation about Daemontools ??? Poettering should certainly read it) it is simply outdated according to current wisdom.
>
>
>
> 3. Apart from these activities, a port of my software is available for FreeBSD ??? unfortunately is/was broken due to additional third party patches.
>
>
> The best way to support me currently is simply to use my software and report bugs or successes + requirements. I need to get triggered/fed by the community.
>
>
> Best regards.
> ???eh.
>
>
>
>
> Am 12.12.2014 um 09:15 schrieb Philip Rhoades <phil@pricom.com.au>:
>
> > Daniel,
> >
> > On 2014-12-12 03:57, Daniel Cegie??ka wrote:
> >> 2014-12-11 17:49 GMT+01:00 ed <ed-qmail@s5h.net>:
> >>> Hi Everyone,
> >>> Since 2007 when qmail was placed in the public domain, I was expecting
> >>> to see netqmail, jms, or other combined patch set author to bundle qmail
> >>> and call it something else.
> >>> When I look around today, I cannot see any heavily maintained patch set,
> >>> it seems to me that things have gone really quiet since 2008.
> >>> Who's looking after things?
> >> http://www.fehcom.de/qmail/qmail.html
> >
> >
> > Good to know!
> >
> > "Unfortunately, my forthcoming book about Qmail, Daemontools, UCSPI, and DJBDNS in German language has been canceled by the publisher."
> >
> > Why not do an ePub book? - I can help if you like - I do them for my SF site: http://domain-sf.com
> >
> > Regards,
> >
> > Phil.
> >
> > --
> > Philip Rhoades
> >
> > GPO Box 3411
> > Sydney NSW 2001
> > Australia
> > E-mail: phil@pricom.com.au
> >
>
> ---
> Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id: 7E4034BE
>

--
++ Michael Brunnbauer
++ netEstate GmbH
++ Geisenhausener Straße 11a
++ 81379 München
++ Tel +49 89 32 19 77 80
++ Fax +49 89 32 19 77 89
++ E-Mail brunni@netestate.de
++ http://www.netestate.de/
++
++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
++ USt-IdNr. DE221033342
++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel

Hi Michael,


Am 17.12.2014 um 15:18 schrieb Michael Brunnbauer <brunni@netestate.de>:

>
> Hello Erwin,
>
> I recently upgraded to Spamcontrol 2.7.32. Here is what bothered me most:
>
> -No support for greylisting. I know there are several solutions to have
> support for TLS + greylisting but something integrated into your patch
> would probably be much less work to get running. I currently use the hermes
> smtp proxy with self-developed patches.
>

Hm. You mean Greylisting based on HELO and Mail From information ?
Do you consider a qmail-smtpd plug-in for Greylisting rather front-end module like rblsmtpd ?


> -I had to install ucspi-ssl, which uses esoteric packaging, building and
> installation processes requiring additional effort.

ucspi-ssl uses the slashpackage format.

>
> -My previous old qmail with Spamcontrol did not have bigtodo and I did not
> spend days contemplating the upgrade (only hours). So my queue was a bit
> broken after upgrading. The only tool that seems to be able to convert
> to/from bigtodo seems to be queue-repair (Python) but it seems to choose
> wrong permissions and file modes for some files and will not remove files
> without counterpart in queue/mess like queue-fix does. There is a bigtodo-
> patch for queue-fix floating around in mailing list archives that I use now.
>

Sorry for that. It seems you updated your system with files hanging around in the todo state.
Actually, this was a matter of the Release Notes.



> I certainly agree with Henning Brauers last mail. Nobody without very special
> demands or legacy issues would choose the royal PITA of living with qmail.
>
> BTW: German privacy regulators are threatening mail server admins that do not
> use TLS with PFS with fines.
>

That is the reason why I integrated SSL into qmail-remote and will go one with other modules as well.

However, referring to Henning’s remarks:

a) We need to sort out and define what are the technical directions to go.

b) Second, we need to implement, test, and report those. Unfortunately, the qmail mail site — qmail.org — is a disaster. It simply does not reflect the current needs. I appreciate Russ’ afford to keep it alive, but it distracts newbies and is not helpful for the matured ones.

However, regarding the current need for more privacy on the net, DJBs developments need again to be reconsidered.

Anybody willing to follow that path is invited.

Best regards.
—eh.


> Regards,
>
> Michael Brunnbauer
>
> On Fri, Dec 12, 2014 at 11:39:35PM +0100, Erwin Hoffmann wrote:
>> Hi together,
>>
>>
>> I almost most missed this thread (Apple???s Mail App is awful).
>>
>> Since I was referenced regarding qmail, here are my statements (however, don???t nail me):
>>
>> 1. I currently prepare a fork of qmail including my own developments + IPv6. Patching qmail is getting too difficult because of the dependencies.
>>
>> The state of the project can be found here:
>>
>> http://www.fehcom.de/ipnet/sqmail.html
>>
>> ucspi-tcp (done) and ucspi-ssl (still missing some necessary ingredients like OSCP ???) is done and fully functional on 64 bit platforms + IPv6 support.
>>
>> You find it here: http://www.fehcom.de/ipnet/ipnet_en.html
>>
>> In case I find some quiet hours (the next days) I will build qmail + IPv6 support.
>> Progress will be reported on the above web site.
>>
>> Those ones, who are interested about the current state may subscribe to my EZMLM list.
>>
>>
>> Further plans are to support QMTPS (to provide a distributed qmail system, ie. as cloud solution). Here, I asked IANA to provide some ports for this protocol. This is still pending.
>>
>>
>>
>> However, DNS is still missing. DJBDNS + CurveDNS is a working solution but requiring IPv6 support + EDNS(0) + ???..
>>
>> Unfortunately, Till???s web page disappeared, but I do have backups and some rough implementation. Though much more work needs to be done.
>>
>>
>> 2. My publication efforts absorbed much of my spare time the last 14 month.
>>
>> A (german) book about TCP/IP is finished and will be available next year. This will include for example DNSCurve as well.
>>
>> http://www.fehcom.de/pub/tipn.html
>>
>>
>> Some of my material will be made public on my web sites.
>> See: http://www.fehcom.de/qmail/smtptls.html
>>
>>
>> Regarding my Qmail book project ??? this is 10 years old. Though the basics still remain (ie. including a nice explanation about Daemontools ??? Poettering should certainly read it) it is simply outdated according to current wisdom.
>>
>>
>>
>> 3. Apart from these activities, a port of my software is available for FreeBSD ??? unfortunately is/was broken due to additional third party patches.
>>
>>
>> The best way to support me currently is simply to use my software and report bugs or successes + requirements. I need to get triggered/fed by the community.
>>
>>
>> Best regards.
>> ???eh.
>>
>>
>>
>>
>> Am 12.12.2014 um 09:15 schrieb Philip Rhoades <phil@pricom.com.au>:
>>
>>> Daniel,
>>>
>>> On 2014-12-12 03:57, Daniel Cegie??ka wrote:
>>>> 2014-12-11 17:49 GMT+01:00 ed <ed-qmail@s5h.net>:
>>>>> Hi Everyone,
>>>>> Since 2007 when qmail was placed in the public domain, I was expecting
>>>>> to see netqmail, jms, or other combined patch set author to bundle qmail
>>>>> and call it something else.
>>>>> When I look around today, I cannot see any heavily maintained patch set,
>>>>> it seems to me that things have gone really quiet since 2008.
>>>>> Who's looking after things?
>>>> http://www.fehcom.de/qmail/qmail.html
>>>
>>>
>>> Good to know!
>>>
>>> "Unfortunately, my forthcoming book about Qmail, Daemontools, UCSPI, and DJBDNS in German language has been canceled by the publisher."
>>>
>>> Why not do an ePub book? - I can help if you like - I do them for my SF site: http://domain-sf.com
>>>
>>> Regards,
>>>
>>> Phil.
>>>
>>> --
>>> Philip Rhoades
>>>
>>> GPO Box 3411
>>> Sydney NSW 2001
>>> Australia
>>> E-mail: phil@pricom.com.au
>>>
>>
>> ---
>> Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de | PGP Key-Id: 7E4034BE
>>
>
> --
> ++ Michael Brunnbauer
> ++ netEstate GmbH
> ++ Geisenhausener Straße 11a
> ++ 81379 München
> ++ Tel +49 89 32 19 77 80
> ++ Fax +49 89 32 19 77 89
> ++ E-Mail brunni@netestate.de
> ++ http://www.netestate.de/
> ++
> ++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
> ++ USt-IdNr. DE221033342
> ++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
> ++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel

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

Hello Erwin,

On Wed, Dec 17, 2014 at 04:01:49PM +0100, Erwin Hoffmann wrote:
> Hm. You mean Greylisting based on HELO and Mail From information ?

I mean Greylisting based on a database of ip/from/to triples.

> Do you consider a qmail-smtpd plug-in for Greylisting rather front-end module like rblsmtpd ?

Huh? You mean something like spamdyke? I discovered spamdyke too late. As the
code is very low level (compared to hermes) and the documentation very big, I
did not abandon hermes. spamdyke seems to duplicate much functionality of
Spamcontrol. Don't you think that it would be much less work if Spamcontrol
offered Greylisting out of the box?

> > -I had to install ucspi-ssl, which uses esoteric packaging, building and
> > installation processes requiring additional effort.
>
> ucspi-ssl uses the slashpackage format.

From Dan, yes. I think I never saw it before. Can you name any popular
software using it? qmail, checkpassword, ucspi-tcp, etc. all come with a
working Makefile and do not insist to be installed in /package.

> > -My previous old qmail with Spamcontrol did not have bigtodo and I did not
> Sorry for that. It seems you updated your system with files hanging around in the todo state.
> Actually, this was a matter of the Release Notes.

No problem. I am more concerned that Spamcontrol does not come with queue
management tools, e.G. a tool to convert to bigtodo and a queue-fix patched
for bigtodo.

Regards,

Michael Brunnbauer

--
++ Michael Brunnbauer
++ netEstate GmbH
++ Geisenhausener Straße 11a
++ 81379 München
++ Tel +49 89 32 19 77 80
++ Fax +49 89 32 19 77 89
++ E-Mail brunni@netestate.de
++ http://www.netestate.de/
++
++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
++ USt-IdNr. DE221033342
++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel

>> -I had to install ucspi-ssl, which uses esoteric packaging, building and
>> installation processes requiring additional effort.
>
> ucspi-ssl uses the slashpackage format.

Unfortunately, nobody uses the slashpackage format these days unless they
really are enamored with it. I understand the concept, and can see where
it might have been a useful idea at one time, but frankly (like "plain"
qmail) it's time has come and gone. Most (if not all) production servers
use some sort of Distro-preferred binary packaging system, and unless you
only have one server and don't mind just running 'make install', you're
going to want to use it for all of your software.

I'm in the process of putting the finishing touches on an RPM that starts
with SPAMCONTROL and adds a bunch of other patches that I would like
(including a couple that should probably be in it, like EXTERNAL-TODO),
and while it's a bit of a pain to initially set it up the RPM format has
made testing and eventual deployment from one environment to another a lot
simpler. The slashpackage formats for ucspi-tcp6 and ucspi-ssl were also
a bit of a pain to work with in building RPMs, but again once built it's
out of the picture. I don't object things being available in slashpackage
format, but I've decided that it's just not worth my time to keep them
that way...

Josh

Joshua Megerman
SJGames MIB #5273 - OGRE AI Testing Division
You can't win; You can't break even; You can't even quit the game.
- Layman's translation of the Laws of Thermodynamics
josh@honorablemenschen.com

On Wed, Dec 17, 2014 at 02:01:55PM +0100, Henning Brauer wrote:
> The current state of qmail is quite easily described - fading.

Yes, the original qmail code hasn't changed in a very long time. That
could be viewed as a good thing, that original building block is very
solid.

> Those who have big installations based on qmail don't really use qmail
> as an MTA anyway, but rather as a colelction of building blocks for
> their own MTA (or rather, Mail System, it is much more than an MTA).
> They effectively have forked qmail.
> Those aren't very visible - why would they?
> I have such a setup and I am aware of a couple more.
>
> Where qmail has been used as an MTA it either has been replaced
> already or is to be replaced once something "major" changes around it.
> qmail as-is just doesn't cut it any more, you need recipient
> verification in the SMTP dialogue, you pretty much need TLS, and so

Agreed. I'm currently using JMS's combined patch set, with some of my
own modifications.

> on, the list is quite long by now. Add that qmail is not in most
> package management systems and very "different" to configure and
> maintain.

The same can be said of postfix/exim/sendmail, especially with debian
since configuration gets pulled in, as with many things, with glob
scriptlets.

> qmail was EXTREMELY important at its time, last not least one of the
> first, if not THE first, visible privilege seperation implementation.

Yes, this is the reason I still use it. Call me a curmudgeon but it
works and I like it.

> That was almost 20 years ago.
> The world has changed, qmail hasn't.

qmail hasn't changed, you're right, what I'm wanting to know is where
today are people meant to go for their combined patches. I was expecting
(after several years without need) to find that something like netqmail
was running the show with huge community of followers. This doesn't seem
to be the case. In honesty, I wanted somewhere to submit the tiny
patches that I had done so that someone else who tracks a bigger set of
patches could maintain it. Given the code is now public domain, I am
surprised that some other derivative work hasn't become established and
taken over.

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

Hi

Am 17.12.2014 um 19:44 schrieb ed <ed-qmail@s5h.net>:

> On Wed, Dec 17, 2014 at 02:01:55PM +0100, Henning Brauer wrote:
>> The current state of qmail is quite easily described - fading.
>
> Yes, the original qmail code hasn't changed in a very long time. That
> could be viewed as a good thing, that original building block is very
> solid.
>
>> Those who have big installations based on qmail don't really use qmail
>> as an MTA anyway, but rather as a colelction of building blocks for
>> their own MTA (or rather, Mail System, it is much more than an MTA).
>> They effectively have forked qmail.
>> Those aren't very visible - why would they?
>> I have such a setup and I am aware of a couple more.
>>
>> Where qmail has been used as an MTA it either has been replaced
>> already or is to be replaced once something "major" changes around it.
>> qmail as-is just doesn't cut it any more, you need recipient
>> verification in the SMTP dialogue, you pretty much need TLS, and so
>
> Agreed. I'm currently using JMS's combined patch set, with some of my
> own modifications.
>

Yupp. JMS ist one of the major patch-sets.


>> on, the list is quite long by now. Add that qmail is not in most
>> package management systems and very "different" to configure and
>> maintain.
>
> The same can be said of postfix/exim/sendmail, especially with debian
> since configuration gets pulled in, as with many things, with glob
> scriptlets.
>
>> qmail was EXTREMELY important at its time, last not least one of the
>> first, if not THE first, visible privilege seperation implementation.
>
> Yes, this is the reason I still use it. Call me a curmudgeon but it
> works and I like it.
>

Still a superior design.


>> That was almost 20 years ago.
>> The world has changed, qmail hasn't.
>
> qmail hasn't changed, you're right, what I'm wanting to know is where
> today are people meant to go for their combined patches. I was expecting
> (after several years without need) to find that something like netqmail
> was running the show with huge community of followers. This doesn't seem
> to be the case. In honesty, I wanted somewhere to submit the tiny
> patches that I had done so that someone else who tracks a bigger set of
> patches could maintain it. Given the code is now public domain, I am
> surprised that some other derivative work hasn't become established and
> taken over.

The only major fork I know is IndiMail.

What I find rather puzzling is the lack of technical discussion and requirements analysis among the ‚qmail specialists‘.

Here, Postfix posses an advantage because Wietse is coordinating the development.

I would have wished, if Russ (and perhaps together with Charles and Henning) would have taken the opportunity to formulate the ‚best of breed‘; unlike the situation today, where we have scattered, incompatible patches.

Actually, I am a victim of this: The qmail/spamcontrol FreeBSD port includes the External-Todo patch (in a version/state I can’t control) of Rene Oppermann glued together. It simply does not work.

---

Anyway. I will carry on with my s/qmail project. IPv6 + TLS for QMTP comes next. I will keep compatibility with vanilla qmail, thus ‚the tiny patches‘ still can be applied.

Stay tuned.

Best regards.
—eh.



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

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

Thus said Erwin Hoffmann on Wed, 17 Dec 2014 21:12:17 +0100:

> The only major fork I know is IndiMail.

This may be the only public fork, but I bet there are a lot of private
forks.

If I'm not mistaken, Yahoo forked qmail and I still think they are using
it, but this is private code.

I also think that Gmail's SMTP servers have an air of qmail to them, and
I suspect that they too may have used qmail as the basis for building
their service, but I could never prove it.

> What I find rather puzzling is the lack of technical discussion and
> requirements analysis among the ``qmail specialists''.

Perhaps qmail fits a niche and those who use it like it in that niche
already and don't find it worth the effort to compete with others? Maybe
people are more interested in code origination and so we get more MTAs
out there. Maybe part of the problem is that there is no concensus as to
what should and shouldn't be there and nobody wants to commit to a
patched qmail that is hard to remove features from. Easier to add than
it is to take away?

I continue to use qmail (and even recommend it for certain situations)
and will continue to do so as long as it will compile.

> Actually, I am a victim of this: The qmail/spamcontrol FreeBSD port
> includes the External-Todo patch (in a version/state I can't control)
> of Rene Oppermann glued together. It simply does not work.

I don't necessarily agree with all the patches that are included in the
``jumbo'' patches so I just have my own repository beginning with
vanilla qmail sources, then I patch as I see fit. If there is a
conflict, I refactor until they work. I build from that for all
installations where a vanilla qmail won't be suitable---I find that
vanilla qmail works just fine on a private network, but for public
facing SMTP more is required.

What I like about qmail is it's modularity which makes it easy to extend
and replace any component that doesn't do exactly what is wanted.

Thanks for keeping your contributions active.

Andy
--
TAI64 timestamp: 40000000549279f5

On 18 December 2014 at 01:42, Erwin Hoffmann <feh@fehcom.de> wrote:
>
> The only major fork I know is IndiMail.
>

To give more perspective about IndiMail, most of the major changes
have been in qmail-smtpd, qmail-remote and qmail-queue, IPV6 support.
The other changes are mostly to implement all patches that are out
there and implementations of DKIM, BATV, greylisting, QHPSI (for virus
scanning from Erwin Hoffman), etc.

On 2014-12-18 06:53, Andy Bradford wrote:

> Thus said Erwin Hoffmann on Wed, 17 Dec 2014 21:12:17 +0100:
>
>> The only major fork I know is IndiMail.
>
> This may be the only public fork, but I bet there are a lot of
> private
> forks.

Agreed, we have an internal fork which we have been using since ~2003.
several people have hinted about putting up on GitHub, we thought about
GPLv2 but unsure how that would work given the "public domain" status of
the original code base now. comments?

mainly we were hooking into mysql at various points for all the
userdb/.qmail file stuff, we also took a knife to anything we didn't
need, pop3, qmtp etc. other changes I recall (from memory):

qmail-smtpd/qmail-remote
domainkeys with yahoo's libdomainkeys
dkim with pdkim
ssl/tls
srs


qmail-smtpd:
verify users during RCPT/MAIL
various dns/rbl checks
various 822/2822/5322 header checks/basic requirements
autonomous system header logging: country code/asn/netname etc.
user level blacklists/whitelists (from mysql again)

IPv6 support based on Kazunori Fujiwara's original 2002 patch

a lot changes to work with modern gcc
removal of all the old K&R definitions, global code reformat :)

a number of other smaller changes involving 822/2822/5322 header
layout/information/logging etc
changed the delivery retry scheduling
changed the whole inode/message id queue thing to use a base64 encoded
128bit UUID's (v1 mac based) a wide ranging patch that touches many
files, subdirectory split handling etc.
added qmail-lmtp and an lmtp queue mainly to lmtp to Dovecot
added qmail-imap and an imap queue so that we could copy "sent items"
server side into user's imap account (using dovecot master users)
(strictly speaking those two could have been added as part of the
"remote queue", though they are generally more short-lived compared to
the remote queue items as they are more "local" (topologically speaking)
though not system-local)

merged in other community patches..
John M. Simpson's surbl url scanner patch - with a few changes
Jana Saout's spf patch by - also started work on an spf patch using
libspf
Claudio Jeker's & Andre Oppermann's EXTTODO - with changes there to
work with our extra queue's and mysql
Bruce Guenter's fastremote patch

bare lf patch
big concurrency
better handling of error codes during initial smtp conversation in
qmail-remote

others I'm probably forgetting - just working from memory here!

just my 2p :)


--
Paul Freeman
Core Internet Limited T +44(0)1329 800 300
https://www.coreinternet.co.uk/ F +44(0)1329 800 301

Hi Paul,


Am 18.12.2014 um 15:49 schrieb Paul Freeman (Core Internet) <paul@coreinternet.co.uk>:

> On 2014-12-18 06:53, Andy Bradford wrote:
>
>> Thus said Erwin Hoffmann on Wed, 17 Dec 2014 21:12:17 +0100:
>>
>>> The only major fork I know is IndiMail.
>>
>> This may be the only public fork, but I bet there are a lot of private
>> forks.
>
> Agreed, we have an internal fork which we have been using since ~2003. several people have hinted about putting up on GitHub, we thought about GPLv2 but unsure how that would work given the "public domain" status of the original code base now. comments?
>
> mainly we were hooking into mysql at various points for all the userdb/.qmail file stuff, we also took a knife to anything we didn't need, pop3, qmtp etc. other changes I recall (from memory):
>
> qmail-smtpd/qmail-remote
> domainkeys with yahoo's libdomainkeys
> dkim with pdkim
> ssl/tls
> srs
>
>
> qmail-smtpd:
> verify users during RCPT/MAIL
> various dns/rbl checks
> various 822/2822/5322 header checks/basic requirements
> autonomous system header logging: country code/asn/netname etc.
> user level blacklists/whitelists (from mysql again)
>
> IPv6 support based on Kazunori Fujiwara's original 2002 patch
>
> a lot changes to work with modern gcc
> removal of all the old K&R definitions, global code reformat :)
>
> a number of other smaller changes involving 822/2822/5322 header layout/information/logging etc
> changed the delivery retry scheduling
> changed the whole inode/message id queue thing to use a base64 encoded 128bit UUID's (v1 mac based) a wide ranging patch that touches many files, subdirectory split handling etc.
> added qmail-lmtp and an lmtp queue mainly to lmtp to Dovecot
> added qmail-imap and an imap queue so that we could copy "sent items" server side into user's imap account (using dovecot master users)
> (strictly speaking those two could have been added as part of the "remote queue", though they are generally more short-lived compared to the remote queue items as they are more "local" (topologically speaking) though not system-local)
>

This sounds like a wish list for christmas.

Some of them I’ve incorporated already into my Spamcontrol patch; others are foreseen for s/qmail.

However, we have to take care: qmail’s code base is small and consistent. Adding many patches from different people makes the code incoherent and difficult to manage/audit/verify. Don’t let qmail become bloated and included solutions for just one problem as general.

What I identified to be necessary is:

a) AMD64 and Clang support.
b) IPv6 is a must.
c) TLS is a must for all transport protocols.

— That’s on my agenda.

However, I’m not a fan of stateful solutions in case they can be omitted: Greetdelay vs. Greylisting, use of databases + sql queries.
For instance in my RECIPIENTS extension for qmail-smtpd there is space for a qmail-sqlpam. Why not?

Other items I believe to be important:

d) Encryption of qmail queue (perhaps supported by the OS)
e) Pipelining for qmail-rspawn.

f) qmail-lmtp and qmail-imap sounds great.

What I find least important is:

- A qmail package either in .rpm or .deb format.

Though I’ve recognized the criticism about the slashpackage format, just

package/install main

should not be to difficult. The problem is here, that some Linux system don’t provide the necessary header files since they need to be installed by means of additional dev-XX packages.

Now, I stop here and invest the rest of the day for qmail development.

Best regards.
—eh.


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

* Erwin Hoffmann <feh@fehcom.de> [2014-12-17 21:28]:
> Still a superior design.

From nowadays POV, I beg to differ.

> > qmail hasn't changed, you're right, what I'm wanting to know is where
> > today are people meant to go for their combined patches. I was expecting
> > (after several years without need) to find that something like netqmail

There is a netqmail. We haven't touched/updated it in many moons tho,
and the approach was extremely conservative. Maybe too conservative.

> What I find rather puzzling is the lack of technical discussion and
> requirements analysis among the ‚qmail specialists‘.

Puzzling?

As said earlier, two groups really:
-those running big custom systems based on qmail aren't very visible,
esp. here
-almost everybody else moved on to something else

> I would have wished, if Russ (and perhaps together with Charles and
> Henning) would have taken the opportunity to formulate the ‚best of
> breed‘; unlike the situation today, where we have scattered,
> incompatible patches.

err...
http://www.qmail.org/netqmail/
More or less surprisingly, the 3 names you mentioned are in the README.

> Actually, I am a victim of this: The qmail/spamcontrol FreeBSD port
> includes the External-Todo patch (in a version/state I can’t control)
> of Rene Oppermann glued together. It simply does not work.

Andre, not Rene.

> Anyway. I will carry on with my s/qmail project. IPv6 + TLS for QMTP
> comes next. I will keep compatibility with vanilla qmail, thus ‚the
> tiny patches‘ still can be applied.

Two things that really need to happen for those continuing to run
qmail:
-djb's DNS code has to be replaced. With the ever growing DNS answers,
its shortcomings impose real operational damage.
-a proper TLS implementation, with PFS. Afaik none of the SSL/TLS
patches have it right (no surprise given the horrible OpenSSL API, and
given that the other TLS libs are even worse)

--
Henning Brauer, hb@bsws.de, henning@openbsd.org
BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, VMs/PVS, Application Hosting