> You need it added to your third-party script, as, based on your > description, it's invoking the SA perl API's directly.
http://www.worlddesign.com/index.cfm/rd/mta/spampd.htm is what I'm currently using. It doesn't provide any additional parameters over regular spamassassin configs, and whatever I do to spamassassin is picked up transparently. I'm having a couple problems with some of it (SPF errors are being picked up and causing problems for it, apparently) but I haven't found anything else that fits into the postfix->sa->postfix->cyrus model in a better way so I'm inclined to keep using it.
First, let's clarify something. There are three ways to use SA.. spamassassin, spamd/spamc, and Mail::Spamassassin (aka the perl API).
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.
http://spamassassin.apache.org/full/3.0.x/dist/doc/Mail_SpamAssassin.html
There's nothing more for SA to do. It's there, all spampd has to do is make use of it.
