Hi [EMAIL PROTECTED] -
Thanks for your comments, but I don't know if I explained myself right,
although I'd love alternate ideas for dealing with our complicated needs:
To start off with we have a database full of users, including say "mark".
Mark connects through to pop3.ispa.co.nz and is used to supplying "mark"
as their username.
If we wholesale to another isp or buy an ISP with "mark" in their system, we
want to be able to allow them to connect seamlessly. [At the moment we
import them into our central database as say "mark.ispb" but in the near
future a rewrite will allow them to be imported as simply "mark" with a
different account id].
When it was just 'mark' (no second ISP), we simply had:
"mark" <-> dbmail daemons [pop3/imap] [logs into db as "mark"] <->
dbmail-database
When we add the second ISP we currently proxy-rewrite things:
"mark" (from ISPA]
<-> dbmail daemons [pop3/imap] (listening on 10.0.0.1)
<-> dbmail-database
[logs into db as "mark"]
"mark" (from ISPB]
<-> simple pop3/imap proxy (listening on 10.0.0.2)
[rewrites pop stream to say "USER mark.ispb" when user enters "USER
mark"]
<-> dbmail-database
[logs into db as "mark.ispb"]
Thus we point pop3.ispa.co.nz to 10.0.0.1 and pop3.isbp.co.nz to 10.0.0.2.
This means "mark" from ISPB doesn't notice anything, and can keep using
"mark" as their username.
I don't quite understand the radius/pbsp idea you had below. An in any case
if a user is roaming (currently in the US and wants to check their mail), it
wouldn't work I'm guessing.
-------------
It would be great to be able to let Dbmail handle the above -- a very simply
idea would be to have two user tables. One for ISPA and one for ISPB I
guess, and then simply configure the daemons bound to 10.0.0.2 to select
from users_ISPB.
In the end it all just ends up with a user_idnr, so I guess I am looking at
ways that could be made more simple -- whilst allowing other people to do
'fancy' things as well. For example, there was discussion ages ago about how
to deal with suspended accounts, etc.
-------------
I didn't understand your suggestion so if you're willing to explain it to me
on or off list that would be appreciated, and I'd love to hear from anyone
else out there doing similar things as to what ideas they use in their
system.
Also -- what are people doing when they have their own, independent user
database for radius/billing? Are people just running one big database
server and using the dbmail 'users' table with other columns, are they
copying data to and from, updating both databases from the web-apps?
About 6-12 months ago the 'user' table was separated into a different
db-connection, which meant it could be on a different server, and thus be
plugged in with a few hacks of the SQL strings to existing databases. This
was discarded at one point (don't think it was ever posted to the list why).
Maybe this is a good idea for a 2.x release feature now that bigger
installations are starting to use dbmail.
/Mark
> mark, i think you're over complicating the thing with this
> pop3/imap proxy.. hack pbsp(extend it), make your radius
> write there the
> clients IP when they log, and their user?ip, then do your select ..
>
> you have so much data for a user.
> idnr
> name
> clientid
>
> and then pbsp
> ipnumber
> +name
> timestamp..
>
> you're already using xxx.isp, at the end of the day success
> is if you dont
> have to make your clients change their usernames, just for that..
>
> one optional field more wont be bad.. but why?
>
> you dont need proxy to achive that, this is trivial.
