Customising SpamAssassin with Amavis

[Mark Martinec]

Simon,

> In the first instance, I implemented SPF on my domains.  I notice that
> SA does check for SPF records.  However, I wonder if would be possible
> to configure SA/Amavis to insert a specific SPF line in the headers when
> an SPF record is found in the way that Yahoo/Gmail/postfix-policyd/etc. 
> does?

Not available off-the shelf, it would require a custom hook.

But you can have a list of triggered SpamAssassin rules inserted
into a mail header section, and one of these carries the result of
SPF check as performed by SpamAssassin's plugin.
I know, not quite the same. Not worth the trouble in my view :)

> that opens up a lot of other issues..  Here are the ones
> that concern me most.
> 
> Nov  1 19:43:32.556 [12312] dbg: diag: [...] module not installed:
> Net::Ident ('require' failed)
> Nov  1 19:43:32.556 [12312] dbg: diag: [...] module not installed:
> IO::Socket::SSL ('require' failed)
> --How can I fix that?

Not to worry about Net::Ident, you don't want it.
Not to worry about IO::Socket::SSL, you most likely don't need it.

> Nov  1 19:43:32.557 [12312] dbg: config: using
> "/etc/mail/spamassassin" for site rules pre files
> Nov  1 19:43:32.557 [12312] dbg: config: read file
> /etc/mail/spamassassin/init.pre
> Nov  1 19:43:32.557 [12312] dbg: config: read file
> /etc/mail/spamassassin/v310.pre
> Nov  1 19:43:32.557 [12312] dbg: config: read file
> /etc/mail/spamassassin/v312.pre
> Nov  1 19:43:32.557 [12312] dbg: config: read file
> /etc/mail/spamassassin/v320.pre
> Nov  1 19:43:32.557 [12312] dbg: config: read file
> /etc/mail/spamassassin/v330.pre
> -- Surely can't that be right?

It *is* right.

Each vxxx.pre file contains loadplugin directives for
modules that were introduced with that versions.
You need them all by default (unless you copy all the
interesting 'loadplugin' directives to some local.pre file and
wipe out vxxx.pre files - but that is not commonly done).


> Nov  1 19:43:32.563 [12312] dbg: plugin: loading
> Mail::SpamAssassin::Plugin::SpamCop from @INC
> Nov  1 19:43:32.564 [12312] dbg: reporter: local tests only, disabling 
SpamCop
> Nov  1 19:43:32.565 [12312] dbg: plugin: loading
> Mail::SpamAssassin::Plugin::SPF from @INC
> Nov  1 19:43:32.568 [12312] dbg: plugin: loading
> Mail::SpamAssassin::Plugin::Pyzor from @INC
> Nov  1 19:43:32.569 [12312] dbg: pyzor: local tests only, disabling Pyzor
> Nov  1 19:43:32.570 [12312] dbg: plugin: loading
> Mail::SpamAssassin::Plugin::Razor2 from @INC
> Nov  1 19:43:32.571 [12312] dbg: razor2: local tests only, skipping Razor
> -- I thought I had network tests on..
> 
> mail:~# grep -rin sa_local_tests_only /etc/amavis/*
> /etc/amavis/conf.d/20-debian_defaults:93:$sa_local_tests_only = 0;
> # only tests which do not require internet access?
> 
> Surely = 1 would be local only, no?

Correct. A value of 0 is fine, and is also a default.
I don't see how your SA sees them as disabled.

The above debug log doesn't appear to be from amavisd.
Perhaps it is from a 'spamassassin --lint' run, which
implicitly disables network tests.

The simples way to get SpamAssassin debug log from
amavisd (to stderr) is to run it as: amavisd debug-sa


> spamassassin 2>&1 -D --lint | less

actually:

  spamassassin -D --lint 2>&1 | less

> Is /etc/spamassassin/v330.pre the correct location to add modules
> like this (and DCC, etc)?

I prefer to have a separate file, e.g. local.pre, where all
the non-default 'loadplugin' directives can go.
But it is also alright to modify existing vxxx.pre files
if you prefer.

  Mark