On Thursday April 12 2007 19:34:18 Michael Scheidell wrote: > Had a custom front end that needed to allow for NULL policy for users > (so users policy was derived from either the @domain.com or the @. > Catchall) > > Lots of reasons, if anyone is interested, contact me off list. > It solved some user issues with policies, and was required for me to > actually get whitelisting to NON interactive users to work. > > (ie, user logs in, creates a policy, add whitelist, life is fine) > > BUT, if user doesn't log in, doesn't create a policy, and I want > to add a whitelist for him I have to create a user entry,
right > and what policy do I select? some default policy id, prepared in advance for this purpose > and what policy do I select? @domain.com? @.? What if @. Changes? > Do you change users policy? Looks like a wrong kind of question. What policy to select? Probably some neutral site-default policy. Prepare one in advance, give it some fixed id like 1 or 999, then let any newly created record in 'users' table have it, until a more specific setting is needed (if ever). Such a default policy can even have all fields (except its id) set to NULL, which would cause lookups to fall back to static settings. It is not necessary that such a policy is also associated with an @.domain or an @. record, although it usually is. > and what policy do I select? @domain.com? @.? You are now talking about a user record, not a policy record. User records map a recipient address to some id, which can then be used to attach white/black list to, and to associate it with some policy record (carrying Y/N flags to fields like spam lover, providing a kill level, etc). Policy record has nothing to do with white/black lists. White/black lists are associated with a user record, not with a policy record. When creating white/black list entries (in table wblist), and the w/b list is intended to apply to one specific local user, and he happens not to already have a record in 'users' (but relies on a fallback to some @.domain record), then just create a new 'users' record specific to this user, give it some default policy (e.g. the 999 mentioned above), then you can start creating entries in table wblist for this new users.id . > By allowing a NULL users.policy_id and checking for it, bypassing the > user id on first pass if NULL, this SHOULD allow a 'automatically > generated' users account, without selecting a policy. > > The complexity was needed if it selected a derived policy, returned the > @domain.com user id, but the whitelist was actually owned by > [EMAIL PROTECTED] Maybe I just don't understand the problem you are trying to solve. Mark ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ AMaViS-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
