Bug 1956 - Easy bypass of SA for spammers
Summary: Easy bypass of SA for spammers
Status: RESOLVED WORKSFORME
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamassassin (show other bugs)
Version: 2.54
Hardware: All All
: P5 normal
Target Milestone: 2.60
Assignee: Daniel Quinlan
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-05-23 14:48 UTC by Sidney Markowitz
Modified: 2003-05-23 07:29 UTC (History)
0 users


Attachment Type Modified Status Actions Submitter/CLA Status
gzipped spam spam_test.eml.gz application/octet-stream None Sidney Markowitz [HasCLA]
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Sidney Markowitz 2003-05-23 14:48:14 UTC 
While testing 2.54 I accidentally sent a spam message through spamc twice. It 
may or may not be relevant, but the message had already been run through SA 
2.43 and had the 2.43 format X-Spam* headers including the report. SA 2.54 
labeled it as spam the first time through, creating the report and the 
original message MIME attachments as it is supposed to.

When I ran that through SA 2.54 a second time, the result was not marked as 
spam. Some rules triggered, I guess from the spam report section, but the spam 
message went through unchecked.

This looks like a way that spammers could easily get spam to sail through 
unfiltered. Not that they would run spam through SA first, but make it a MIME 
attachment or whatever about the SA report format is keeping this one from 
being checked by SA.

I'll attach the spam I used after it was run through SA 2.54 once. To 
reproduce the bug, run it through SA (2.54) and observe that it is not labeled 
as spam.
Comment 1 Sidney Markowitz 2003-05-23 14:51:19 UTC 
Created attachment 985 [details]
gzipped spam spam_test.eml.gz
Comment 2 Daniel Quinlan 2003-05-23 15:28:51 UTC 
There's no bug here.

By running the message through SA 2.54 twice, it SHOULD get a different score.
The first time it goes through 2.54, the original received headers are replaced
with a single local one.  That means RCVD_IN_NJABL can't hit because SA now
thinks the message originated locally.  Spammers can't get around that because
even if they ran SA first, it would still come from their IP address.

In addition, the message hit DCC_CHECK.  DCC_CHECK is a bulk email test.
People report bulk messages as they are received.  That is, without the SA
markup.  If a spammer sent a message with SA markup, then THAT message would
be reported instead.  2.54 actually improves matters over 2.4x because it's
now possible for "spamassassin -r" to report the exact original message to
DCC, Razor, and Pyzor.  Before, in 2.4x, it was only approximately the same
as the original message (although it was usually close enough due to the
fuzzy matching algorithms in use by most of the distributed checksum systems).

So, everything is exactly as it should be, no hole for spammers, etc.
Comment 3 Daniel Quinlan 2003-05-23 15:29:07 UTC 
closing