[Dspam-devel] [ dspam-Bug Tracker-3603022 ] False DSPAM headers confuse dspamc retraining

[SourceForge.net <no...@so...>]

Bug Tracker item #3603022, was opened at 2013-02-01 12:22
Message generated for change (Comment added) made by bcully
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1126467&aid=3603022&group_id=250683

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: v3.10.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brendan Cully (bcully)
Assigned to: Stevan Bajic (sbajic)
Summary: False DSPAM headers confuse dspamc retraining

Initial Comment:
I just received a spam email which included its own DSPAM headers (imitation is the sincerest form of flattery!), including:
X-DSPAM-Signature: 1,510c1e2526783905217225

The message also had legitimate DSPAM headers added by my dspam at the very end of the headers, but when I sent the message to dspamc for retraining, it errored out at the bogus header:
Feb  1 12:07:41 xxx dspam[xxx]: Signature retrieval for '1,510c1e2526783905217225' failed
Feb  1 12:07:41 xxx dspam[xxx]: Unable to find a valid signature. Aborting.

Perhaps dspam should keep looking if lookup fails, instead of giving up immediately?

Walking the headers backwards would also work for me since dspam's are at the end, but I could see that breaking with more complicated email flows that might involve passing through more than one dspam instance.


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

Comment By: Brendan Cully (bcully)
Date: 2013-02-01 14:28

Message:
Renaming the headers is probably a good idea (I guess dspam will still
treat them as spam/notspam signals the same way even if they're under a
different name), but I think it would still be a good idea for dspam to
search the entire header set for the signature when retraining.

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

Comment By: Tom Hendrikx (tomhendr)
Date: 2013-02-01 13:36

Message:
Typically you would configure your MTA to remove or rename the untrusted
headers before the message reaches DSPAM. It depends on the way you built
your mail stack, but I use this in postfix:

main.cf:
header_checks = pcre:/etc/postfix/header_checks.pcre

header_checks.pcre:
# Rename headers of incoming messages that might interfere with our own
setup.
/^X-(DSPAM-.*): (.*)$/m REPLACE X-External-$1: $2


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

Comment By: Stevan Bajic (sbajic)
Date: 2013-02-01 13:25

Message:
Thank you for clarification. Now I understand.

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

Comment By: Brendan Cully (bcully)
Date: 2013-02-01 13:15

Message:
I received a message that already had a set of DSPAM headers (generated to
fool spam filters, presumably). When my dspam received it, it misclassified
it as innocent and added its own second set of DSPAM headers:

From: ...
Subject: ...
Received...
X-DSPAM-Signature: bogussig
...
Received...
X-DSPAM-Result: Innocent
X-DSPAM-Signature: goodsig

The first set of DSPAM headers are fake, created as part of the spam
message to fool spam detection. The second set are generated by my DSPAM
instance when I receive the message.

I tried to reclassify the message as spam by bouncing it to my
spam-foo@domain address, which pipes it trhough dspamc --class=spam
--source=error. But reclassification failed because it took the signature
from the first X-DSPAM-Signature header, couldn't find it in my user
database, and gave up. If it had continued looking for the signature
instead of giving up, it would have found the second, valid signature and
succeeded at reclassifying the message.

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

Comment By: Stevan Bajic (sbajic)
Date: 2013-02-01 12:32

Message:
Hello Brendan, I don't understand what the problem is? Can you please
rephrase your problem? How did you pass that message to dspamc for
retraining?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1126467&aid=3603022&group_id=250683