Mailing List Archive

On 21 April 2016 at 14:30, Pascal Nobus <pascal@nobus.be> wrote:
> Since the previous century we are running several mailservers on qmail,
> serving around 6000 domains with about 4000 mailboxes.
>

great :)

> Ezmlm is also in use.
>
>
> Because of the several patches the last years (some have TLS, other
> IPv6, some both, some none of these), we want to make a new fresh start
> with compiling qmail on our servers.
> Our systems are mixed-OS's, most run on Slackware, some of them on
> CentOS, so I want to compile the things myself.
>
>
> Which package should we follow?
> eQmail, s/qmail, or are there others?
>

You could try eQmail, s/qmail and regarding others, you could give a
try to indimail-mta,
available in RPM / Debian format for various distros at
http://software.opensuse.org/download.html?project=home%3Aindimail&package=indimail-mta

Gives you TLS + IPv6 + DKIM + ucspi-tcp + daemontools + SRS +
SPAM/virus filter and
almost all patches known to me It does not have a binary package for
slackware, but you
could easily build it yourself using the pristine qmail-1.03,
ucsp-tcp-0.88 tarballs and theqmail-1.03 and ucspi-tcp-0.88 patch from
https://sourceforge.net/projects/indimail/files/Patches/

If you want virtual domains support with IMAP, POP3 (courier-imap) and
users in MySQL database then you
could look at the IndiMail package at
http://software.opensuse.org/download.html?project=home%3Aindimail&package=indimail

Installation and configuration of indimail-mta is quite simple and you
will feel quite at home since you use qmail.
Configuration of indimail package is a bit more involved however
(MySQL setup, etc).

You can use iwebadmin (a hack of qmailadmin) to manage indimail. All
binary packages (indimail-mta, indimail, iwebadmin) are available from
the same repos.

Tutorials are available at http://indimail.blogspot.in/

Spoilt for choice? My suggestion: use eQmail! ;-)

No truly, I'm wondering that there is no more response to your question.
I see eQmail like the mentioned but never released netqmail-1.07. I made
it cause netqmail-1.07 was never released. It includes the really needed
enhancements only. Any other enhancements have to be done by (3rd party)
extensions through the API's. This is the responsibility of the admin.
Means that there will no new functionality added to the original code in
the future - at least I don't see any reason to do so at the moment. The
final eQmail-1.09 will be released within the next (2) weeks, so give it
a try.

It makes the decision may be easier for you if you know where eQmail
will go in the future. Mainly it will be stripped down by removing some
overhead. Less code, less risk of bugs. As an example qmail-pop3d will
be removed from standard installation because of the "Guninski" bug and
the availability of other/better POP3/IMAP servers. Overall eQmail will
be a core MTA with improved user (admin) friendliness in the future.
Code changes will be reduced to fixes in case there will be a need for.
I will publish a road map after next final release.

I will bundle some of my extensions in my upcoming openqmail suite and
will add more step by step.

Anyway, you have do decide along your needs, experience and preferences.
IMHO individual patching haven't to be necessary anymore.

On 2016-04-21 11:00, Pascal Nobus wrote:
> Since the previous century we are running several mailservers on qmail,
> serving around 6000 domains with about 4000 mailboxes.
>
> All systems are based on the original Qmail-1.03, with the standard
> patches, and all run on a single UID, based on Paul Greggs howto:
Whatever you define as "standard patch". Beware that things (can)
differ between the "big" patches.
> https://pgregg.com/projects/qmail/singleuid/
Assuming this means that you are using qmail's user mechanism through
users/assign. No need to start from scratch with eQmail.
>
> Spamfiltering is done in front of Qmail, with assp. So no hookups
> needed
> for this. (assp listens to port 25, qmail to port 125)
>
> Ezmlm is also in use.
Beware of the user-ext delimiter before compile. However, ezmlm is an
extension which can be replaced by an alternative (I prefer mlmmj).
>
>
> Because of the several patches the last years (some have TLS, other
> IPv6, some both, some none of these), we want to make a new fresh start
> with compiling qmail on our servers.
> Our systems are mixed-OS's, most run on Slackware, some of them on
> CentOS, so I want to compile the things myself.
Any (modern) linux is fine to compile. For the BSD's some things differs
a bit. Btw, I have no interest to support historical operating systems
running in the basement of some guys.
>
>
> Which package should we follow?
> eQmail, s/qmail, or are there others?
>
> Any tips are welcome.
Maybe you will have a look at my eQmail road map:
https://blog.dyndn.es/doku.php/blog/2015/06/18_my_eqmail_roadmap (and
around)

regards
Kai
>
> Best regards,
> Pascal Nobus

I really like the eQmail-package, and certainly it's style.
We are certainly looking to use Qmail for just MTA, other things can be
better done with specialized programs.
We are using
- Dovecot/mysql for IMAP/Pop which really works fine.
- ASSP for spamfiltering
- AuthSMTP is on seperate servers (Postfix)

The only thing I "miss" is SRS.
We patched two servers once, but on both qmail-local occasionly crashed.
I never had time to investigate it further, so we don't use it for now.
However this still breaks SPF and so causing bad reputation for our
outgoing SMTP-servers.
I don't see an SRS-patch in eQmail nor s/qmail.
It is in indimail-mta, but to me indimail depends a little bit to much
on rpm's. Building Indimail ourself is patching again, and that's what
we don't want anymore.


Are there plans for an SRS-patch in eQmail or s/qmail?





Op 22-04-16 om 16:16 schreef Kai Peter:
> Spoilt for choice? My suggestion: use eQmail! ;-)
>
> No truly, I'm wondering that there is no more response to your question.
> I see eQmail like the mentioned but never released netqmail-1.07. I made
> it cause netqmail-1.07 was never released. It includes the really needed
> enhancements only. Any other enhancements have to be done by (3rd party)
> extensions through the API's. This is the responsibility of the admin.
> Means that there will no new functionality added to the original code in
> the future - at least I don't see any reason to do so at the moment. The
> final eQmail-1.09 will be released within the next (2) weeks, so give it
> a try.
>
> It makes the decision may be easier for you if you know where eQmail
> will go in the future. Mainly it will be stripped down by removing some
> overhead. Less code, less risk of bugs. As an example qmail-pop3d will
> be removed from standard installation because of the "Guninski" bug and
> the availability of other/better POP3/IMAP servers. Overall eQmail will
> be a core MTA with improved user (admin) friendliness in the future.
> Code changes will be reduced to fixes in case there will be a need for.
> I will publish a road map after next final release.
>
> I will bundle some of my extensions in my upcoming openqmail suite and
> will add more step by step.
>
> Anyway, you have do decide along your needs, experience and preferences.
> IMHO individual patching haven't to be necessary anymore.
>
> On 2016-04-21 11:00, Pascal Nobus wrote:
>> Since the previous century we are running several mailservers on qmail,
>> serving around 6000 domains with about 4000 mailboxes.
>>
>> All systems are based on the original Qmail-1.03, with the standard
>> patches, and all run on a single UID, based on Paul Greggs howto:
> Whatever you define as "standard patch". Beware that things (can)
> differ between the "big" patches.
>> https://pgregg.com/projects/qmail/singleuid/
> Assuming this means that you are using qmail's user mechanism through
> users/assign. No need to start from scratch with eQmail.
>>
>> Spamfiltering is done in front of Qmail, with assp. So no hookups needed
>> for this. (assp listens to port 25, qmail to port 125)
>>
>> Ezmlm is also in use.
> Beware of the user-ext delimiter before compile. However, ezmlm is an
> extension which can be replaced by an alternative (I prefer mlmmj).
>>
>>
>> Because of the several patches the last years (some have TLS, other
>> IPv6, some both, some none of these), we want to make a new fresh start
>> with compiling qmail on our servers.
>> Our systems are mixed-OS's, most run on Slackware, some of them on
>> CentOS, so I want to compile the things myself.
> Any (modern) linux is fine to compile. For the BSD's some things differs
> a bit. Btw, I have no interest to support historical operating systems
> running in the basement of some guys.
>>
>>
>> Which package should we follow?
>> eQmail, s/qmail, or are there others?
>>
>> Any tips are welcome.
> Maybe you will have a look at my eQmail road map:
> https://blog.dyndn.es/doku.php/blog/2015/06/18_my_eqmail_roadmap (and
> around)
>
> regards
> Kai
>>
>> Best regards,
>> Pascal Nobus
>

On 2016-04-22 17:24, Webservice wrote:
> I really like the eQmail-package, and certainly it's style.
:-)

> We are certainly looking to use Qmail for just MTA, other things can be
> better done with specialized programs.
That's exactly the way I prefer.

> The only thing I "miss" is SRS.
> We patched two servers once, but on both qmail-local occasionly
> crashed.
> I never had time to investigate it further, so we don't use it for now.
> However this still breaks SPF and so causing bad reputation for our
> outgoing SMTP-servers.
> I don't see an SRS-patch in eQmail nor s/qmail.
> It is in indimail-mta, but to me indimail depends a little bit to much
> on rpm's. Building Indimail ourself is patching again, and that's what
> we don't want anymore.
>
>
> Are there plans for an SRS-patch in eQmail or s/qmail?
It is not necessary to patch eQmail. SRS can be implemented like I do in
my qmail-xdkim package through the API's. As I said already, there
should be no need to patch eQmail to add a functionality anymore.

Unfortunately there is no ready-to-use plugin yet. Wouldn't it be a task
for somebody to create such a package?

Kai
----
Sent with eQmail-1.10-dev

Hi Pascal,

after Manvendra and Kai promoted their 'products', let my give you my comment:

a) As Manvendra said: Try and evaluate all three qmail successors.

b) Over the last decades, qmail developed like a garden without gardener.

c) There are tasty fruits and basic fruits which need to be planted.
Three of those I tried to grow up, thus you can harvest those: IPv6, Auth, and TLS (within s/qmail).

d) You seem to have other tastes. I don't know about 'assp', nor about SRS (not yet; SPF is on my list).
Thus, I have no expertise to provide add-ons for any of those (however, this could change).

However, currently I don't see any 'convergency' to join all the activities together into a common platform.
Two give you two examples:

- exim (Phil Hazel) seems to be used like a brick yard (on Debian).
- Postfix (Wietse Venema) is a strong focused project (everywhere).

At first, because we - as developers - like to protect our work; we are all 'egomanes'.
Second, because we simply have too different views on the 'real qmail world'.

What I try to do, is to provide a solid code base (and the right ideas).
Documented, functional, in the spirit of DJB.
I do this partially for my students to teach them how to do things (right).
Minimalistic, no 'stdio', no MySQL, no SASL; OpenSSL is hard to avoid.
Very few dependencies. Working on current systems.

This is my 'philosophy' - which might not coincident with your expectations.

I'am glad, that my enhancements made their way to 'other products' as well.

Again: Your choice. Anyone's choice. Free software. Free to 'mod' it.

I would be happy, if qmail.org (Russ Nelson) would reflect those thoughts.


Best regards.
--eh.


> Am 21.04.2016 um 11:00 schrieb Pascal Nobus <pascal@nobus.be>:
>
> Since the previous century we are running several mailservers on qmail,
> serving around 6000 domains with about 4000 mailboxes.
>
> All systems are based on the original Qmail-1.03, with the standard
> patches, and all run on a single UID, based on Paul Greggs howto:
> https://pgregg.com/projects/qmail/singleuid/
>
> Spamfiltering is done in front of Qmail, with assp. So no hookups needed
> for this. (assp listens to port 25, qmail to port 125)
>
> Ezmlm is also in use.
>
>
> Because of the several patches the last years (some have TLS, other
> IPv6, some both, some none of these), we want to make a new fresh start
> with compiling qmail on our servers.
> Our systems are mixed-OS's, most run on Slackware, some of them on
> CentOS, so I want to compile the things myself.
>
>
> Which package should we follow?
> eQmail, s/qmail, or are there others?
>
> Any tips are welcome.
>
> Best regards,
> Pascal Nobus
>

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





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

On 22 April 2016 at 20:54, Webservice <info@webservice.be> wrote:
> I don't see an SRS-patch in eQmail nor s/qmail.
> It is in indimail-mta, but to me indimail depends a little bit to much
> on rpm's. Building Indimail ourself is patching again, and that's what
> we don't want anymore.

indimail-mta uses git for source code control and is available as
source at https://sourceforge.net/p/indimail/code/ci/master/tree/qmail-1.03/.
Building indimail-mta is not patching.In fact the patch is generated
in the build process by doing a diff -Naur between indimail-mta source
directory and qmail-1.03 source directory

The patch is available for the qmail community, who over the years,
have become so accustomed to applying patches, that they have
forgotten the convenience of building a source code without patches :)

You need exactly 4 source code to build indimail-mta - indimail-mta
source code above, ucspi-tcp, libdkim and libsrs2 soruce listed below
https://sourceforge.net/p/indimail/code/ci/master/tree/ucspi-tcp-0.88
https://sourceforge.net/p/indimail/code/ci/master/tree/libdkim-1.4
https://sourceforge.net/p/indimail/code/ci/master/tree/libsrs2-1.0.18

Just a post to give my findings about replacement of a running
qmail-1.03 system.


First I tried to install eQmail, however I bumped into ipv6 and
SSL-support for tcp-server, and insteadoff patching it myself, I
downloaded it from fehcom.
And when I was there I took a short look at the doc's about s/Qmail.
After reading this I thought: just give it a try.

And well, I had a deamontool/tcpserver/qmail with IPv6 SSL running in 10
minutes!
I copied over my users,virtualdomains,rcpthosts, and the base was fine.


After that I had to install some other tools I needed:
- qtools + patch (to make filter_to which I use in .qmail-files)
- bglibs, qmail-autoresponder
- unbound (new caching dns-server insteadoff djbdns)
- qmail-control-script (to stop/start/view queue, purge queue)


The only thing I struggled with was qmail-mrtg, first mrtg-setup (the
damned gd-problem again, I'm on slack so I have to compile it from
source), and then the lack of documentation, so I downloaded the old
qmail-mrtg-package and read the source.


Because s/qmail did went so fine, I didn't try indimail (so I can't tell
if it's good or bad). Nor smtp-auth is installed (will give it a try
later on).
I'll maybe take a look at eQmail indimail again on some other servers,
but I really liked the smooth s/qmail-setup.
I've been running now for 1 week in test mode, and 1 day in normal load.
Had no crashes and TLS is working fine.

Erwin: thx for the great job you already did.
Kai/Manvendra: I'll have to test your products further.

The real + of s/Qmail to me is that is compile all the things you
basicly need, it's up to you if you use it or not.
Erwin: why is there still a pop3 and authentication build in? Most
systems use IMAP now for default, and there are great servers for that
(Dovecot p.e.) which also do pop and authentication.


Best regards,
and keep up the good work.

P.S.
Why not bundle your works eQmail s/Qmail and Indimail in one project?
If you bundle your strength you could be the leader in MTA, replace the
awfull (my personal opinion) exim/postfix.

I want to thank you for your response overall.

> First I tried to install eQmail, however I bumped into ipv6 and
> SSL-support for tcp-server, and insteadoff patching it myself, I
> downloaded it from fehcom.
ucspi-* is a separate package and not part of eQmail :-(

> P.S.
> Why not bundle your works eQmail s/Qmail and Indimail in one project?
> If you bundle your strength you could be the leader in MTA, replace the
> awfull (my personal opinion) exim/postfix.
Hmm, that's a strange point. Always IMHO:

Overall it will be hard to reanimate (net)qmail to growth in public
attention again. There is a (hard) core of users, but most of the main
distributions didn't provide/assist (net)qmail as a package anymore. Why
ever, there were a lot of mistakes made in the past. I question if this
can be corrected. At the moment I would say (net)qmail is dying slowly
but continuously.

I couldn't say a lot about s/qmail or indimail. eQmail is one of
multiple private forks using popular patches and some individual
changes. Just published more successful. On the other side this shows
that there is still an interest. Back, differences in short:

- s/qmail is academic, not what I want as administrator
- indimail is leading in up-to-date functionalities and its history
- eQmail is minimalistic, less (should be) is more (its like I wanted to
se netqmail-1.07)
- other derivatives of (net)qmail with lesser attention differs minimal

Getting the work of Erwin, Manvendra and me together is not enough. The
community have to contribute too. Starting with feedback, wishes and
expectations. Former and new contributors. Than it will make sense to
think about a coordinated project.

Just some high level thoughts. Keep in mind: IMHO!

--
----
Sent with eQmail-1.10-dev

On 13 May 2016 at 22:05, Pascal Nobus <pascal@nobus.be> wrote:
> Just a post to give my findings about replacement of a running
> qmail-1.03 system.
>
>
> First I tried to install eQmail, however I bumped into ipv6 and
> SSL-support for tcp-server, and insteadoff patching it myself, I
> downloaded it from fehcom.
> And when I was there I took a short look at the doc's about s/Qmail.
> After reading this I thought: just give it a try.
>
> And well, I had a deamontool/tcpserver/qmail with IPv6 SSL running in 10
> minutes!
> I copied over my users,virtualdomains,rcpthosts, and the base was fine.
>

I have myself taken a look at s/qmail. Dr Erwin writes code well and
in the same style as DJB. I have shamelessly integrated his code in
indimail. QHPSI was his first work that I really liked. Unlike other
virus scanning interfaces, QHPSI does the scanning inline. i.e. It
scans the email while qmail-queue is reading the data from
qmail-smtpd. There is no additional disk I/O it incurs.

> After that I had to install some other tools I needed:
> - qtools + patch (to make filter_to which I use in .qmail-files)
> - bglibs, qmail-autoresponder
> - unbound (new caching dns-server insteadoff djbdns)
> - qmail-control-script (to stop/start/view queue, purge queue)

qtools, qmail-autoresponder are already packaged with indimail-mta and
indimai. indimail-mta/indimail has a modified qmail-qread to list
queues like qmHandle and qmail-rm to purge the queue.

> Because s/qmail did went so fine, I didn't try indimail (so I can't tell
> if it's good or bad). Nor smtp-auth is installed (will give it a try
> later on).
> I'll maybe take a look at eQmail indimail again on some other servers,
> but I really liked the smooth s/qmail-setup.
> I've been running now for 1 week in test mode, and 1 day in normal load.
> Had no crashes and TLS is working fine.
>
> Erwin: thx for the great job you already did.
> Kai/Manvendra: I'll have to test your products further.
>

If you want to try indimail, you should be trying indimail-mta instead
of indimail. indimail-mta includes qmail + all patches, daemontools +
ucspi-tcp, tls, ipv6, dkim, srs, spf, etc. indimail is a huge package
which includes courier-imap, virtual domain using MySQL as backend and
many other tools

To be honest, I have not been good at documentation and users may find
it difficult to build it from source. But the git repo is there and
all it requires is make; make install (not make setup check like
qmail). An easy way to try out indimail-mta is to use the docker
images at (assuming you know about docker and have the docker-engine
installed on your machine)

http://indimail.blogspot.in/2016/04/using-docker-engine-to-run-indimail.html

> Why not bundle your works eQmail s/Qmail and Indimail in one project?
> If you bundle your strength you could be the leader in MTA, replace the
> awfull (my personal opinion) exim/postfix.

This is a good suggestion. Willing to give it a try but not sure how
to take this forward. Maybe it requires someone to play the role of a
facilitator bring us all together and drive it as a project with
concrete goals.

On Fri, Apr 22, 2016 at 9:16 AM, Kai Peter <kp@lists.openqmail.org> wrote:

> Spoilt for choice? My suggestion: use eQmail! ;-)
> Any (modern) linux is fine to compile. For the BSD's some things differs a
> bit. Btw, I have no interest to support historical operating systems
> running in the basement of some guys.


So, instead you're maintaining a version of an ancient MTA that most
consider to have been long since obsoleted by postfix and others? this
attitude makes no sense. What's the issue with supporting FreeBSD/NetBSD?
Lack of testers?

I was considering eQmail until I read this message; I use a combination of
Linux, FreeBSD, NetBSD, and SmartOS. I'm not trying to start an OS fight
here, but what's your meterstick for determining an operating system is
"historical" and "running in the basement" ?

If you've made a Linux-only qmail variant, you've taken away most of the
appeal of qmail for me. Not only that, but not testing it on other unix
variants sounds like laziness and unwillingness to write portable code.


Sean

>> Any (modern) linux is fine to compile. For the BSD's some things
>> differs a bit. Btw, I have no interest to support historical
>> operating systems running in the basement of some guys.
>
> So, instead you're maintaining a version of an ancient MTA that most
> consider to have been long since obsoleted by postfix and others? this
> attitude makes no sense. What's the issue with supporting
> FreeBSD/NetBSD? Lack of testers?
Ancient was meant for systems like IRIX or HP-UX, not for BSD's.

Hi together,


On Sat, 14 May 2016 13:03:41 +0200, Kai Peter <kp@lists.openqmail.org> wrote :


> Overall it will be hard to reanimate (net)qmail to growth in public
> attention again. There is a (hard) core of users, but most of the main
> distributions didn't provide/assist (net)qmail as a package anymore. Why
> ever, there were a lot of mistakes made in the past. I question if this
> can be corrected. At the moment I would say (net)qmail is dying slowly
> but continuously.

Still there is a substantial user base out there - but the current qmail is hard to maintain for the
the current SMTP and privacy requirements.


> Back, differences in short:
>
> - s/qmail is academic, not what I want as administrator
> - indimail is leading in up-to-date functionalities and its history
> - eQmail is minimalistic, less (should be) is more (its like I wanted to
> se netqmail-1.07)
> - other derivatives of (net)qmail with lesser attention differs minimal
>
> Getting the work of Erwin, Manvendra and me together is not enough. The
> community have to contribute too. Starting with feedback, wishes and
> expectations. Former and new contributors. Than it will make sense to
> think about a coordinated project.
>
> Just some high level thoughts. Keep in mind: IMHO!

Let's add some more thoughts:

a) In order to stay tuned with current Internet developments, we need developers checking the
upcoming RFCs, perhaps writing patches to include those, checking other peoples
contributes.

b) MY personal contribution was to include a rock-solid IPv6 implementation working for both
Linux and BSD (at least) because these two stacks are different. Further, I took the chance to
jump on the train for TLS encryption and provide some High-Level APIs together with UCSPI-
SSL. Remember: This architecture prevented any potential Heartbleed victim at least not to
disclose the users's passwords.

c) Integration into different OS is still a battle. At least we need to consider *BSD, Debian,
perhaps Ubuntu and the Rad Hat based (rpm) systems like SuSE (in Germany). Actually --
according to a) -- wie need specialist in that field. I made the attempt to use DJB's
slashpacket convention; but not everyone welcomes this.

In order to maintain a long haul (valid) version of qmail (or any successor) we need to talk
about architecture:

d) qmail is (disk) I/O bound. I just had an user running out of 1024 file descriptors for qmail-
send. This is coupled with the way qmail deals with message storage identified with inode
names in the queue. My long term aim is to use more flexible UUIDs instead, allow a 'real'
distributed queue and in addition encryption of the queue.

e) qmail-remote is CPU bound for outgoing TLS connections: Each message is one delivery;
no pipelining. Which means one TLS handshake each. This is sub-optimal and needs to be
addressed together with d).

f) In s/qmail (3.1) I made the attempt to integrate Recipient verification and User
Authentication. However; I just provide the APIs and some PAMs. A good solution is of vital
importance for any current MTA.


Apart from my 'academic' research, I do see the need that not only to identify the required
resources but also find specialists really doing the integration. Unfortunately, Russ Nelson's
qmail site was never the place to be.

---

This was my talk regarding the developers. What's next: Setting up a particular web-site?
Scheduling a nice-to-meet-you conference? Any volunteers?

---

Now some word to potential users(updaters: Please try out the different solutions! Today,
regarding VMs, it is cheap to setup a well-maintained qmail-successor package (I hope at
least) and compare those.

Best regards.
--eh

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

In linux most packages are distributed as rpms; packages providing
additional functionality also come that way making maintenance easier.
Additional configuration should be well structured. A good example
being Apache. Qmail, somehow, never took that route. That is why it
takes a specialist to use qmail and they are invariably in short
supply.

-C

Hi chitta,


On Sun, 15 May 2016 15:04:28 +0530 (IST), chitta@iitkgp.ac.in wrote :

> In linux most packages are distributed as rpms; packages providing
> additional functionality also come that way making maintenance easier.

Hm. Never heard of *.deb packages ? And the following formats:

https://en.wikipedia.org/wiki/Package_format


> Additional configuration should be well structured. A good example
> being Apache. Qmail, somehow, never took that route. That is why it
> takes a specialist to use qmail and they are invariably in short
> supply.

Actually, qmail *was* packaged as rpm (together with my Spamcontrol)* ) but the maintainer
left or does not follow up it anymore.

It is the shortage of maintainers, in the first place.

Actually, I've seen cases, where the maintainer messed up the sources while providing some
'combined' patches.


regards.
--eh.

*) Hey, this would be an additional thought and input for the qmail history web-site.

On 2016-05-15 11:34, chitta@iitkgp.ac.in wrote:
> In linux most packages are distributed as rpms; packages providing
> additional functionality also come that way making maintenance easier.
> Additional configuration should be well structured. A good example
> being Apache. Qmail, somehow, never took that route. That is why it
> takes a specialist to use qmail and they are invariably in short
> supply.
>
> -C
AFAIR the original license didn't allow to distribute qmail as binaries.
Some distros have had packages later on. They removed them - may be
because a lack of maintenance. FreeBSD and Gentoo have still a netqmail
package in their repos. Anyhow, creating packages from sources should be
the job of the package maintainers of their distro.
--
----
Sent with eQmail-1.10-dev

>> Just some high level thoughts. Keep in mind: IMHO!
>
> Let's add some more thoughts:
The truth is in the middle - always. Let me add some points for open
discussion:
>
> a) In order to stay tuned with current Internet developments, we need
> developers checking the
> upcoming RFCs, perhaps writing patches to include those, checking other
> peoples
> contributes.
The most important thing: coordination! I see RfC sometimes critical,
e.g. djb decided not to implement the DSN RfC. RfC's can be interpreted
different too or they are not absolutely clear written. This doesn't
mean to ignore them.

>
> b) MY personal contribution was to include a rock-solid IPv6
> implementation working for both
> Linux and BSD (at least) because these two stacks are different.
I wouldn't mix packages, so IPv6 should be on the remote of X-qmail
only.

> Further, I took the chance to
> jump on the train for TLS encryption and provide some High-Level APIs
> together with UCSPI-
> SSL. Remember: This architecture prevented any potential Heartbleed
> victim at least not to
> disclose the users's passwords.
IMHO there are too many "ucspi" packages: -tcp, -ssl, -ipv6 (and a
patch), -unix. I think a consolidation would make sense. Otherwise the
usage of xinetd is an alternative too. This shouldn't be ignored. How to
do SSL/TLS with xinetd?

Heartbleed was yesterday and it was a openssl bug. This is fixed. I'm
not really happy with openssl but I don't see an alternative at the
moment. I think djb was right that we should put attention to tomorrows
bugs/security leaks.
>
> c) Integration into different OS is still a battle. At least we need
> to consider *BSD, Debian,
> perhaps Ubuntu and the Rad Hat based (rpm) systems like SuSE (in
What's about Gentoo? As you mentioned Ubuntu - what's about Mint? There
are more. I pointed this out already: creating packages for distribution
is not a task of the developers.

> Germany). Actually --
> according to a) -- wie need specialist in that field. I made the
> attempt to use DJB's
> slashpacket convention; but not everyone welcomes this.
I like slashpackage. It can make systems cleaner. Otherwise I wouldn't
use it to separate every package.

>
> In order to maintain a long haul (valid) version of qmail (or any
> successor) we need to talk
> about architecture:
>
> d) qmail is (disk) I/O bound. I just had an user running out of 1024
> file descriptors for qmail-
> send. This is coupled with the way qmail deals with message storage
> identified with inode
> names in the queue. My long term aim is to use more flexible UUIDs
> instead, allow a 'real'
> distributed queue and in addition encryption of the queue.
What's wrong by using functions provided by the OS (disk I/O)? The user
will run out of 10000 fd's too. Beside - how many (so called) admin's
have knowledge about resource management (memory, fd's) as of today? I
wouldn't put to much attention on this (from developers side), as it
looks like a admin issue.

>
> e) qmail-remote is CPU bound for outgoing TLS connections: Each
> message is one delivery;
> no pipelining. Which means one TLS handshake each. This is sub-optimal
> and needs to be
> addressed together with d).
I agree that the "remote" side could need some improvements - however,
this isn't high prio.
>
> f) In s/qmail (3.1) I made the attempt to integrate Recipient
> verification and User
> Authentication. However; I just provide the APIs and some PAMs. A good
> solution is of vital
> importance for any current MTA.
I use your authentication patch with success. But at least I have made
my way of authentication and preventing backscattering.
>
>
> Apart from my 'academic' research, I do see the need that not only to
> identify the required
> resources but also find specialists really doing the integration.
> Unfortunately, Russ Nelson's
> qmail site was never the place to be.
> @Erwin: Please don't interpret 'academic' as negative in any case. Some
> things I like, some things I would do/see different.

With all respect, I won't wait for any of the former "qmail big one's".
They are still on the list and I realized that any of them is better
than me regarding to qmail. But as they are seems to be passive - let's
move on.
> ---
>
> This was my talk regarding the developers. What's next: Setting up a
> particular web-site?
I think we need a good discussion platform - better than a website.
> Scheduling a nice-to-meet-you conference? Any volunteers?
Me - if you want to accept.

I hate discussions via mail. It could be led into to much
misunderstandings. At least at long threads. There is never a chance to
point out all nor really accurate. Did I made all accurate?

----
Sent with eQmail-1.10-dev

On Sun, May 15, 2016 at 07:15:08PM +0200, Kai Peter wrote:
> On 2016-05-15 11:34, chitta@iitkgp.ac.in wrote:
> >In linux most packages are distributed as rpms; packages providing
> >additional functionality also come that way making maintenance easier.
> >Additional configuration should be well structured. A good example
> >being Apache. Qmail, somehow, never took that route. That is why it
> >takes a specialist to use qmail and they are invariably in short
> >supply.
> >
> >-C
> AFAIR the original license didn't allow to distribute qmail as
> binaries. Some distros have had packages later on. They removed them
> - may be because a lack of maintenance. FreeBSD and Gentoo have
> still a netqmail package in their repos. Anyhow, creating packages
> from sources should be the job of the package maintainers of their
> distro.

Public domain since 2007, nearly ten years though so this shouldn't
apply now.

I think the problem is that most distros have a mailer of choice now, so
switching to something different is likely to upset their user base.
Including a patched qmail in binary form should be possible if someone
wishes to maintain it.

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

On 15 May 2016 at 15:04, <chitta@iitkgp.ac.in> wrote:
> In linux most packages are distributed as rpms; packages providing
> additional functionality also come that way making maintenance easier.
> Additional configuration should be well structured. A good example
> being Apache. Qmail, somehow, never took that route.

qmail uses hardcoded uid/gids generated during make. This makes it
unsuitable to deploy RPM/debs. You also cannot backup the binaries and
restore it on another machine, unless the qmail users and groups are
exactly the same as that on the machine where the qmail binary was
compiled.
This problem was solved in indimail-mta / indimail. Also
indimail-mta/indimail does not use hardcoded directories e.g.
/var/qmail/control, /var/qmail/queue gets replaced by environment
variables CONTROLDIR, QUEUEDIR. I use build.opensuse.org to generate
the RPMs and debs and all my production machines use yum/dnf/apt-get
to install/update indimail-mta

> That is why it
> takes a specialist to use qmail and they are invariably in short
> supply.
>
qmail is far easier to administer than sendmail and postifix. No crazy
syntax. Just plain simple text files in /var/qmail/control. Just
follow the excellent guide LWQ from Dave Sill.

Hi,


On Mon, 16 May 2016 22:48:16 +0530, Manvendra Bhangui <mbhangui@gmail.com> wrote :

> qmail uses hardcoded uid/gids generated during make. This makes it
> unsuitable to deploy RPM/debs. You also cannot backup the binaries and
> restore it on another machine, unless the qmail users and groups are
> exactly the same as that on the machine where the qmail binary was
> compiled.

Yes, and with s/qmail it is solved by means of the /package installation tools.
I guess, Dan - at that time - had GUID and GGID settings in mind.

>
> > That is why it
> > takes a specialist to use qmail and they are invariably in short
> > supply.
> >
> qmail is far easier to administer than sendmail and postifix. No crazy
> syntax. Just plain simple text files in /var/qmail/control. Just
> follow the excellent guide LWQ from Dave Sill.

Ack. Within s/qmail I follow that path; though unfortunately, in particular TLS settings can be
quite complicated. What I try to do, is to maintain precise man pages.

regards.
--eh.

Hi,

for my understanding, the different packages of Apache are a mess.
You have to learn the configuration for any distribution (in particular Debian).

Sorry.

regards.
--eh.

On Sun, 15 May 2016 15:04:28 +0530 (IST), chitta@iitkgp.ac.in wrote :

> In linux most packages are distributed as rpms; packages providing
> additional functionality also come that way making maintenance easier.
> Additional configuration should be well structured. A good example
> being Apache. Qmail, somehow, never took that route. That is why it
> takes a specialist to use qmail and they are invariably in short
> supply.
>
> -C
>
>
>

On May 17, 2016 2:05 AM, Erwin Hoffmann <feh@fehcom.de> wrote:

Hi,

> for my understanding, the different packages of Apache are a mess.
> You have to learn the configuration for any distribution (in particular Debian).

Rather than the specific configuration details, I was referring to the mechanism of a configuration directory where files for various components can be dropped or removed.

-C

* Erwin Hoffmann <feh@fehcom.de> [2016-05-15 11:13]:
> Still there is a substantial user base out there

yes.

Let's face it: new qmail installs are a rare exception.

> b) MY personal contribution was to include a rock-solid IPv6 implementation working for both
> Linux and BSD (at least) because these two stacks are different. Further, I took the chance to
> jump on the train for TLS encryption and provide some High-Level APIs together with UCSPI-

the network APIs are all well defined and not OS specific at all.

writing portable code isn't the black magic you make it sound.

once you stop relying on the idiotic "embedded v4"-adressing, there is
little (should be nothing, really. well. should.) to care about.

TLS is a nightmare.
openssl has APIs designed to drive the consumers insane (they provoke
bad bugs)
gnutls is a bad joke
libressl's libtls API is much better, but very young and probably not
widepread enough yet

> c) Integration into different OS is still a battle. At least we need to consider *BSD, Debian,
> perhaps Ubuntu and the Rad Hat based (rpm) systems like SuSE (in Germany).

no. POSIX. period.

and things like file system locations are up to the packagers anyway.

> I made the attempt to use DJB's slashpacket convention; but not everyone welcomes this.

well, the world at large is better off without "I need to reinvent the
wheel again" slapshpackage alike attempts.

> e) qmail-remote is CPU bound for outgoing TLS connections

you better profile.
hint: it isn't. not even close.

to be honest, I consider that wasted effort. the world moved on. qmail
was extremely important at its time, but isn't worth the effort since
it is a) way too different which makes it way too hard to audit and b)
its architecture was sane in '98 - but plain doesn't cut it 15 years
later. This is fundamental and basically unfixable without turning
qmail upside down.

qmail's place is largely in the history books now. qmail brought the
concept of privilege seperation - even if it wasn't labeled so - to
us. Not just MTAs, qmail was one of the first visible bits ever, with
great influence to everything after. Again, not just MTAs.

Today, who's still using qmail? Two groups, imho:
1) large deployments effectively using their own fork
2) a couple of freaks that can't let go :)

the first group doesn't need a nicely packaged MTA; they have forked
anyway.

the second will probably never agree on direction.

--
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/VPS, Application Hosting

On 2016-05-16 19:18, Manvendra Bhangui wrote:
> qmail uses hardcoded uid/gids generated during make. This makes it
> unsuitable to deploy RPM/debs. You also cannot backup the binaries and
> restore it on another machine, unless the qmail users and groups are
> exactly the same as that on the machine where the qmail binary was
> compiled.
I don't think this is absolutely correct and could led into
missunderstandings. And package maintainers of a distro should be able
to handle these UID/GID's.

> This problem was solved in indimail-mta / indimail. Also
> indimail-mta/indimail does not use hardcoded directories e.g.
> /var/qmail/control, /var/qmail/queue gets replaced by environment
> variables CONTROLDIR, QUEUEDIR. I use build.opensuse.org to generate
> the RPMs and debs and all my production machines use yum/dnf/apt-get
> to install/update indimail-mta
This is a great improvement indeed.

----
Sent with eQmail-1.10-dev

On 17 May 2016 at 22:00, Kai Peter <kp@lists.openqmail.org> wrote:
> On 2016-05-16 19:18, Manvendra Bhangui wrote:
>>
>> qmail uses hardcoded uid/gids generated during make. This makes it
>> unsuitable to deploy RPM/debs. You also cannot backup the binaries and
>> restore it on another machine, unless the qmail users and groups are
>> exactly the same as that on the machine where the qmail binary was
>> compiled.
>
> I don't think this is absolutely correct and could led into
> missunderstandings. And package maintainers of a distro should be able to
> handle these UID/GID's.

qmail-1.03 Makefile has a target for auto_uids.c. This is generated by
auto-uid binary by getting the uid, gid from /etc/passwd and
/etc/group. The auto_uids.c has uids/gids from the source machine's
/etc/passwd and /etc/group. If you transfer the binaries to a
different host with qmail system users with different uids and gids,
six binaries, listed below do not work. You have to use the idedit
program to correct it.
IMHO quite complicated for a mortal like me :)

# Files are edited in the installation directory, then copied.
# There are 40 arguments to idedit after the filename,
# showing the positions of each byte in the following ten ints:
# uida, uidd, uidl, uido, uidp, uidq, uidr, uids, gidq, gidn.
# Normal little-endian positions are n n+1 n+2 ... n+39 for some n.
# Normal big-endian positions are n+3 n+2 n+1 n n+7 ... n+36 for some n.

setup:
mkdir /var/qmail
./idedit install-big XXX
./idedit qmail-lspawn XXX
./idedit qmail-queue XXX
./idedit qmail-rspawn XXX
./idedit qmail-showctl XXX
./idedit qmail-start XXX
./install-big
cp /var/qmail/boot/binm1+df /var/qmail/rc
chmod 755 /var/qmail/rc
echo '|fastforward -d /etc/aliases.cdb' > /var/qmail/alias/.qmail-default
chmod 644 /var/qmail/alias/.qmail-default
hostname | grep -q '\.'
./config-fast `hostname`

--
Regards Manvendra - http://www.indimail.org