Jump to content

"Header data found in body"


mshalperin

Recommended Posts

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

29622[/snapback]

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.

Link to comment
Share on other sites

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 ....

Link to comment
Share on other sites

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 ....

29629[/snapback]

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.

Link to comment
Share on other sites

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.

29639[/snapback]

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)

Link to comment
Share on other sites

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)

29681[/snapback]

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!

Link to comment
Share on other sites

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!

29683[/snapback]

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.

Link to comment
Share on other sites

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.

29684[/snapback]

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?

Link to comment
Share on other sites

From my e-mail;

From: "SpamCop/Ellen"

To: "Wazoo"

Subject: Re: VER & Parse problem

Date: Mon, 27 Jun 2005 08:28:59 -0400

Yes -- he wrote to us. I have opened a ticket on the problem.

Ellen

SpamCop

Please include all previous correspondence with replies

----- Original Message -----

From: "Wazoo"

To: Deputies

Sent: Saturday, June 25, 2005 6:49 PM

Subject: VER & Parse problem

> http://forum.spamcop.net/forums/index.php?showtopic=4434

> user states that VER was used from his SpamCop e-mail account.

> Parse failed ... The probable forged line has some issues,

> but I can't quite place the problem .. starts with a Tab, but

> the additional "line wrap" characters are dropped somewhere.

>

> Put plainly, the "displayed" submittal 'looks' OK ... but

> the parsed display hoses that line totally, thus leading to

> a failed parse (and a confusing error message (based on

> the displayed submittal) ...

>

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

> Submittal of this spam:

>

http://www.spamcop.net/sc?id=z778653289zb3...;action=display

Link to comment
Share on other sites

  • 3 years later...

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.

Link to comment
Share on other sites

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.
Link to comment
Share on other sites

A Tracking URL showing the original situation would be good.

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

Link to comment
Share on other sites

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.

...

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

...

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

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:
Please make sure this email IS spam:

From: ()

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]

Link to comment
Share on other sites

<snip>

missing "From:" can invoke the problem, at least without mailhosting,

<snip>

...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").
This will be of interest to the deputies,

<snip>

...Their reply may be "violation of RFC 822 A.3.1."
Link to comment
Share on other sites

...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")....
Thanks.
Their reply may be "violation of RFC 822 A.3.1."
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.

Link to comment
Share on other sites

... 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.

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

Link to comment
Share on other sites

As I recall, the message used to appear before 22 January 2008 so not a recent change. ...
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.)

Link to comment
Share on other sites

...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.
Link to comment
Share on other sites

  • 11 months later...

I frequently get spam peddling counterfeit watches that get this error on submission. I have found two things that cause it. One is in the subject line in the header, there are one or more words run together. If I insert a space between the words, the Spamcop parser will accept the mail without error. The other is some special character in the subject line. If that character is removed, the mail is processed okay. I don't know how these things trip up the parser, but this is what causes this error.

Link to comment
Share on other sites

If I insert a space between the words, the Spamcop parser will accept the mail without error.

If that character is removed, the mail is processed okay.

Just the obligitory reminder not to actually submit these modified spam messages as that could lose you your spamcop reporting account.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...