A modern mail transfer agent suite around eQmail
openQmail is a suite, or call it container, including a number of tools which are separate but tuned to work simply together. The core is eQmail, forked from netqmail 1.06 with some extensions. netqmail itself is an enhancement of djb's qmail, including a few very conservative patches.
Browsing the internet will show up two extremely opposite positions, each of them are represented by well educated and experienced UNIX developers which knows their stuff. One are the (often) so called qmail enthusiasts, the others are the people who don't like qmail and/or djb's stuff at all - I won't call them haters . As of any thing there are two sides of a coin always, it is not really hard to define pros or cons for each of these positions. As one result, the enthusiasts withdrew from the public and taking to most their knowledge, followed by the users who needs their experience and moved to other email solutions. As result the popularity and usage of (net)qmail decreases. Some distributors removed (net)qmail from their package trees.
(net)qmail doesn't fit the requirements of an email solution of today out of the box. Good news are that for nearly any requirement there is a solution - a patch - available. Bad news are that the patches in most cases heavily conflicts together. Overall a very unsatisfied situation was reached. The root causes seems to be - after djb did stop publishing software in round about 2000 - a restrictive license policy which by itself prevented a new, central coordination by other people to do further improvement. So a lot of individual, partial, duplicate solutions - patches - were originated. The situation was deadlocked as qmail 1.03 was new licensed and put in public domain.
Now, at this point, openqmail takes its place. Against the base - netqmail 1.06 - new code (patches) was and will be implemented for some very important requirements only, as there are authentication, encryption and standards conformity. Any other - lets say individual - requirements have to be flexible integrated through a plugin API. This keeps the choice of what to use by the target group - which functionality to use as well which (external) program(s) should do it. Seen this as the fourth requirement, openqmail provides three plugin API's by default. Thus let us define the primary target group of openqmail - experienced users and (real) administrators.
openQmail stays in the tradition of UNIX programming and culture - at least it tries to do so. Thus it also stays in the tradition of (net)qmail too. Some points, freely interpreted, are:
Not all of these points are reached full yet. But openQmail as a suite of separated, independent components will be improved continuously. The components can be used with other qmail derivatives too and will keep their behavior. Especially with the provided plugin API's there is an easy way to do extensions without changing the source code. Thus reduces the risk of bugs of new code/patches and is another point of security. And stay by with security, the original design of qmail is - compared with other mailers - quite good.
openQmail overall tries to make life of users easier. Instead it is may be of interest what openQmail stands NOT for. It is easier than (net)qmail, but still not easy to install and configure. Some knowledge how internet mail works have to exists. This applies to all parts. Another important point is, that openQmail never will have code included to support incorrect implementations of software. Nor will have workarounds against violations of absolutily clear standards.
openQmail stands for independence always. It provides plugin API's, but will never include or depend to build on third party tools. Using third party software is ok and wanted, depending on it it is not. The only exception of this rule is openssl, as far TLS will be build in. It have to be mentioned that some extensions use third party tools, but they are exchangeable and not required to build the base system. For sure, a UNIX like operating system with its standard tools is a requirement too. Nevertheless this doesn't mean, that openQmail have to run on out-dated, proprietary UNIX OS's out of the box, nor that it is or will be supported on such systems by default. Typically examples of such OS's are IRIX or HP-UX. The focus is put on actual linux and BSD systems.
The core of openQmail - eQmail - is (and will be further) stripped down by out-dated, unneeded stuff. The question behind this decision was: What makes sense and what not? This applies to coding principles as well to some functionality which is not necessary of a mta.
Everybody who can accept or respect this is invited and welcome to participate to openQmail.