# [Solved] Dspam and Amavis

## coutts99

Hi,

I am trying to integrate dspam with Amavis.

Everything looks good except I can't get Amavis to score the message according to the dspam headers.

I have the following in my local.cf -:

header DSPAM_SPAM X-DSPAM-Result =~ /Spam/

describe DSPAM_SPAM DSPAM claims it is spam

score DSPAM_SPAM 5.0

header DSPAM_HAM X-DSPAM-Result =~ /Innocent/

describe DSPAM_HAM DSPAM claims it is ham

score DSPAM_HAM -2.0

I can see the dspam headers in the emails, and amavis is checking the message, but those rules are not working.

Anyone any ideas why?

CheersLast edited by coutts99 on Tue Dec 08, 2009 1:30 pm; edited 1 time in total

----------

## coutts99

Doh!

Restarting amavis helps  :Smile: 

----------

## cach0rr0

I trust dspam is clever enough to strip out forged "X-DSPAM-Result" headers, yes? 

If not, you are opening yourself up making that rule, big time - headers are easily forged. Unless dspam strips off any X-DSPAM-Result headers it sees (e.g. ones generated by a foreign host), easy loophole.

----------

## coutts99

 *cach0rr0 wrote:*   

> I trust dspam is clever enough to strip out forged "X-DSPAM-Result" headers, yes? 
> 
> If not, you are opening yourself up making that rule, big time - headers are easily forged. Unless dspam strips off any X-DSPAM-Result headers it sees (e.g. ones generated by a foreign host), easy loophole.

 

Thats a good point, and one I hadn't considered.

But if someone does go to the bother of doing that, then the worst that will happen is a spam getting marked down a bit. Suppose I could customise the header text for my installation, but I don't really consider it worth doing compared with the slight risk of a spam getting through.

----------

## cach0rr0

 *coutts99 wrote:*   

> 
> 
> Thats a good point, and one I hadn't considered.
> 
> But if someone does go to the bother of doing that, then the worst that will happen is a spam getting marked down a bit. Suppose I could customise the header text for my installation, but I don't really consider it worth doing compared with the slight risk of a spam getting through.

 

I'd def look into it. It's...fairly common actually, the forgery of SpamAssassin, DSPAM, etc headers, specifically for circumventing filters that utilise this type of rule. And it's not someone going through the trouble of doing so by hand, this would be something done by one of the very many well-written sophisticated spambots that would have such headers included in their spam templates. 

I would definitely customise the header content if possible - the more random the better, chunk this in as a marker

```

head -c 8 /dev/urandom | uuencode -m - |head -n 2 |tail -n 1

```

Probably overkill on the paranoia side using a chunk of urandom, but def steer clear of the defaults. I mean you may get lucky and never get burned by it, but it's all too common in the spam streams I've seen (work bollocks - last job was, in part, doing threat research for a commercial AS vendor; not to tout as credentials, merely explaining my reference point)

----------

## coutts99

http://osdir.com/ml/mail.spam.dspam.devel/2006-12/msg00012.html

Suggestion there of renaming any existing dspam headers before the mail is passed to dspam with postfix header_checks.

Might give that a go.

----------

## cach0rr0

looks like it should work, and is straightforward enough

haven't tried it myself. It does look like you can actually strip the headers altogether in postfix via "IGNORE" in header_checks

http://www.posluns.com/guides/hedrem.html

http://www.postfix.org/header_checks.5.html

 *Quote:*   

> 
> 
> IGNORE Delete the current line from the input, and inspect
> 
>               the next input line.

 

If that works I'd think it'd be better than leaving in superfluous headers - then again you may well want to keep those headers intact and score based upon them 

e.g. if it already has dspam headers that say it's spam, add 0.3, if it has ones already saying it's innocent, subtract 0.1

META rules are a very powerful tool in spamassassin as well. I don't know how much customisation you intend to do to your SA checks (I personally do a ton as one would expect!), but as an example:

foreign dspam header says innocent + your dspam header says spam == very suspicious

foreign dspam header says innocent + your dspam header says innocent == treat it as innocent

foreign dspam header says spam + your dspam header says spam == suspicious

foreign dspam header says spam + your dspam header says innocent == treat it as innocent

I say the first is very suspicious because it reeks of a classic header forgery. Any forged headers are a tipoff something is out of sorts. 

So take the 'very suspicious' example from above, say you rewrite the foreign headers from

X-DSPAM-Result: Innocent

to

X-Foreign-DSPAM-Result: Innocent

You might have a rule that looks like this:

```

header RH_DSPAM_REMOTE_CLEAN  X-Foreign-DSPAM-Result =~ /Innocent/i

score RH_DSPAM_REMOTE_CLEAN 0.01

describe RH_DSPAM_REMOTE_CLEAN foreign dspam header says innocent

```

and then for the locally-added dspam header

```

header RH_DSPAM_LOCAL_SPAM  X-DSPAM-Result =~ /Spam/i

score RH_DSPAM_LOCAL_SPAM 5.0

describe RH_DSPAM_LOCAL_SPAM local dspam header says spam

```

Now what if both of those rules are true? Here is where META rules come in:

```

meta DSPAM_HEADER_FORGERY (RH_DSPAM_LOCAL_SPAM && RH_DSPAM_REMOTE_CLEAN)

score DSPAM_HEADER_FORGERY 6.0

describe DSPAM_HEADER_FORGERY dspam clean header forgery

```

If you drop messages that have a certain SA score (rather, in this case SA is invoked by amavisd) and quarantine ones that are within a 'suspect' but not 'confirmed spam' threshold - I do personally, ymmv - this gives it the needed kick. 

Of course adjust the scores to your liking, mainly wanted to point out the ability to do such a thing. 

PS: don't mind me, just the incoherent thoughts of someone who fiddles with SA rules more than is sane =/

----------

## coutts99

All interesting stuff, thanks   :Very Happy: 

----------

