Re: [Razor-users] Re: Trust (in numbers)

[Shane W. <sh...@sh...>]

On Sat, 29 Mar 2003, Chris Martin wrote:

> Thank you for your reply.
> 
> Running razor-check -d gives a lot of interesting text!
> 
> This spam (about a generic version of a medicine (?) with a name
> beginning with V) has been processed by SpamAssassin 2.50 and the
> original message is in a MIME part.

This is due to a change in the default behavior of SA in 2.5x called
safe report.  Look in the SA documentation for report_safe (which can
be turned off and may be what you want).

> Passing the whole email through razor-check gives the result "not
> spam".

This is because the "whole" mail you're referring to sounds like the
email that SA now surrounds the original spam in (so that people don't
even get an eyefull of anything offensive, web-bugged images don't
display, etc.

> Extracting the original spam from the MIME part and passing it
> through razor-check gives the result "is known spam".
>
> Well, the surrounding text of the whole email as received must have
> changed the signature, but there have been emails which have not been
> processed by SpamAssassin (one offering diplomas) which are clearly
> spam but which are said _not_ to be spam.

Not sure what this is about.  If SA isn't processing it, then what is
"saying" it's not spam?

> This one (the diploma one) has two extra headers due to POPing it from
> the ISP and delivering it locally but, otherwise, the text is much the
> same as everybody else gets -- the To: header has four addresses on it
> which presumably change during the spammer's run.
> 
> Even removing these two local headers doesn't change the decision that
> it is not spam.

I think this needs to be in big bold print somewhere because so many
people aren't aware of it, but Razor pays no attention to headers at
all.  Razor doesn't care where ir came from our what program sent it
(SA cares about such things, but not Razor).  It only hashes the email
body itself.

> Obviously, the SpamAssassin processed ones must be unprocessed before
> checking and, if necessary, reporting but should anything be done
> about the other ones before checking/reporting?

Again, search for report_safe in SA documentation (or on the mailing
list archive), since it sounds like you may want to turn it off.
Also, note that SA is now at 2.52 to fix a few bugs, particularly in
the bayesian learning code.

> P.S. Which exactly are the CF values in the output?

Borrowing from someone else's recent post, here's a line where you can
see the cf value (20, in this case, right before the >= min_cf):

sig=6NGa2mSKjG-Bq7AMOBWKgd0vjEQA: Is spam: cf 20 >= min_cf 6

-- 
Public key #7BBC68D9 at            |                 Shane Williams
http://pgp.mit.edu/                |      System Admin - UT iSchool
=----------------------------------+-------------------------------
All syllogisms contain three lines |              sh...@sh...
Therefore this is not a syllogism  | www.ischool.utexas.edu/~shanew