Re: Spamassassin not catching spam On Mon, 2008-02-18 at 15:59 -0800, tmasboa wrote:
> hello, I just got SA set up on my server, and it does not seem to be working
> very well.
> 
> Out of about 300 spam messages, only 30 were caught, with many of the false
> -'s receiving scores like 2.x or something.
> 
> I have version 3.2.3 and it just doesn't seem to work well at all. I tried
> editing local.cf and changing the level from 5 to 4 but it won't actually
> change what SA is doing. Do I need to restart SA somehow? I have tried but
> it won't let me do "spamassassin restart".

Yes, IFF you are running spamd, then you need to restart it after
changing the configuration.

'spamassassin restart' sure won't work, because 'spamassassin' is not
the server. You should restart spamd (if you are using it) exactly the
way you started it in the first place. Can't help on that, cause you
failed to give any information about your system and mail processing
chain.

Also, it is a bad idea to simply decrease the default, unless you really
know what you doing.


Given these overall low results, it seems network tests are either
disabled, or you got a major problem with DNS on that machine.


> Edit: i have trained about 1000 messages throuy the bay filter and about 100
> ham messages.

You need at least 200 ham and spam *each*, for Bayes to kick in.


Did you read the documentation provided and the wiki?

  guenther


-- 
char *t="\\10pse\\0r\\0dtu\\0.@ghno\\x4e\\xc8\\x79\\xf4\\xab\\x51\\x8a\\x10\\xf4\\xf4\\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}


>From wyz@clerew.man.ac.uk  Sat Apr 26 15:48:51 2008
Message: 3
Date: Fri, 15 Feb 2008 12:50:53 -0000
From: "Charles Lindsey" 
Subject: Re: [ietf-dkim] NEW ISSUE: SSP-02: Policy Scope
To: DKIM 
Message-ID: 
Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1

On Thu, 14 Feb 2008 19:08:41 -0000, Douglas Otis   
wrote:

> On Feb 14, 2008, at 3:26 AM, Charles Lindsey wrote:
>
>> On Wed, 13 Feb 2008 22:46:10 -0000, Douglas Otis   
>> wrote:
>>
>>> Agreed.  DKIM can be employed in conjunction with _many_ transport  
>>> protocols.  While a domain may assert they sign "all" their SMTP  
>>> traffic, they may not be signing other types of traffic that could  
>>> potentially use DKIM signature headers.  How would a domain indicate  
>>> what protocol they cover by their assertion?  It seems logical to  
>>> restrict the _SSP policy to that of SMTP.  Other protocols can define  
>>> where the relevant policy can be found, or they could add a protocol  
>>> policy scope to the record.
>>
>> If you want to indicate that information, then propose a new tag within  
>> the SSP record for the purpose. But the default should be that the SSP  
>> applies to all modes of transport. Otherwise the Bad Guys will just  
>> send mail like the following:
>>
>> Received: by bar.com from foo.com by SMTP ...
>> Received: by foo.com from ebay.com by UUCP ...
>> From: zevuvqao@ebay.com
>> [NO DKIM signature]
>
> Agreed.  This issue does not appear to have been entered into the RT  
> tracking, but both you and Jim have suggested this alternative  
> solution.  Here is a more formalized suggestion for a tag added to the  
> policy record.
>
> s= Policy Scope (plain-text; OPTIONAL; default is "SMTP").  A colon-
>     separated list of policy scopes specify which protocols to which
>     this record applies.  Verifiers for a given service type MUST
>     ignore this record if the appropriate type is not listed.
>     Currently defined service types  are as follows:

No! The default must be '*'.
>
>         *   matches all service types
>         !  disavows protocol use
>
>         SMTP	RFC2821
>         NNTP	RFC3977
>         MSRP	RFC4975
>
>     This tag is intended to constrain the use of policy for various
>     transport protocols that may implement, should DKIM be defined by
>     other protocols in the future. This tag can also disavow use
>     of specific protocols to repudiate references to this domain.

But you have to make it clear that verifiers can only discern the protocol  
used by the originating site by carefull examination of Received headers  
(and believable ones at that). So I am still very dubious about adding  
this feature.

-- 
Charlesï¿½H.ï¿½Lindseyï¿½---------Atï¿½Home,ï¿½doingï¿½myï¿½ownï¿½thing------------------------
Tel:ï¿½+44ï¿½161ï¿½436ï¿½6131ï¿½                      
ï¿½ï¿½ï¿½Web:ï¿½http://www.cs.man.ac.uk/~chl
Email:ï¿½wyz@clerew.man.ac.ukï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Snail:ï¿½5ï¿½Clerewoodï¿½Ave,ï¿½CHEADLE,ï¿½SK8ï¿½3JU,ï¿½U.K.
PGP:ï¿½2C15F1A9ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Fingerprint:ï¿½73ï¿½6Dï¿½C2ï¿½51ï¿½93ï¿½A0ï¿½01ï¿½E7ï¿½65ï¿½E8ï¿½64ï¿½7Eï¿½14ï¿½A4ï¿½ABï¿½A5


------------------------------


