Customising SpamAssassin with Amavis

[Simon Brereton]

On 2 November 2011 09:46, Mark Martinec <Mark.Martinec+amavis at ijs.si> wrote:
> 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 :)

Okay, I agree - what I have for now will suffice.  But if you're ever
bored and want to add it in, I won't complain :)

>> 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).

Okay, thanks.  Until now I've always just followed a howto and not
really worried so long as mail was being delivered.  SA is a
configuration nightmare - I can see how it would work if I was user
using it, but we only use it for Amavis and then things become not so
clear.  I was lead to believe (probably not intentionally) that Amavis
didn't use the /etc/spamassassin/local.cf - that could be part of my
issue - does it?

>> 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.

Again - thanks for aiding my understanding.  Yes, it was a --lint run.

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

I'm on debian - and this doesn't work for me..

mail:~# amavisd debug-sa
bash: amavisd: command not found
mail:~# amavis-new debug-sa
bash: amavis-new: command not found

However, /usr/sbin/amavisd-new debug-sa 2>$1 works..  Which means I
have more questions..

Nov  2 16:13:31.459 mail.spamfreeisp.net /usr/sbin/amavisd-new[21323]:
Tools code           NOT loaded
--  How can I fix this?  What's it for?

Nov  2 16:13:31.461 mail.spamfreeisp.net /usr/sbin/amavisd-new[21323]:
Internal decoder for .zip
Nov  2 16:13:31.461 mail.spamfreeisp.net /usr/sbin/amavisd-new[21323]:
No decoder for       .7z   tried: 7zr, 7za, 7z
Nov  2 16:13:31.461 mail.spamfreeisp.net /usr/sbin/amavisd-new[21323]:
No decoder for       .rar  tried: unrar-free
Nov  2 16:13:31.461 mail.spamfreeisp.net /usr/sbin/amavisd-new[21323]:
No decoder for       .arj  tried: arj, unarj
Nov  2 16:13:31.461 mail.spamfreeisp.net /usr/sbin/amavisd-new[21323]:
No decoder for       .arc  tried: nomarch, arc
Nov  2 16:13:31.461 mail.spamfreeisp.net /usr/sbin/amavisd-new[21323]:
No decoder for       .zoo  tried: zoo
Nov  2 16:13:31.461 mail.spamfreeisp.net /usr/sbin/amavisd-new[21323]:
No decoder for       .lha
Nov  2 16:13:31.461 mail.spamfreeisp.net /usr/sbin/amavisd-new[21323]:
No decoder for       .doc  tried: ripole
Nov  2 16:13:31.461 mail.spamfreeisp.net /usr/sbin/amavisd-new[21323]:
No decoder for       .cab  tried: cabextract
Nov  2 16:13:31.461 mail.spamfreeisp.net /usr/sbin/amavisd-new[21323]:
No decoder for       .tnef
Nov  2 16:13:31.461 mail.spamfreeisp.net /usr/sbin/amavisd-new[21323]:
Internal decoder for .tnef
Nov  2 16:13:31.461 mail.spamfreeisp.net /usr/sbin/amavisd-new[21323]:
No decoder for       .exe  tried: unrar-free; arj, unarj
--  How can I fix these?

I still miss a way to see if the SpamCop plugin is correctly sending
spam to spamcop.


>> 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.

Yes, it's working when I added it to 330.pre.  Would a local.pre
suppliment the other .pre files or replace it (that would be what I
understood from your tip above).



Thanks for awesome software.

Simon