The DynDN.eS Blog

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

User Tools

Site Tools


The project to consolidate eQmail and s/qmail to aQmail stalls and the last release eQmail-1.10 was published one year ago. So here is eQmail-1.11. It doesn't offer a lot of new features, the development was focused to the qlibs integration. Beside there is one important change in the folder structure inside eQmail's install folder:

  •  control  was renamed to  etc 
  • there are 2 new folders  tmp  and  var 
  • the folders  alias ,  queue  and  users  are moved to (the new) folder  var 

As the new structure doesn't conflict with the old one - even not with derivatives - an upgrade can be done smoothly by simply moving the contents of the old folder to the new ones or even use symbolic links. Beware of the home directory of the *qmail system users too, especially the user alias.

Download: eqmail-1.11 (sha256sum)

eQmail will be discussed on the openqmail mailing list.

More info is available at eqmail website.

Now, eQmail-1.11 doesn't offer a firework of new features. So let me do a review and a look into the future.


Its lack of features makes vanilla qmail a pretty useless MTA of today. The initial license results in a patch anarchy with incompatible patches. Without some programming knowledge it is impossible to apply multiple required patches. Thus it bears the risk in itself to break initial security. But why is qmail considered secure and what makes qmail secure? I question that many people who rely on qmail's security knows about that. Beside the initial design and security thoughts, I think there are 3 main points:

  1. qmail is based on djb's C environment (libraries)
  2. djb did an absolutely consequent error handling
  3. the micromanagement makes the effort of code analyzes very high

I don't want go to deep into details, but just want mention some more thoughts. The libraries around stralloc, byte and others are really great and secure. There are multiple forks, qlibs is one of them. The error handling is straight and efficient. Even if it's partially a bit plain. The third point is a bit more complex.

micromanagement means here the split of the code into many small files. Looking at the relevant qmail code itself it is in general ok - related to the design. But with the libraries the goal was overreached. It increases complexity in multiple cases only, without making things for example more secure. Together with the fact that different of djb's packages uses different versions of his libraries. I can assume it only, but I'm pretty sure that the goal was to not write a function twice. As a fact, there are duplicate functions and duplicate code - even if some functions are published by patch authors.

Where do we stay today?

eQmail includes the most important advantages like TLS/SSL, authentication, the “recommended” patches, full IPv6 support, smtp plugins (qmail-spp) and API's to add additional code by external tools/programs. There are separate modules available, most important for DKIM but as well boot scripts, spf checks and more. With the included tcpserver the Independence from ucspi-tcp is given as well the common usage of daemontools is optional.

However, some features are still not available yet. The actual focus is laid at the consistent integration with qlibs. It doesn't make sense to me to add new features to an “unclean” code. For sure the initial design - even the security - will be kept. But eQmail moves forward also - means some outdated stuff will be removed and/or replaced by up-to-date techniques. (It is on my TODO list to write a recommendation of usage including some background of reasons why to do so compared with alternatives based at this article - whenever.)

Pretty sure that some people will not agree with my thoughts and my way - opinions are different and that's good. Anyway, I will go my way along my experiences. Think progressive.