On 2/18/2005 3:05 PM, Matt Kettler wrote: > spampd implements calls directly to the SA perl API via > Mail::SpamAssassin. By using the API, the tool becomes responsible for > directly setting up some of the user configuration. In particular, the > caller of the perl API specifies where to get the user preferences from. > This is NOT automatically handled. > > The perl API does not auto load the user config for any tool. It's always > up to the caller of the API to specify the source of user preferences. It > can look at the Mail::SpamAssassin::Conf object to make decisions, but it > is up to the perl API caller to decide how to proceede. > > Mail::SpamAssassin makes the SQL tools available, but it's up to spampd to > actually call load_scoreonly_sql(). Everything is in there, but spampd > doesn't use it.
This is helpful thanks. Basically... I've already got postfix calling LDAP for a variety of filters (see http://www.ehsco.com/reading/20040916ncf1b.gif), and I'd like to extend those LDAP entries for global spamassassin tests (I don't do any per-user tests at the global level). Primarily this means moving the global whitelists to LDAP (eg, rather than track global whitelists in a local cf file, link them to domain-based entries in the directory). Is the LDAP stuff in SA usable for global tests, or is it per-user only, or is there less of a difference than I am imagining here? There are comments in spampd about unsure future use of per-user scores and this may be a central part of the discussion. OTOH, spampd does seem to pick up the LDAP entries in local.cf, so it appears to be activating that part of the routine [I generally use the spamassassin script for tests before activating the changes for use with spampd, and that was part of the whole confusion on my part here]. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
