I occaisonally get this error message:

Finding links in message body
Header data found in body, aborting link detection

All of these were submitted using VER, without any modification. Is this due to corruption of the header or a tactic to block Spamcop parsing of links?

http://www.spamcop.net/sc?id=z778653289zb3...0fd5cb64fcbacdz

There is something strange about the 4th (from the top) Received line in that looking at the tracking URL view, there are several header lines connected to that Received: line. The strangest part is that if you View entire message, the headers look correct. It looks like that Received line is forged because there is no handoff to the Charter system (and the Charter IP is an end user one) and it COULD be something being done by the spammer.

I suggest forwarding this tracking URL to the deputies<at>spamcop.net address for further investigation and possible tweak in the parser.

Not exactly. It discloses private data, including mshalperin's email address, which, I think, it should not do.

Played with data provided via the Tracking URL ... Yes that line does look 'cooked' .. but I'll admit that I can't sort it out, guessing that all the intervening handling steps have messed up the actual encoding used in the original spam. That said, I built up an e-mail and sent up a request for assistance from above ....

Here is another example:

http://www.spamcop.net/sc?id=z778924695z4f...f7ccbcc1f1e0f9z

Again. I don't see any "header data" in the body of the spam, though the header itself looks strange. I found a link manually and processed it with DNSstuff.com. I forwarded this URL to Spamcop admin.

Copying and repasting your example seems to resolve fine, the parser works through it okay for me (does some additional munging):
http://www.spamcop.net/sc?id=z779110199z66...b5b3f8c4063cfbz
Does this tell us something? (As I have said before, it's all white man's magic to me)

The tracking URL in your message isn't the same as the one I posted. I still get the "Header Data found in body..." with the original URL!

Correct - *my* tracking URL points to the result of copying the spam message from *your* tracking URL and submitting it again. It works (for me) when subjected to that process. Just wondering if that sheds any light on what is going on (as to where/how the header might be corrupted). Means nothing to me but my hope was it might to someone else who actually knows more about this stuff. It does seem to make it unlikely that a deliberate spammer technique is being used to fool the parser.

Maybe there are unseen "blank" characters in the original header which spill over into the body and get filtered out by the copy/paste process... This still could be a deliberate tactic. I've been getting 1/2 of these a week for the last couple of months. Unfortuneatly, I haven't checked to see if they are from the same source. Is anyone else getting these?

I am, but they are reportable!

From my e-mail;

Sometimes when I get this error, I find that the spammer has either scrambled the order of the From: To: Subject: lines in the header or has spread them out in different parts of the header. Apparently Spamcop's parser can't handle that. If I delete these lines and resubmit, it accepts the report okay.

There can be a number of reasons for such 'scrambling'. How do you submit spam? Do you see the same when paste the spam into the webform and when you email it? A Tracking URL showing the original situation would be good. The problem with changing spam is that you may be making a 'material change' which is forbidden and could lead to you being banned or fined - see Rules - everybody read!. The safest thing, if there is any doubt, is to ask the deputies but, as said, if you care to post examples as tracking URLs you could get an opinion here.

I've seen the message from time to time. I don't think the To: matters but here is an example with Subject: present but all blanks IIRC Subject: missing is the same.

-- Header data found in body, aborting link detection
Here is your TRACKING URL
http://www.spamcop.net/sc?id=z2945463582z6...93cabd8ddf5fb9z

Changing this to Subject: none causes the message to go away.

-- Parsing text part, no links found
Here is your TRACKING URL
http://www.spamcop.net/sc?id=z2945489639z8...7299b29c0ca344z

These have "Sender:" rather than "From:" but I don't think that matters either.

HTH

Wow, thanks michaelanglo (I don't see the "Subject: present but all blanks", but that doesn't matter). Multiple weirdness - trying to replicate your broken example with current date (since these are, as dra007 pointed out 'way back then', reportable and wanting to see if there were any further clues/messages in the unreported spam dialog) produced with no mailhosting set:This disappears from the cancelled (US spelling be damned) report tracker but, sure enough, inserting a "From: nobody" (has to be something) makes the "Header data found in body" message go away - as seen (and "Subject:" absent): http://www.spamcop.net/sc?id=z2946446101z7...d400f1849ab6c2z

So, missing "Subject:" can invoke the problem, missing "From:" can invoke the problem, at least without mailhosting, and (example still to be tabled) out-of-sequence (but not missing) "From:" "To:" and "Subject" headers are said to invoke it BUT, paradoxically, deleting them is said to make it go away. We need Xoxcatpl input/examples on that.

This will be of interest to the deputies, I'm fairly sure adding bogus data would be out of the question (especially since reports to the spamsource hosts are still generated) but the deputies would need to rule on that. Equally (which is to say IMO only) sure deleting data would be out of the question. Deputies (and engineering) will be especially interested if it turns out this problem has resurfaced/changed as a result of recent changes to the parser code (I don't know). That would indicate the regression testing was somewhat deficient - though, they would probably say, "in a non-critical way". Thing is, in the interests in not 'tempting' users WRT to breaches of the 'material changes' rule it would be better if it didn't happen.

So, as far as I am concerned (for the benefit of others reading), waiting to see if Xoxcatpl (or anyone else) has further input before 'burdening' the deputies with these observations. In the meantime, remember dra007's 'bottom line' (earlier in this topic). They are still reportable, without alteration. If you want to alert hosts of 'spamvertizers', make a Manual Report. Just use the parser input form (with the spam URL only) to get the abuse address - if that includes 'devnull' it may indicate it would be imprudent to send a report.

[edit - just to add that the non-printable character in michaelangelo's example is the 'concatenate' (hex 1C, in the fake "Message-Id:" header) - there often is one in this sort of weirdness it seems - but removing it does nothing to the parse AFAICT]

...When I checked with mail hosting (although, of course, my mail hosting rather than with michaelanglo's), it also failed without the "From:" line (error message "Header data found in body")....Their reply may be "violation of RFC 822 A.3.1."

Thanks.True, why should they support the handling of anything so broken and so wildly at variance with the most basic standards? Against which the only real case to be put would be if these things (the premature terminations of parsing) are actually only re-appearing as a result of code changes. But I'm unaware of the results of Ellen's 2005 ticket.

In any event, one gets the impression that body parsing is a total pain in the nether regions for SC (with only intangible benefit to the corporation AFAICT) and quick reporting/VER is much preferred. It could be it wouldn't take much of an excuse to push the 'spamvertizement' notifications facility right off the menu. But of course I don't know that.

As I recall, the message used to appear before 22 January 2008 so not a recent change.

I had only seen this message in broken spams so my interest was solely in the fact that missing certain fields would stop the parsing of the header itself, ie not even Quick Reporting occurred.

The above date was a newsgroup post by - Don D'Minion - SpamCop Admin - whicch I noted as confirming that neither adding

From: nofrom
nor
Subject: no subject

were allowable alterations

Great information, + confirmation that changes - dummy header fields - are not allowable alterations, thanks once again. No doubt Don's NG post had the 'do not archive' bit set - I will have a hunt when I have time in case it didn't.

So, some variant(s) of these things is/are not even reportable? Well, as we know the networks will strive mightily to deliver stuff that they should never accept 'according to standards' and SC is not generally in the business of chasing such unknowable variation, even if the popular mail clients mostly manage to resolve it as something resembling a normal message. I'm guessing a lot of this/similar stuff is in fact filtered out/rejected by networks these days but all of that is apparently outside/additional to the present scope of this topic.

Unless I hear anything new soon which affects any of this, I will simply update the deputies ("still happens, reporters reminded changes - dummy header fields - to enable body parsing not permissible, there was a ticket ... if you would like to add anything ..." etc.)

Email sent.