Jump to content

X-SpamCop-Disposition in body of message


Recommended Posts

Posted

I've been using spamcop since March to tag and forward my mail. I use procmail to file away spam labelled with the header "X-SpamCop-Disposition: blocked".

However, for about a month now I've noticed some messages are slipping through because, for certain spams, spamcop is putting the X-SpamCop-Disposition tag in the body of the message. Almost all the spams that have had this problem are from the same spamhaus. While I'm willing to admit the possibility that I'm doing something dumb, my guess is that this is a bug in the way spamcop is parsing certain messages.

Here's an example spam that got tagged in the body of the message.

X-Coding-System: undecided-unix

Mail-from: From ymwjlrptdpxotc[at]chello.no Sun Oct 10 03:26:42 2004

Received: from c60.cesmail.net (c60.cesmail.net [216.154.195.49])

        by sark.cc.gatech.edu (8.12.10/8.12.8) with ESMTP id i9A7Qfmn008619

        for <xxx[at]cc.gatech.edu>; Sun, 10 Oct 2004 03:26:41 -0400 (EDT)                                       

Received: from unknown (HELO blade1.cesmail.net) (192.168.1.211)

  by c60.cesmail.net with SMTP; 10 Oct 2004 03:26:42 -0400                                                   

Received: (qmail 26951 invoked by uid 1010); 10 Oct 2004 07:26:41 -0000                                   

Message-ID: <20041010072641.26950.qmail[at]blade1.cesmail.net>

Delivered-To: spamcop-net-xxx[at]spamcop.net

Received: (qmail 26945 invoked from network); 10 Oct 2004 07:26:40 -0000                                     

Received: from unknown (192.168.1.101)

  by blade1.cesmail.net with QMQP; 10 Oct 2004 07:26:40 -0000                                             

Received: from dsl231-049-025.sea1.dsl.speakeasy.net (HELO hanjin.cowlove.com) (216.231.49.25)

  by mailgate.cesmail.net with SMTP; 10 Oct 2004 07:26:40 -0000                                           

Received: (qmail 8453 invoked by uid 509); 10 Oct 2004 07:38:39 -0000                                     

Delivered-To: xxx-info[at]xxx.xxx

Received: (qmail 8450 invoked from network); 10 Oct 2004 07:38:38 -0000                                   

Received: from adsl-69-225-43-171.dsl.skt2ca.pacbell.net (69.225.43.171)

  by hanjin.cowlove.com with SMTP; 10 Oct 2004 07:38:38 -0000                                             

Received: from chello.no (25.122.227.160)

by chello.no (Postfix) with SMTP id 05625556195854368205

for <info[at]xxx.xxx>; Sun, 10 Oct 2004 06:19:01 -0200                                                         

From: "Elvis Ouellette " <ymwjlrptdpxotc[at]chello.no>

Reply-To: "Elvis Ouellette " <ymwjlrptdpxotc[at]chello.no>

To: <info[at]xxx.xxx>

Subject: how are you?

Date: Sun, 10 Oct 2004 13:14:01 +0500

X-Mailer: Fnzawken 2.4

MIME-Version: 1.0

X-Scanned-By: MIMEDefang 2.21 (www . roaringpenguin . com / mimedefang)

----05625556195854368205

Content-Type:html;                                                                                           

        charset="ISO-8859-1"

X-spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on blade1

X-spam-Level:

X-spam-Status: hits=0.5 tests=FORGED_RCVD_HELO,MIME_HEADER_CTYPE_ONLY

        version=3.0.0

X-SpamCop-Checked: 192.168.1.101 216.231.49.25 69.225.43.171

X-SpamCop-Disposition: Blocked bl.spamcop.net

B;uy meds for 8O% 1ess than in regular st0re                                                                 

Or;der H;ere                                                                                                 

http://www.chum5sprayer.com/136/

Unfinish'd Things, one knows now what to call,

Most have the Seeds of Judgment in their Mind;                                                               

Elvis

----05625556195854368205--

And here's my .procmailrc.

PATH=$HOME/bin:/usr/local/public/bin:/usr/local/bin:/bin:/usr/bin:$PATH
MAILDIR=$HOME/.procmail      #you'd better make sure it exists
LOGFILE=$MAILDIR/from        #recommended

# Turn off biff notification until we know the e-mail isn't spam.
COMSAT=no

# Preserve last 100 messages in $MAILDIR/backup/.
:0 c
backup

:0 ic
| cd backup &amp;&amp; rm -f dummy `ls -t msg.* | sed -e 1,100d`



# SpamAssassin tagged spam? File in $MAILDIR/spamtrap. -BW March 2004
:0:
* ^X-spam-Status: Yes$
spamtrap

# Spamcop.net tagged spam? Stuff in spamtrap. -BW March 2004
:0:
* ^X-SpamCop-Disposition: Blocked
spamtrap


# CAN-spam Compliant e-mail. -BW June 2004
:0:
* ^Subject: SEXUALLY-EXPLICIT
spamtrap


# MIMEDefang found a virus? Delete the memo. -BW March 2004
:0
* B ?? ^A known virus was discovered and deleted\.
/dev/null


###
# If we get here, the message isn't spammy, so it should be put in my inbox.

# Re-enable comsat (biff) notification
COMSAT=yes

I'd appreciate any help, even if it's just to let me know I'm doing something wrong.

Thanks,

Ben

Posted

Small problem in that your sample spam isn't quite matching up, but ..... some conversation going on over in the newsgroups is basically looking at;

A particular spammer / system is spewing stuff out with a missing "Blank Line" between the header and body. Apparently, the parsing engine is snagging these spams, inserts its own header lines into where the the "end of the header" is seen, which turns out to be inside the actual body area. (In your sample, it appears that somebody/something re-inserted a blank line prior to the Boundary line .. I can't explain that, but .. )

Ignoring the issue that you've got something going on that re-inserted a blank line (the defang thing maybe?) .. you've hit the actual problem with your comment "Almost all the spams that have had this problem are from the same spamhaus." The fix ...???? I know Julian has spent some time on it, but you also have to look at the reality that this stuff is deformed and thusly, it really shouldn't render in an e-mail application, which would then follow that the spammer wouldn't be getting any return on the spew. However, .... Trying to program around this "problem" spam runs smack into the checks and verifications that the submittal was actually provided in an RFC compliant condition (or the two-part form iwas used correctly) .. so yes, the spammer is taking advantage of a specific scenario/condition ... [and now that we've educated another batch of spammers ....]

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...