This thread forces me to re-subscribe to the qmail mailing list and publish eQmail-1.08. After I did some documentation there came up some questions: Should I do eQmail-1.09? Does it make sense? What should be implemented? But before I go on:

All of the following is my opinion and my point of view. I highly respect the work/software of others, but I keep the right to see some things (positive) critical!

To answer the 3 questions above let me start from the back with an actual wishlist:

1. improve installation routine
   • slashpackage format under /usr/local/
   • creation of config file smtpplugins
2. IPv6 functionality in qmail-remote (1.06-ipv6.patch)
3. update tls (POODLE fix) and/or auth * netqmail-1.06-tls-20141216.patch … –> not needed, see here
   • or switch to Roberto's roberto-netqmail-1.06_auth_tls_force-tls.patch-latest
   • –> important for remote auth
4. increase RSA and DH key lengths –> Update: surprisingly Frederik Vermeulen did it in his new patch netqmail-1.06-tls-20151215.patch
5. include qmail-chkpw (cmd5checkpw) (will/can be used by spamdyke too)
6. remove unneeded stuff (e.g. qmtpd and pop3d etc.)
7. domainbindings should work with IPv6 (or replace with outgoingip?)
8. badmailto (perhaps via qmail-spp?)

         –> eQmail should be a code base! (forked)
         –> packages (e.g. vpopmail) have to follow and depend on eQmail, not vice versa
         –> using a plugin API (instead of patches for new functions) - some (most?) people want it

         –> redesign through the used patches
         –> Update of bugs (of patches) ⇒ new release

Recommended packages to use with eQmail (I would say all before courier-imap are essential):

1. daemontools-0.76
2. ucspi-tcp-0.88 with IPv6 (or ucspi-unix by Bruce Guenter?)
3. spamdyke
4. qmail-chkpw (cmd5checkpw)
5. courier-imap
6. qmail-pwrap
7. procmail
8. clamav
9. bmf
10. mlmmj

To answer the 2. question lets see the Pros and Cons of qmail:

• the design (a lot of small programs) is Unix conform
• there are some “individual” special forks, unpublished
  • –> so there is a need for (!), but perhaps slightly different requirements
• patches for (nearly) every needed functionality exists
• more/new functionality can be added quite easy through qmail-spp, wrappers and pipes

• the usage of (net)qmail is decreasing
• 64bit security - was there a review/audit
• no development coordination, no progress for newer features (after RfC821) –> what if updates are needed (POODLE)
• a lot of incompatible patches, duplicate implementations of functionality
• activity of qmail pioneers is decreasing (Charles Cazabon, Russel Nelson, Bruce Gunther, Andre Oppermann, and other patch authors)
• eQmail: 9 downloads, one success feedback –> less interest
• qmail-spp ??? (dead?)
• qmail-toaster (Bill Shupp) and qmailrocks –> dead?
• qmail.org website is out of date, many dead links –> web-presence of qmail is decreasing too

• performance design of qmail is unimportant for actual hardware
• qmail-queue with uid instead inodes
• seems like djb has no interest at qmail anymore (as for his other software too) –> should his software be classified as concept(s)?

• Erwin Hofmann: works on his own s/qmail (alone), together with additional tools (spamcontrol) there is a slow progress, bugs and alpha versions, some things are very useful, others too complicated
• John Simpson: last patch release was 2010, for me more a special privat fork
• Ricardo Puzzanghera: actual website and patches, but anything is patched

There is the problem with updates (of patches) always: every small change will need a new release. Also to get the diffs between patch releases is some work.

As a general idea I tend to reduce patching and using a plugin style structure. Any used program/plugin should be independent by itself and exchangeable on the fly. A good example is spamdyke, which fits perfectly into the qmail pipe. A bad example is the patch chkuser-2.0, because of it's dependency of vpopmail. For this and perhaps some others the qmail-spp seems to me to be a better alternative.

I'm not against patching or code changes overall, but as long a clearly designed API can be used it should be done. I'm sure there are a lot people (users, admins) who would appreciate this. Beside the new requirements since the release of qmail-1.03, people wants to see progress.

At the moment I couldn't say what have to be done really, but to have remote auth is a MUST. Perhaps the “tls-auth” patch could be reverted for qmail-smtpd (if necessary). This has side affects to qmail-spp.

As to provide authentication is a MUST (for incoming connections), I would see 3 2 alternatives:

1. using one of the auth patches (for sure including TLS)
2. a plugin through qmail-spp –> there is no such plugin, only “force auth” and/or “auth logging”
3. use spamdyke

In contrary order I would prefer to use spamdyke , have an alternative through qmail-spp and do not use the patched smtp auth functionality.  Update!  Due to the fact that some things were happen surprisingly and unexpected in the last time (e.g. the new tls patch release, ucspi-unix-1.0) I tend to use patched AUTH functionality.

For incoming mail this will be done by ucspi-tcp. This works already. For outgoing mail is a patch available, but conflicts with the domainbindings (which work for IPv4 only). To make domainbindings applicable for IPv6 seems to be a bigger effort - maybe we stay by domainbindings with IPv4 in the next release.

On the other side IPv6 for outgoing connections is not a must as long a relay can/will be used (if IPv6 is necessary). I'm not sure also, if domainbindings makes sense with IPv6 really.

The latest patch by Frederick Vermeulen simply dissallows the usage (fallback) to SSLv2/SSLv3 for both  qmail-smtpd  and  qmail-remote  . I wouldn't do this for outgoing connections overall, as for incomming connections this can be defined through the config file  tlscipherlist  .

I daresay a few things could be reviewed:

• Andrew Richards provides qmail-logmsg (extended smtpd logging) and some other stuff
• Andrew St. Jean provides some stuff to use courier authlib (no patches) - done!

There is the SPF and DKIM stuff too, as of today I don't have any roadmap how to do this. /*

• patch moreipme (includes the “qmail-0.0.0.0-patch”?, which is in netqmail) –> IPv4 only
• qmHandle
• queue-repair
• queue-fix
• relay-ctrl
• patch maildir++
• patch ext-todo

/*

*/

Until now I don't have an answer to the first question. Any comments?

Update!  Let's move forward! A project without any progress is dead! The following things are on the road:

1. IPv6 for qmail-remote
2. Improved install/config routines, especially for qmail-spp
3. DKIM signing (and verify ?) –> this will come later on, maybe as a separate package
4. included updates of the netqmail-1.06-tls-20151215.patch
5. included force-tls functionality
6. some qmail extra stuff (e.g. checkpassword wrapper) –> most of extra stuff will be available separate
7. new man pages
8. some code clean up (internal, use of POSIX standards)

So without a timeline - eQmail-1.09 will be coming.