> 1. configurable prefix. I guess the default should be an empty prefix,
> to default to the current table names.
> 2. do tablenames also need to configurable like [EMAIL PROTECTED]
> mentioned in a previous message? If queries get table names from
> variables, it shouldn't be so hard to make the whole table name
> configurable.
>
> Please shoot at my arguments. I think we need some strict
> requirements
> on this before Brian gets to work ;)
I don't think all tablenames need to be configurable , or certainly the ones
are 'dbmail-specific' [but prefixable may be nice]; but one that may be
worth considering is the users table. I've said this before, many months
ago, so forgive my repeat ramblings:
Most of us have a database of all our customers, for billing, radius, etc.
This to me it make sense to allow dbmail to be able to query our existing
user databases to ultimately find the dbmail "user_idnr" that we need to
handle delivery/checking of mail. Thus it may be worth making the "users"
table totally configurable, so you can hook into any existing table that
exists.
The real power with above, would be to allow the magic dbmail-specific
columns to be customisable (so if you already had a "uid" column which
mimicked the passwd file, you could use that column rather than having to
add a "user_idnr" column to your database, etc.
Even better -- allow custom queries from that table, to allow greater
flexibility. There are probably only a handful of queries which actually
interact with the users' table, so maybe these could be definable [but not
required to be defined in a config, eg. default if not present].
Reason: We do wholesale ISP services in NZ and also buy a lot of ISPs, which
results in the need to support multiple "mark" usernames on our mailserver
(people over here don't log in with [EMAIL PROTECTED] and [EMAIL PROTECTED] --
usually just 'mark'). Dbmail because it's in theory all numeric post-auth is
great for this -- I can have mark from ispa with user_idnr 1000 and mark
from ispb with user_idnr 2000. So all I need to do now is make sure I can
look up the right user_idnr when 'mark' connects.
Currently we're having to proxy the pop3/imap streams and rewrite the
username so when someone goes "USER mark" the dbmail server actually gets
"USER mark.ispa" or similar. We have daemons bound to different IP addresses
and ports with different configs to do this.
What would be great, is to allow dbmail to do this job for us -- so I don't
have another intermediate step which doesn't need to be here. I'd love
dbmail to be able to do the following:
select user_idnr, password from users where userid='mark' and
SOMEOTHERCOLUMN='VALUE'
This SOMEOTHERCOLUMN=VALUE could be an ip address (host='10.0.0.1') based on
the IP address of the incoming connection, or perhaps some variable that is
per-daemon defined (e.g. start ./dbmail-pop3d with some config that says
ISPID="DEFAULT" or ISPID="ISPB").
Now I know not everyone wants this (or do you? -- there must be people in a
similar boat to me out there!). Having just the users-related queries
customisable, and allowing macros to be used such as
%u for username
%p for password
%h for incoming hostip
%{customvariableinconfig}
Would allow a very customisable solution for those people that needed it.
Then people could easily build up configs which queried their existing
user/billing databases.
My 2c.
/Mark
