Re: SA doesn't use my scores from local.cf

[Matt Kettler <mk...@evi-inc.com>]

ddaasd wrote:
> Hi,
> I have a problem with SpamAssassin. I would appreciate if someone could
> help me.
> 
>  My setup is:
> 
> I’ve upgraded to SpamAssassin version 3.0.3  running on Perl version
> 5.8.0. I am using in conjunction with spamass-milter - Version 0.3.0 and
> Sendmail 8.12.11. The OS is RHEL 3.
<snip>

> 
> 1)      It seams that my customized scores from
> /etc/mail/spamassasssin/local.cf don’t work.


Did you restart spamd after editing this file? In order to avoid wasting CPU
time, spamd only reads /etc/mail/spamassassin/*.cf when it starts up. It only
reads user_prefs files when it's scanning a message.

The spamassassin command line on the other hand, parses everything from scratch
as it's a new instance.
> 
> The problem is that DEAR_SOMETHING, DEAR_FRIEND etc have no effect as
> they weren’t there. Is this a parse error or I miss something? How can I
> customize my score for different tests?
> 
>  
> 2 ) The result of #spamassasin -d --lint:
> 
>  Net::DNS version is 0.31, but need 0.34dnsavailable-1 at
> /usr/lib/perl5/vendor_perl/5.8.0/Mail/SpamAssassin/Dns.pm line 1230.
> 
>  What is this DNS? I think it has nothing to do with BIND…. Should I
> upgrade something?

Erm, It's DNS.. Domain Name System.. It's how names get resolved to IP
addresses, a very fundamental basic of the Internet.

SA uses a DNS module to do various RBL lookups. If you don't want to bother with
those rules you can ignore these warnings, otherwise you should try to get a
newer version of the Net::DNS perl module.

> 
> 
> 3)      I can’t use user_prefs from /home/user/.spamassassin/user_prefs
> 
>  
> 
> From the logs I see that SpamAssassin wants to write/read from
>  /root/.spamassassin/user_prefs. Why root?
> 
> I found out that the problem is that nobody has no home directory. I
> understand that. But when I run SA as root it reads from
> /root/.spamassassin/user_prefs. Shoudn’t SA read the user_prefs file of
> the recipient?

No, it shouldn't use the recipient automatically.

Consider the following:

1) SpamAssassin doesn't always know who the recipient is, as it can only guess
based on the To: header. However, what about a message that's To:
users@spamassassin.apache.org but was remailed to you by the list? There's not
always header saying who the recipient is, since the list effectively remails it
to you as a Bcc.

2) There might be multiple recipients (think Cc:, etc).

3) The recipient might not have an account on the local box (think relaying
mailserver, or even outbound mail you sent)


SpamAssassin uses the userid that *executes* it.

Spamd uses the userid that executed spamc, or the user passed to the -u command
line of either app.

If it finds it's going to scan mail as root, it falls back to nobody for safety.


> Isn’t this the point here, to customize for every recipient different
> rules? So, why is SA stucked to /root/.spamassassin/user_prefs?

Because that's who called SA.
> 
>  
> How can I customize rules for every user?

Ditch spamass-milter. You generally can't do this with a MTA layer filter.
Instead you'll want to do it at the MDA layer (i.e. procmail)and pass the
envelope recipient to -u. Some milters might be able to do this, but they often
run into the "what to do when there's multiple recipients for the same message"
problem.

There's drawbacks and advantages to each different layer of calling SA, so while
 a milter has several advantages, per-user customization is one of it's weaknesses.

Some generalities about the trade-offs of calling SA at different parts of the
mail chain. Yes there's some exceptions and variation among tools, but baring
some considerable coding cleverness, these are the limits of a straightforward
implementation at a given layer:

1) smtp-time in the MTA: (ie: milters, qmail-scanner, etc)
+can reject (properly)
+scanning is done once per message not per recipient
-inbound mail rate must be limited by a number of processes, or else system load
will explode if a rush of mail comes in all at once. (most do this using spamd
which has built-in child limiting)
-usually have very limited per-user flexibility

2) mta-queue layer (mailscanner is the only one I'm aware of):
+inbound mail can be queued quickly without waiting for SA to scan it.
+scanning can done per-message or per recipient (with some MTA queuing options)
+bursts of high volume have little impact on system load
-sustained high volume can cause mail queue to get large (Mailscanner does shift
to emergency mode to alleviate this, but that bypasses scanning)
-somewhat limited per-user flexibility (better than with milter, but still one
SA user_prefs)
-can't reject, can only generate post-delivery bounces (bad idea), quarantine,
delete, or deliver.

3) MDA layer (ie: procmail)
+high degree of per-user flexibility, as passing -u to spamc allows separate
user_prefs
-multi-recipient messages must be re-scanned
-can't reject...

4) MUA layer (ie: called from within kmail)
+complete end-user control of scanning
-isn't site-wide, must be installed on each client machine
-no centralized scanner, thus no central statistics
-messages must be downloaded to client before they can be scanned.
-can't reject...

Re: SA doesn't use my scores from local.cf

[ddaasd <dd...@gmail.com>]

Hi Matt,
Thanks a lot for your clarifications. Everything is clearer now :)



ddaas

Matt Kettler wrote:
> ddaasd wrote:
> 
>>Hi,
>>I have a problem with SpamAssassin. I would appreciate if someone could
>>help me.
>>
>> My setup is:
>>
>>I’ve upgraded to SpamAssassin version 3.0.3  running on Perl version
>>5.8.0. I am using in conjunction with spamass-milter - Version 0.3.0 and
>>Sendmail 8.12.11. The OS is RHEL 3.
> 
> <snip>
> 
>>1)      It seams that my customized scores from
>>/etc/mail/spamassasssin/local.cf don’t work.
> 
> 
> 
> Did you restart spamd after editing this file? In order to avoid wasting CPU
> time, spamd only reads /etc/mail/spamassassin/*.cf when it starts up. It only
> reads user_prefs files when it's scanning a message.
> 
> The spamassassin command line on the other hand, parses everything from scratch
> as it's a new instance.
> 
>>The problem is that DEAR_SOMETHING, DEAR_FRIEND etc have no effect as
>>they weren’t there. Is this a parse error or I miss something? How can I
>>customize my score for different tests?
>>
>> 
>>2 ) The result of #spamassasin -d --lint:
>>
>> Net::DNS version is 0.31, but need 0.34dnsavailable-1 at
>>/usr/lib/perl5/vendor_perl/5.8.0/Mail/SpamAssassin/Dns.pm line 1230.
>>
>> What is this DNS? I think it has nothing to do with BIND…. Should I
>>upgrade something?
> 
> 
> Erm, It's DNS.. Domain Name System.. It's how names get resolved to IP
> addresses, a very fundamental basic of the Internet.
> 
> SA uses a DNS module to do various RBL lookups. If you don't want to bother with
> those rules you can ignore these warnings, otherwise you should try to get a
> newer version of the Net::DNS perl module.
> 
> 
>>
>>3)      I can’t use user_prefs from /home/user/.spamassassin/user_prefs
>>
>> 
>>
>>>From the logs I see that SpamAssassin wants to write/read from
>> /root/.spamassassin/user_prefs. Why root?
>>
>>I found out that the problem is that nobody has no home directory. I
>>understand that. But when I run SA as root it reads from
>>/root/.spamassassin/user_prefs. Shoudn’t SA read the user_prefs file of
>>the recipient?
> 
> 
> No, it shouldn't use the recipient automatically.
> 
> Consider the following:
> 
> 1) SpamAssassin doesn't always know who the recipient is, as it can only guess
> based on the To: header. However, what about a message that's To:
> users@spamassassin.apache.org but was remailed to you by the list? There's not
> always header saying who the recipient is, since the list effectively remails it
> to you as a Bcc.
> 
> 2) There might be multiple recipients (think Cc:, etc).
> 
> 3) The recipient might not have an account on the local box (think relaying
> mailserver, or even outbound mail you sent)
> 
> 
> SpamAssassin uses the userid that *executes* it.
> 
> Spamd uses the userid that executed spamc, or the user passed to the -u command
> line of either app.
> 
> If it finds it's going to scan mail as root, it falls back to nobody for safety.
> 
> 
> 
>>Isn’t this the point here, to customize for every recipient different
>>rules? So, why is SA stucked to /root/.spamassassin/user_prefs?
> 
> 
> Because that's who called SA.
> 
>> 
>>How can I customize rules for every user?
> 
> 
> Ditch spamass-milter. You generally can't do this with a MTA layer filter.
> Instead you'll want to do it at the MDA layer (i.e. procmail)and pass the
> envelope recipient to -u. Some milters might be able to do this, but they often
> run into the "what to do when there's multiple recipients for the same message"
> problem.
> 
> There's drawbacks and advantages to each different layer of calling SA, so while
>  a milter has several advantages, per-user customization is one of it's weaknesses.
> 
> Some generalities about the trade-offs of calling SA at different parts of the
> mail chain. Yes there's some exceptions and variation among tools, but baring
> some considerable coding cleverness, these are the limits of a straightforward
> implementation at a given layer:
> 
> 1) smtp-time in the MTA: (ie: milters, qmail-scanner, etc)
> +can reject (properly)
> +scanning is done once per message not per recipient
> -inbound mail rate must be limited by a number of processes, or else system load
> will explode if a rush of mail comes in all at once. (most do this using spamd
> which has built-in child limiting)
> -usually have very limited per-user flexibility
> 
> 2) mta-queue layer (mailscanner is the only one I'm aware of):
> +inbound mail can be queued quickly without waiting for SA to scan it.
> +scanning can done per-message or per recipient (with some MTA queuing options)
> +bursts of high volume have little impact on system load
> -sustained high volume can cause mail queue to get large (Mailscanner does shift
> to emergency mode to alleviate this, but that bypasses scanning)
> -somewhat limited per-user flexibility (better than with milter, but still one
> SA user_prefs)
> -can't reject, can only generate post-delivery bounces (bad idea), quarantine,
> delete, or deliver.
> 
> 3) MDA layer (ie: procmail)
> +high degree of per-user flexibility, as passing -u to spamc allows separate
> user_prefs
> -multi-recipient messages must be re-scanned
> -can't reject...
> 
> 4) MUA layer (ie: called from within kmail)
> +complete end-user control of scanning
> -isn't site-wide, must be installed on each client machine
> -no centralized scanner, thus no central statistics
> -messages must be downloaded to client before they can be scanned.
> -can't reject...
> 
>