I has similar problems when investigating this earlier on, and even more so
when I had hoped to have multiple pop3/imap deaemons on the same machines
listing for different ISPs.
My ultimate plan is to different pop3/imap daemons consult either a
different user database, or a single userdatabase but with 2 keys (eg.
Username and ISP/Company code => thereby allowing duplicate usernames. As
dbmail for the most part refers to mail messages and mailboxes by a numeric
ID, you could have a mark/ISPA and mark/ISPB which didn't need to log in by
realm ("[EMAIL PROTECTED]" / "[EMAIL PROTECTED]"). The differention for me
would be IP
address:
Therefore I need to be able to have POP3/IMAP listening on say
10.0.0.1 - doing a lookup from dbmail users with a userid of "mark" and say
"virtualcode" of "ISPA" ('virtualcode' being a new column in the dbmail
users table).
10.0.0.2 - could do a lookup from dbmail users with userid of "mark" and
virtualcode="ISPB"
No-one commented back on whether people liked this idea or not, so I'd
welcome comments now that dbmail is starting to be used in more production
environments and the list is getting bigger.
The current dbmail config database makes this a bit harder, and I'd been
thinking of two ways this could be implemented:
1) On-disk config (start up dbmail with dbmail-pop3d -f
/etc/dbmail/ispa.conf and dbmail-pop3d -f /etc/dbmail/ispb.conf).
2) Per-client database identifier:
dbmail-pop3d -clientid ISPA
dbmail-pop3d -clientid ISPB
The second would allow configs to be managed by database still, but make
them selectable. The config lookup query could be modified to simply do a
"select ... From config where clientid='XXXX'". If the clientid was not
specified in the command line of the client, let it default to "DEFAULT".
What do people think? (... *please* comment). I'd really love dbmail to
have good support for duplicate usernames without the requirement for @realm
logins stored in the database. It's inherent design makes this easy, but it
always seems to be hard to get feedback supporting this idea, even when I
offer to write patches. Eelco.. I'd love to hear from you regarding your
support/rejection of this concept...
/Mark
On 5/9/02 10:40 AM, "Jesse Norell" <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> We're working on a multi-server setup with a single
> database server, and multiple postfix/dbmail servers
> connecting to it. It seems the current (database-stored)
> configuration setup (ie. config table) does not handle this,
> as most of the settings may/will be server-specific. The
> most prominant example would be POP3D_BIND_IP and IMAPD_BIND_IP,
> which if not '*' will be different on every machine, but most
> all the variables really should be server-specific.
>
> I'm pretty sure I can get around this by setting up nearly
> identical machines (including user/group names, etc.), and
> bind to '*', so it's not a "showstopper" problem, but is
> there a way to handle this currently, or is this something
> that needs addressed? If the latter, a few thoughts on the
> design - there does need to be one central config source for
> the entire system, that each dbmail server will consult (ie.
> in the database), and then a way to have server-specific
> values. One way would be to have server-specific values
> saved in a local config file (eg. dbmail.conf) - alternately
> could add a field to the config table to specify which server
> the config setting applies to (global if empty, otherwise it
> matches the server's hostname or ip addr).
>
> Or, did I just miss something in how I have this setup?
>
> Thanks,
> Jesse
>
>
>
> --
> Jesse Norell
> [EMAIL PROTECTED]
> _______________________________________________
> Dbmail mailing list
> Dbmail@dbmail.org
> https://mailman.fastxs.nl/mailman/listinfo/dbmail
