Re: eQmail or s/qmail

>> Just some high level thoughts. Keep in mind: IMHO!
> 
> Let's add some more thoughts:
The truth is in the middle - always. Let me add some points for open 
discussion:
> 
> 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.
The most important thing: coordination! I see RfC sometimes critical, 
e.g. djb decided not to implement the DSN RfC. RfC's can be interpreted 
different too or they are not absolutely clear written. This doesn't 
mean to ignore them.

> 
> 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.
I wouldn't mix packages, so IPv6 should be on the remote of X-qmail 
only.

> 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.
IMHO there are too many "ucspi" packages: -tcp, -ssl, -ipv6 (and a 
patch), -unix. I think a consolidation would make sense. Otherwise the 
usage of xinetd is an alternative too. This shouldn't be ignored. How to 
do SSL/TLS with xinetd?

Heartbleed was yesterday and it was a openssl bug. This is fixed. I'm 
not really happy with openssl but I don't see an alternative at the 
moment. I think djb was right that we should put attention to tomorrows 
bugs/security leaks.
> 
> 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
What's about Gentoo? As you mentioned Ubuntu - what's about Mint? There 
are more. I pointed this out already: creating packages for distribution 
is not a task of the developers.

> 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.
I like slashpackage. It can make systems cleaner. Otherwise I wouldn't 
use it to separate every package.

> 
> 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.
What's wrong by using functions provided by the OS (disk I/O)? The user 
will run out of 10000 fd's too. Beside - how many (so called) admin's 
have knowledge about resource management (memory, fd's) as of today? I 
wouldn't put to much attention on this (from developers side), as it 
looks like a admin issue.

> 
> 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).
I agree that the "remote" side could need some improvements - however, 
this isn't high prio.
> 
> 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.
I use your authentication patch with success. But at least I have made 
my way of authentication and preventing backscattering.
> 
> 
> 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.
> @Erwin: Please don't interpret 'academic' as negative in any case. Some 
> things I like, some things I would do/see different.

With all respect, I won't wait for any of the former "qmail big one's". 
They are still on the list and I realized that any of them is better 
than me regarding to qmail. But as they are seems to be passive - let's 
move on.
> ---
> 
> This was my talk regarding the developers. What's next: Setting up a
> particular web-site?
I think we need a good discussion platform - better than a website.
> Scheduling a nice-to-meet-you conference? Any volunteers?
Me - if you want to accept.

I hate discussions via mail. It could be led into to much 
misunderstandings. At least at long threads. There is never a chance to 
point out all nor really accurate. Did I made all accurate?

----
Sent with eQmail-1.10-dev