Thanks you all who replied for my questions.
From: Geo Carncross <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED],DBMAIL Developers Mailinglist
<dbmail-dev@dbmail.org>
To: DBMAIL Developers Mailinglist <dbmail-dev@dbmail.org>
Subject: Re: [Dbmail-dev] Questions on DBMail IMAP server
Date: Tue, 29 Mar 2005 16:04:37 -0500
On Tue, 2005-03-29 at 22:31 +0200, Paul J Stevens wrote:
> Geo Carncross wrote:
>
> > On Tue, 2005-03-29 at 00:54 +0000, Aaron Stone wrote:
> >>DBMail relies on MySQL or PostgreSQL for data storage.
>
> > ... or SQLite; but that's really only useful for one-db per user
> > situations.
>
> Which is actually quite interesting if we can support auto-creation of
the
> database. For that to happen however, we need:
>
> A better run-time configuration; the current setup for accessing
dbmail.conf and
> presetting the runtime should be fixed to
>
> 1. allow full runtime access to specific variables through a single
commandline
> switch. Consider:
>
> 'dbmail-util -n -O smtp:debug=5'
> 'dbmail-imapd -n -O dbmail:db=/var/lib/dbmail/$USERNAME.db'
I don't see why. Separating authentication would be "good enough"-
simply allow a "PREAUTH" mode (dbmail-imapd --already-logged-in-as=test)
that simply starts authenticated with a :
* OK
(or optionally, with --already-preauth-as=test to display the preauth
banner.... or display $BANNER :)
I presently proxy the IMAP connection to dbmail-imapd and handle
authentication elsewhere. All of my dbmail copies have the same "foo"
and "foo" -- they're just only accessible through the proxy.
I'm happy to change that, however :)
> 2. allow dynamic overloading of the conf-file location. Like this:
>
> load system-wide /etc/dbmail/dbmail.conf
>
> if getenv("DBMAILCONF"):
> ..load all known ini-variables from it..
> else if ~/.dbmailrc:
> ..load all known ini-variables from it..
> else if /etc/dbmail/$USERNAME/dbmail.conf:
> ..load etc...
-f is fine for me. getenv wouldn't be too bad, but see above- I think
authentication should be split out so this kind of hackish behavior can
be avoided.
> These things combined with a xinetd setup and *safe* auto-creation of
databases
> will make dbmail scale pretty well on sqlite I suspect.
I think the (ahem) best way to do this is to set some policies on
the .sql files:
0. forbid touching data
1. forbid a ";" at the end of a line in the .sql files
2. require the use of "--" at the VERY BEGINNING of a line to be a
comment
3. do upgrades only if 0,1,2 are okay.
That being done,
4. Use a short awk script that converts the .sql file into a C function
that "builds" the database.
awk 'BEGIN { print "/* do not edit this file */"; print "static void
__dbmail_make_db(void) {"; RS=";\n"; Q=sprintf("%c",34); } { gsub("[^a-
zA-Z0-9 [EMAIL PROTECTED]","\\\\&"); print "dbmail_exec("Q$0 Q");" } END { print
"}\n" }'
We then just #include this file normally in the sqlite/dbsqlite.c (or
similar) and call __dbmail_make_db() if we think for a reason the
database doesn't exist.
This way, people who are largely comfortable with SQL can avoid the C as
much as possible.
--
Internet Connection High Quality Web Hosting
http://www.internetconnection.net/
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
