Actually, I think a much better way of doing this is to give DBMail a few
'keywords' that can be used in configurable auth queries.
[AUTH]
auth_user_exists = SELECT name AS %user_name%, uid AS %user_idnr% FROM
radius.usernames WHERE name = %auth_user_name% AND ipaddr = %auth_ip_address%
Something like that. Basically, DBMail would run this query with the
%variable% names replaced with (quoted if necessary) internal values. So the
AS clauses would force the return columns to have the names that DBMail
expects, while the WHERE clause can still use the native naming. (I just
tested this on MySQL 4.0.16).
Aaron
[EMAIL PROTECTED] said:
> Mark Mackay - Orcon writes:
>
>
> 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.
>
> hope that helps.
>
> c
>
> >> 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
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Dbmail-dev mailing list
> > [email protected]
> > http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
> _______________________________________________
> Dbmail-dev mailing list
> [email protected]
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
--
