Parser bug?

[Tokugawa]

Hi folks. Great service you've got here. I just encountered a small problem this morning -- the Spamcop parser wouldn't accept this email:

Return-Path: <***[at]***.***>
Delivered-To: ***[at]***.***
Received: (qmail 41658 invoked from network); 14 Oct 2005 01:31:17 -0000
Received: from pcp04554093pcs.grey01.tn.comcast.net (68.54.109.131)
  by ***.***.*** with SMTP; 14 Oct 2005 01:31:17 -0000
Received: from ajax (ajax [137.24.18.178
])
	by .ajax.noc.ntua.gr (3.12.9p1/1.12.9) with ESMTP id hATLaiBS972108;
	Thu, 13 Oct 2005 20:22:15 -0600
Date: Fri, 14 Oct 2005 00:27:15 -0200
In-Reply-To: <27131128143048.B6002[at]doit.wisc.edu>
Message-ID: <27531129233551.K36466[at]noc.ntua.gr>
References: <27630224173406.A16320[at]doit.wisc.edu>
From: "Lynette Weiss" <***[at]***.***>
To: ***[at]***.***
Subject:  Your Account is Past Due

Sensational revolution in medicine!

Enlarge your p... (you can guess the rest)

I figured the problem might be the newline character after "Received: from ajax (ajax [137.24.18.178", and sure enough, once I deleted that the mail was processed without any problems.

Would it be possible for someone to modify the parser to accommodate tricks like this? If it's any help, the second "Received" header is the genuine one from my home server, so the malformed one after that is apparently spoofed and/or in the wrong place.

[Farelf]

... Would it be possible for someone to modify the parser to accommodate tricks like this? If it's any help, the second "Received" header is the genuine one from my home server, so the malformed one after that is apparently spoofed and/or in the wrong place.

34181[/snapback]

A problem I see with modifying the parser is it would then also accept malformations introduced by reporters too - viz http://www.spamcop.net/fom-serve/cache/368.html

This then becomes a Catch-22 situation, with the cardinal rule that it must be the full, unmodified headers presented for parsing and reporting (the full process). Rather than deleting the malformed line, you could make it all one - Received: from ajax (ajax [137.24.18.178]) and it should be fine. I guess (my opinion only) the official view would then be, you should use the data from the parse to make "manual" reports, rather than submitting the SpamCop reports - because the integrity of the SC system has been compromised through "correcting" the spammers mistake.

[Jeff G.]

This situation doesn't exactly qualify for Request for Sample Bad spam, but you may try to use the address there (deputy_samples[at]spamcop.net) anyway.

[Farelf]

And it belatedly occurs to me that of course Tokugawa was talking about deleting the "stray newline character" (thus making up the proper single line), not the whole line as I read it on the first pass. Thus that little bit of my initial response is redundant.

[Wazoo]

On the other hand, the use of a Tracking URL would make things a bit more clear .. at issue is whther there is extra content not displayed, spammer construct from the begonning, or the possible cut/past/e-mail app mis-handling of something else .....