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:
         –> 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):
To answer the 2. question lets see the Pros and Cons of qmail:
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:
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:
There is the SPF and DKIM stuff too, as of today I don't have any roadmap how to do this.
/*
/*
*/
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:
So without a timeline - eQmail-1.09 will be coming.