Hello, This would be a nice feature for some. It would seem a little nicer if you could have a command-line option that specifies whether it runs in daemon mode or inet mode, or even a config file entry, so you don't have to recompile to change that. It's probably more of a hassle for people who use binary distributions, mostly (eg. the debian packages).
I believe SSL/TLS support is slated to be added at some point, it's one of the most common requests, but this could be used as a nice stop-gap for people needing it in the interim. You might run over to the sourceforge.net page and log a feature request (trying to get all of them tracked there). jn ---- Original Message ---- From: Diego Rivera <dbmail-dev@dbmail.org> To: DBMail Developers <dbmail-dev@dbmail.org> Subject: [Dbmail-dev] Simplifying DBMail Sent: Thu, 11 Sep 2003 20:54:39 -0600 > Hello all > > First of all - congratulations on a great little product. I've been > looking for something like this for AGES,with little luck. > > Although I'm new to dbmail there is one thing that caught my eye - imapd > and pop3d are standalone-only daemons. > > While this in and of itself is not bad (they HAVE to listen for network > clients after all :) ), it does have some limitations when you want > functionality like DoS detection/prevention and SSL/TLS connectivity > (among others). > > This is precisely the type of functionality that Xinetd (with the help > of tools such as stunnel) can provide rather easily - but the daemons > would have to NOT be standalone network listeners and instead > communicate over stdin/stdout. > > Correct me if I'm wrong, but creating 2 different server executables > (standalone and stdin-based) each linking to different server.c (.o) > files could do this - just replace server.c with server-stdin.c upon > linking and voila! > > I think serverchild.c (.o) is a compliment to server.c so it would not > be needed for such an alternate implementation - is this correct? > > Other things would need to be changed as well: max connections should be > handled by server.c/serverchild.c rather than the daemon cores > themselves, resolveIP, port, etc. > > If this approach seems feasible, I'd like to contribute in adding this > functionality. > > That way coding SSL/TLS support, more sophisticated DoS > prevention/connection rate limiting, IPv6 support, and many other nice > little features can be avoided. > > The tradeoff is the added overhead in the xinetd/stdin-out mode, but I > think this could be acceptable in a lot of scenarios. > > Your opinions and thoughts on this? > > Best > > -- > =========================================================== > * Diego Rivera * > * * > * "The Disease: Windows, the cure: Linux" * > * * > * E-mail: lrivera<AT>racsa<DOT>co<DOT>cr * > * Replace: <AT>='@', <DOT>='.' * > * * > * GPG: BE59 5469 C696 C80D FF5C 5926 0B36 F8FF DA98 62AD * > * GPG Public Key avaliable at: http://pgp.mit.edu * > =========================================================== > > -- End Original Message -- -- Jesse Norell jesse (at) kci.net
