The DynDN.eS Blog

About DynDN.eS, eQmail, Gentoo & some other network stuff

User Tools

Site Tools


After eQmail-1.09

What was started with applying some patches over netqmail-1.06 was growing to a more or less complex project. Adjusting some patches led into code analysis and further into the one or another source code change. Nothing really significant but to reach more robustness, fault tolerance. While doing this there was pointing out the cognition that the last line of netqmail's TODO file is truly more important as it seems: rewrite anything from scratch.

It wasn't planned initially, but as deeper I get familiar with the code as more I was wondering how things were be done. Not talking about the missed maintenance which leads into a patch anarchy for needed functionality. More that it seems like some things are not really finished. About reason(s) I can speculate only, but it is understandable that people moved away from (net)qmail. It is like it is.

Nevertheless I like the basic concept of qmail. eQmail-1.09 has the required basic functionality as of today and can be extended further through existing interfaces. So - at least at the moment - there is no need to do more changes at the code (may be except the domainbindings feature). I won't compare me with the authors of (net)qmail and derivatives. I won't compare me with authors of patches and other contributors. I see them all at a higher level than me in general, but sometimes I do not recognize a valid reason for me why things have been done like that.

As outcome there seems to be no other way to me as to go on with eQmail ;-) and the openqmail suite :-). What are the future tasks?

Code Re-factoring

This will include to build a new structure of source code (reorganization), strip down the sources (remove unneeded stuff), consolidate code (especially libraries), increase automation (install process), not to forget to made the sources more consistent in itself.

Reorganization

  • Put header files into an  inc  sub-folder
  • Put source code which isn't qmail specific into a sub folder, e.g.  lib 
  • Put man pages into  man/{1,3,5,7,8}  sub folder(s)
  • Put docs into the  doc  sub folder
  • use more sub folders if necessary

Overall the “djblibs” have to be separated from the “qmail code”.

Remove obsolete Code

Some examples only (there is more):

  • remove  qmail-pop*  code - there are enough over POP3 servers available and - isn't IMAP a better solution? (Btw: the Guninski bug!)
  • some files are never used nor installed like  idedit  ,  qmail-upq 
  • Is there anyone who uses  qbiff  ,  pinq  (and/or similar tools) or  maildirwatch  ?
  • Was a seperate  hostname{.c)  really needed in 1998?
  • strip down the Makefile
  • most of the “try” code is obsolete on supported (actual) systems or can be done easier by a shell one liner

Consolidate Files

I don't want to make my own fork of “djblibs” nor it is planned to use this partially undocumented stuff in other projects - so some files can be consolidated, e.g. putting  open_*.c into a file  open.c . Only to mention it: there are some forks of “djblibs” out, most common libowfat (I believe :-)).

Against consolidation there should/will be several Makefiles inside sub folders.

More Automation

The whole install routine - written in C - could be replaced by a shell script for better readability, maintenance and extensibility. More automation should be done for qmail system users ( mkusers  script), creating default aliases and others.

The Code Re-Factoring Process does not include new code changes - it is a reorganization only!

Source Code Improvements

Some things have to be done here. One example is to correct the usage of vfork() - thanks to Rolf Eike Beer for pointing this out. The interfaces for plugins needs to be reviewed too. The goal is to improve them to use multiple plugins in a more easily configurable way.

An improvement is also to replace e.g.  qmail-qstat  by Michele Bertrame's  qmHandle .

Another point is to reach more (C99) standard conformity, e.g. in substdio functions. However, the timeline for this is vague. Another thought is to switch from substdio to buffer.

New Features?

New features will be available as plugins (only?) in the future, bundled in the openqmail suite too. Still, each plugin keeps its independence. One example is qmail-xdkim, another is may be qmail-chkpw. Just as a preview - I'm in charge of some other stuff:

  • central administration of users for qmail and courier-imap from one source, through a webinterface too
  • optimized bounce handling (e.g. check outgoing mails is a bounce, limit bounces)
  • recipient validation without extra maintenance

and some other stuff. Badly that none of these stuff is ready to publish it yet, because it is written quick and dirty - really. May be one of the next steps is to publish some existing recommended plugins. Another important task is to do more documentation, including manual pages.

Conclusion

eQmail will go in a direction which is oriented on the real needs of administrators. And keep their freedom to decide what they want to install and use. Means that the main focus is put to be easy maintainable and (individual) extendible. As an side effect, applying existing (net)qmail patches will require more knowledge of what have to be done as before. But shouldn't we go in the direction to avoid individual patching?

Any feedback and comments are highly appreciated. Nevertheless I would like to see and do discussions on the openqmail mailing list ;-).

Comments