Tokugawa Posted October 14, 2005 Share Posted October 14, 2005 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. Link to comment Share on other sites More sharing options...
Farelf Posted October 14, 2005 Share Posted October 14, 2005 ... 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. Link to comment Share on other sites More sharing options...
Jeff G. Posted October 14, 2005 Share Posted October 14, 2005 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. Link to comment Share on other sites More sharing options...
Farelf Posted October 14, 2005 Share Posted October 14, 2005 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. Link to comment Share on other sites More sharing options...
Wazoo Posted October 14, 2005 Share Posted October 14, 2005 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 ..... Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.