amavis "fails to parse" 'uridnsbl_skip_domain ...' in spamassassin local config ?

Mark Martinec Mark.Martinec+amavis at ijs.si
Wed Apr 11 01:36:03 CEST 2012


locuse,

> > The .cf files should not be read before all .pre files
> > are brought in.
> 
> iiuc Quanah's comment, this has been addressed in v2.7.x.

Not really.

> in the interim, what can/should be done about this?  is it a patch to
> amavis itself (unlikely)? or a zimbra issue?

As it stands now I'd say it is a zimbra issue, perhaps due to
a lack of better alternative in amavisd-new until now.


Quanah wrote:

> My question would be, if it shouldn't be $sa_siteconfigpath, what should it
> be?
> 
> In our 2.7.0 Amavisd, which works with the configuration, it is still:
> 
> $sa_siteconfigpath = '/opt/zimbra/conf/salocal.cf';
> 
> The bit I was thinking about was adding the ability for user preferences,
> not site preferences, so it doesn't apply.

Starting with amavisd-new-2.6.3 we pass the following to SpamAssassin
during its initialization:

  rules_filename       => $sa_configpath,
  site_rules_filename  => $sa_siteconfigpath,

With amavisd-new-2.8.0-pre4 we added one more configurable,
adopted from Zimbra, the $sa_userprefs_file:

  rules_filename       => $sa_configpath,
  site_rules_filename  => $sa_siteconfigpath,
  userprefs_filename   => $sa_userprefs_file,

This is from 2.8.0-pre4 release notes:

- added a global configuration setting $sa_userprefs_file (undef by
  default), which is passed on to SpamAssassin as a 'userprefs_filename'
  parameter during its initialization. If 'userprefs_filename' parameter
  is nonempty, SpamAssassin tries to load a file with that name as
  user preferences configuration file (overriding systemwide settings),
  otherwise it tries to load a file '~/.spamassassin/user_prefs'
  if it exists. Suggested by Quanah Gibson-Mount;

Not sure how this all applies to Zimbra environment. Amavisd here is
just a messanger, passing these two or three settings from its config
file directly to SpamAssassin. The exact interpretation/semantics is
entirely in the domain of SpamAssassin.

So I guess the salocal.cf should indeed best be interpreted as
userprefs_filename. If I remember right I've seen the $sa_userprefs_file
addition somewhere in the Zimbra patches for amavisd.

So for versions before 2.8, the solution is either to patch amavisd
with this extra setting, or just append the contents of salocal.cf
to the usual SpamAssassin's systemwide config file, commonly named
local.cf.

  Mark


More information about the amavis-users mailing list