Bernd Zeimetz wrote on 23/12/2005 12:18: >>>-$assassin->compile_now(); >>>+$assassin->compile_now(0); > > it doesn't read root's configuration fles anymore, but it still tries to use > the byes database and auto-whitelist and so on.
Thanks for the test. > Isn't there a way to override > spamassassins default settings in spampd? > Of course, you can configure all these things in the global configuration, > but > I think this makes using spampd unnecessarily complicated for unexperienced > users. I could say that setting up a mailserver with any kind of mail filtering isn't something for an unexperienced user. However, I'm not gonna do this (I would consider that cheating). > Here comes an idea I had while reading torugh the manpage: > - create a directory with a little config for spamassassin which first > includes the normal /etc/spamassassin files (and - don'tknow if neccessary - > configurethe right path for autolearn/bayes/....) > - tell spamassassin to use the config path from above Maxim: This might be doable. The new() constructor to Mail::SpamAssassin accepts a hash of options, which you already use. However, one of those options is 'userprefs_filename'. If we set that to /etc/spampd.conf (and still use the dont_copy_prefs option), it would be read (if existing) for any non-system-default settings the user might want to set for spampd execution of spamassassin. And I could even ship such a config with my spampd package, setting some useful defaults. If it doesn't exist, nothing would change because dont_copy_prefs prevents Mail::SpamAssassin from creating that file itself. It would still make sense to configure spamassassin to use some central storage for the bayes and awl databases, but this could now be done in a configuration file only evaluated when SpamAssassin is used through spampd (or when the user uses --prefs-file=/etc/spampd.conf when executing spamassassin or sa-learn). This would stop spampd usage from interfering with local spamassasssin users. And if we add a commandline option for this, it would even make it possible for multiple instances of spampd to use different spamassassin configurations. > But this is just theory and I won't have the time to test this before January > 2nd - I'm off for christmas holidays - (un?)fortunately to a place without > internet. Well, happy holidays and a happy new year to you then (and to Maxim of course). regards, Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
