eQmail development - an intermediate result

Mid 2016. It's like the fever raises high and higher . I can't let go - ok, I don't want it too. It was simply started by patching netqmail sources and save the changes for individual use. It was followed by using additional patches and made some little changes. As of now it is looking like a (partial) re-write of the sources. And it is going on. Overall it is not the question of sense for me, it is the challenge - really.

eQmail is still a fork for my personal needs. Nevertheless I believe that others have similar needs - that's why I made it public. But I have had to recognize that the release of eQmail-1.09 wasn't satisfactorily to me as expected. Without going into details: some people run into trouble where I haven't had expected that it could happen on these points. Mostly because a lack of knowledge which I did assume to happen, not of an issue with the eQmail sources. Anyway.

eQmail stays in and keeps the tradition of (net)qmail. Some new(er) features are included to met the requirements as of the time of today. The users should get a package which is easy to install, flexible to configure and easy to maintain. It have to run on today's systems - Linux and BSD. Thus eQmail is NOT anymore a replacement of an ancient, buggy sendmail version. There is an internal impact furthermore: the source code have to be moved to a modern level of programming practice, obsolescent tools have to be removed, some tools have to be replaced by simplified rewrites and new functionalities have to be added (best case through an interface). Or in other words eQmail is actively maintained by keeping the initial design. Still there are external influences, mostly from the direct competitors s/qmail and indimail as well from opensmtpd.

So, where is eQmail staying today? Perhaps for a better understanding it is important to know that I consequently use Maildir, courier-imap, the qmail (mail)users mechanism … - I prefer a clean, consistent configuration w/o exotic features.

Some programs are IMHO outdated:

•  qmail-pod3d ,  qmail-popup  were removed. I don't use POP3 nor do I recommend to use it. If you still want to use it, then there are several POP3 servers available. There is the “Guninski bug” also, which was AFAIK never solved.

•  pinq ,  elq ,  qail  - simple one-liner scripts - were removed after question who uses or needs it as of today anymore.

•  qbiff ,  qsmhook ,  qmail-upq  were removed as they were pretty useless to me (as I wrote this I couldn't remember exactly what they are for ). Never used.

Just to mention it, there are some other programs which I did never use. They will be kept as I think they could be useful for someone in some (rare?) circumstances. An example is  maildir2mbox .

The install routine was completely new written. eQmail has a  configure  and a  install  script now. Btw, this saves ca. 900 lines of (C) code. But most important is that eQmail uses the common way of  configure - make - make install  now.

 qmail-showctl  was replaced by  qmail-shcfg . Some patch authors have ignored the old one too and I didn't want to correct this. The new script is easier maintainable and gives an better (colored ) overview. It is exactly for the needs of eQmail.

 qmail-qstat  was heavily extended, inspired by Michele Bertram's  qmHandle . It shows several statistics of the queue and messages. Individual messages can be deleted. As eQmail has the big-todo queue  qmail-qstat  can handle this type of queue only.

 qmail-fixq  was inspired by  queue-fix  and  queue-repair . Beside that both are not maintained,  queue-fix  sets some incorrect (or different) permissions and  queue-repair  is written in python V1 and doesn't run with python3 anymore.

 mkusers  is a small helper script to create the qmail system users.

As the above affects the end-user, the following is about internals. The original source package of (net)qmail with more than 430 files in one folder was a mess for me. So using subfolders was a initial requirement. The next is not in chronological order.

I consolidated the one-per-file functions of the “djb”libs, e.g. I did put all  byte_*.c\  into  byte.c . On the one hand the several files were compiled to one object file anyway. On the other hand I was able to decrease the Makefile. Usually the source of the libs will never be touched. libs and the related headers are moved into subfolders.

If you compare the original qmail sources with the later package daemontools, you will recognize a progress of development style. There is e.g. the usage of  unistd.h , better declaration of prototypes and updated libraries. With view of the future I up'ed cdb, env, consolidated sgetopt/subgetopt into getoptb (buffer) and replaced substdio by buffer. There are influences by fefe's (Felix von Leitner's) more modern libowfat always.

Most of the try's are eliminated. Some were obsolete, e.g.  tryfork , other's are moved into the  configure  script. Rolf Eike Beer forces me to correct the usage of  vfork() . The integer sizes will be defined through standard header files now. It is a step to reach more POSIX conformity too.

The two most important things are to write more tests (include to extend and automate my testsuite) and to reach a better cross-platform compatibility for Linux and *BSD. This is an ongoing work. Next is to rework the documentation.

But there are some other plans/ideas too:

•  tcpserver  should be integrated into eQmail. As the most preferred tool to use with  qmail-smtpd  I think this have not to be part of a separate package. Before there have to be done some preparatory work to consolidate libraries from  ucspi-tcp .

• The dot-forward tool should be integrated. The (my personal) reason is that I have one situation, where eQmail and another mta deliver into the same destination. The idea is to have a  .qmail  AND a  .forward  file always and eQmail uses both.

• Manvendri Banghui pointed out to not have UID/GID's compiled in fix anymore. I like this idea and want to adopt it. This would improve the possibility to distribute a binary package. I want also have the alias user as part of the qmail users mechanism (by default) by using an unprivileged separate (virtual) UID/GID.

Just as some examples.

So - take it or leave it. But be warned: Once you've taken it you will be captured for ever - may be . Thanks to all who using eQmail.