Re: eQmail or s/qmail

Hi together,


On Sat, 14 May 2016 13:03:41 +0200, Kai Peter <[email protected]> wrote :


> Overall it will be hard to reanimate (net)qmail to growth in public 
> attention again. There is a (hard) core of users, but most of the main 
> distributions didn't provide/assist (net)qmail as a package anymore. Why 
> ever, there were a lot of mistakes made in the past. I question if this 
> can be corrected. At the moment I would say (net)qmail is dying slowly 
> but continuously.

Still there is a substantial user base out there - but the current qmail is hard to maintain for the 
the current SMTP and privacy requirements.


> Back, differences in short:
> 
> - s/qmail is academic, not what I want as administrator
> - indimail is leading in up-to-date functionalities and its history
> - eQmail is minimalistic, less (should be) is more (its like I wanted to 
> se netqmail-1.07)
> - other derivatives of (net)qmail with lesser attention differs minimal
> 
> Getting the work of Erwin, Manvendra and me together is not enough. The 
> community have to contribute too. Starting with feedback, wishes and 
> expectations. Former and new contributors. Than it will make sense to 
> think about a coordinated project.
> 
> Just some high level thoughts. Keep in mind: IMHO!

Let's add some more thoughts:

a) In order to stay tuned with current Internet developments, we need developers checking the 
upcoming RFCs, perhaps writing patches to include those, checking other peoples 
contributes. 

b) MY personal contribution was to include a rock-solid IPv6 implementation working for both 
Linux and BSD (at least) because these two stacks are different. Further, I took the chance to 
jump on the train for TLS encryption and provide some High-Level APIs together with UCSPI-
SSL. Remember: This architecture prevented any potential Heartbleed victim at least not to 
disclose the users's passwords. 

c) Integration into different OS is still a battle. At least we need to consider *BSD, Debian, 
perhaps Ubuntu and the Rad Hat based (rpm) systems like SuSE (in Germany). Actually -- 
according to a) -- wie need specialist in that field. I made the attempt to use DJB's 
slashpacket convention; but not everyone welcomes this.

In order to maintain a long haul (valid) version of qmail (or any successor) we need to talk 
about architecture:

d) qmail is (disk) I/O bound. I just had an user running out of 1024 file descriptors for qmail-
send. This is coupled with the way qmail deals with message storage identified with inode 
names in the queue. My long term aim is to use more flexible UUIDs instead, allow a 'real' 
distributed queue and in addition encryption of the queue. 

e) qmail-remote is CPU bound for outgoing TLS connections: Each message is one delivery; 
no pipelining. Which means one TLS handshake each. This is sub-optimal and needs to be 
addressed together with d).

f) In s/qmail (3.1) I made the attempt to integrate Recipient verification and User 
Authentication. However; I just provide the APIs and some PAMs. A good solution is of vital 
importance for any current MTA.


Apart from my 'academic' research, I do see the need that not only to identify the required 
resources but also find specialists really doing the integration. Unfortunately, Russ Nelson's 
qmail site was never the place to be. 

---

This was my talk regarding the developers. What's next: Setting up a particular web-site? 
Scheduling a nice-to-meet-you conference? Any volunteers?

---

Now some word to potential users(updaters: Please try out the different solutions! Today, 
regarding VMs, it is cheap to setup a well-maintained qmail-successor package (I hope at 
least) and compare those. 

Best regards.
--eh

-- 
Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/