Jump to content

spams with no body


chriscapoccia

Recommended Posts

However, this spam seems to have a (poorly constructed) body with the blank line missing beneath the Content-Transfer-Encoding: 7bit when it reached spamcop (otherwise the x-spam* headers would be above that mess). The headers make it impossible to determine (though highly unlikely) whether the first received line Received: from unknown (x) (43.51.244.789) by 0 is valid.

It seems possible that spamcop received this message from the sending system (220.150.179.55) without the required blank line after the previous headers.

Link to comment
Share on other sites

I regularly recieve spams with no body. Is there a way to report these through spamcop? Here is one example:

http://www.spamcop.net/sc?id=z810095873z18...7b6eea18c6438cz

33420[/snapback]

I'm agreeing with SrevenUnderwood ... suggesting a look at http://forum.spamcop.net/forums/index.php?showtopic=3571 to perhaps get the gist of what's happening "under the hood" ... your sample has "body content" but something happened in transmittal somewhere and the all-so-important blank line between headers and body disappeared .. then the SpamCop e-mail parser attached its header lines below all that ., (though leaving a question as to where that extra blank line came from ..?)

If this is actually what was received, then modifying it to make the parser happy is against the material alteration rules. One can rather note that the source of the spam was identified nd that report/complaint was made available for sending .. the prime objective of the parsing and reporting tool has been met. (Noting that this actually seems to be a bit of a change, as in the past, the "no body" error would have simply came back with "nothing to do")

Link to comment
Share on other sites

Spamcop headers are being placed incorrectly in emails with a malformed body. The headers are being placed after the body instead of before.

Here is the email as it appeared without any modification:

http://www.spamcop.net/sc?id=z810448292zeb...3325ab468fd913z

The Spamcop headers should have been placed after the other headers, but was not. The email does not have the required empty line between the headers and the body.

The empty line should have been inserted, and the Spamcop headers should have been added to create a result like this:

http://www.spamcop.net/sc?id=z810449245z9f...974e086f8787d5z

See also http://forum.spamcop.net/forums/index.php?showtopic=5018

Edit: moved from the E-Mail Forum and merged into this existing Topic .. subject matter is the same .. PM sent to advise of this Move/Merge

Link to comment
Share on other sites

Spamcop headers are being placed incorrectly in emails with a malformed body. The headers are being placed after the body instead of before.

As was pointed out in the previous posts in this Topic/Discussion.

The Spamcop headers should have been placed after the other headers, but was not. The email does not have the required empty line between the headers and the body.

Again, yes, as previously described.

The empty line should have been inserted, and the Spamcop headers should have been added to create a result like this:

33503[/snapback]

I believe you are mistakenly believing that the "insertion of 'the' blank line" is done on the receiving system. It doesn't work like that. That missing blank line was (more than likely) done at the insertion/injection of that e-mail, either by the sender or the combination of the sender, sender's tools, and the server being connected to by the sender (considering that it was 'dropped' by another server along the way is a real stretch) These 'additional' lines at the SpamCop server follow the RFC and attempt to add those lines at the "first blank line" in that e-mail construct, which should be that blank line between the header and body ... In your samples, the "first blank lne" doesn't appear until the end of the body.

Additional note: no reference made to Jeff G.'s referenced links in linear post #2 here ... specifically, the Announcement entry on (your) displayed Forum name ... intentional???

Link to comment
Share on other sites

  • 3 weeks later...

I know I've started threads before discussing spamcop headers appearing at the end of mail when there are no empty lines separating the headers from the body, but this is different.

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

The spamcop headers somehow got into the mail just before the end of the message. After the headers, there is one more line of asian spam.

The spam should have looked like this:

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

Link to comment
Share on other sites

I know I’ve started threads before discussing spamcop headers appearing at the end of mail when there are no empty lines separating the headers from the body

34215[/snapback]

And as such merger into one the last Topics you started ... which never actually for 'Resolved' ... other appointments have my attention right now ... PM sent to notify of Move/Merge

Link to comment
Share on other sites

Different but the same story. This message just had a blank line in the body it was sending to you, which defined the official end of the headers.

Spamcop (and any RFC compliant mail server) should see the whole top part of the message as headers and place any addendums to the end of the headers where the first blank line is, preserver that blank line and transmit the rest as the body of the message.

Link to comment
Share on other sites

Can you check to see why the spam at this tracking URL gets the "no body" error when it most certainly both has a body and has 3 blank (did an 'od -c' on the saved mail message to verify the linefeeds) lines between the headers and the body?

http://www.spamcop.net/sc?id=z818240697zd9...089bae221107adz

submitted by pasting into the web form from the standard apple mail client after viewing as raw source. The body is not mixed in with the headers as submitted. I've seen a number of these over the last week.

Thanks.

Link to comment
Share on other sites

submitted by pasting into the web form from the standard apple mail client after viewing as raw source.  The body is not mixed in with the headers as submitted. 

34607[/snapback]

Apparently, something wrong with your cut/paste manipulations ... there is "no body" in your submitted sample ... http://www.spamcop.net/sc?id=z818240697zd9...;action=display only the headers made it for parsing ....

Link to comment
Share on other sites

Apparently, something wrong with your cut/paste manipulations ... there is "no body" in your submitted sample ... http://www.spamcop.net/sc?id=z818240697zd9...;action=display  only the headers made it for parsing ....

34610[/snapback]

Sorry but no. That was not my first submission of that message. I've been using spamcop for years. I thought of that first and I verified that the text was there before I submitted the form. I scrolled from top to bottom to be sure. If there's no body there, the something went wrong after I pasted the message in.

I just repeated the same process with the same results.

http://www.spamcop.net/sc?id=z818252918z9c...3b34fac92dad73z

I verified the body was there before clicking submit. The 'od' of the saved message did not show any unusual characters between the headers and the body. I can supply the raw message on request.

Link to comment
Share on other sites

I just repeated the same process with the same results.

http://www.spamcop.net/sc?id=z818252918z9c...3b34fac92dad73z

34613[/snapback]

And unfortunately, I see the same issue/results .. no body in the submittal ... http://www.spamcop.net/sc?id=z818252918z9c...;action=display

PM sent for another approach ...

Copy provided, but in a 'text' format .. anyway, edited a bit, corrected yet another blank line issue, parse results found at http://www.spamcop.net/sc?id=z818265390z50...18427ea7bbe775z .... much different results ... (more PM traffic sent)

Link to comment
Share on other sites

looks like our hinet friends are keeping us busy again...

34620[/snapback]

Yup, the "blank line" is a header line that reads:

|Content-Transfer-Encoding: 8bit|

that gets stripped during spam form submission, leaving a "blank" line. Remove the '|' at either end. They were included to try and keep form submisson from removing the text as it does during spam submission.

Link to comment
Share on other sites

Yup, the "blank line" is a header line that reads:

    |Content-Transfer-Encoding: 8bit|

that gets stripped during spam form submission, leaving a "blank" line.  Remove the '|' at either end.  They were included to try and keep form submisson from removing the text as it does during spam submission.

34623[/snapback]

Ummmm .... let me say this to forestall any more conjecturing .... I was sent two copies of the same spam, two methods in "copying" the data into an e-mail were used (per the background commentary) ... both have different issues ... all isues pretty severe ... I have had some other things going on, so trying to sort out and try to guess at all that's going on / went wrong has not been my only mission these last hours .... I am also waiting for some other folks to respond to a couple of my queries on some specific issues (and apparently they are waiting for someone else to get back to them?) ....

So although the above data does "seem" to be true/visible (invisible) in one case, the other sample does not "match" .... and it's trying to (guess) analyze just what all the "extra" stuff is in the second example is and where it came from that has me spinning some wheels. I'm almost o the point of thinking about trying to resurrect my iBook one more time, but that's another 3 to 4 hour exercise in disassembly, repair, and reassembly .. not quite gotten myself in the mood just yet ....

Link to comment
Share on other sites

From a PM:

What about using java scri_pt to base 64 encode the entire message before submission, and then decoding it on the receiving side? Any scheme that encodes the data on the client side before submission so that the webserver doesn't muck about with it should work.

Any base-64 encoding/decoding would nornally be seen within the body of an e-mail ... header data is plain-test ....

1. parser would reject it/barf on it as no "header data" would be seen, not RFC compliant.

2. User actions like that could not be "auithorized" .. based on the vast numbers of the clueless in the real world. While a a number of folks might know enough to do something like this, the vast majority don't .. given a scri_pt/tool to "make it easy" would probably lead to yet more "why doesn't it work" scenarios.

3. As a "manipulated" submittal, you'd be asking for the "trust mode" that nothing was done to "muck" anything up in the pre-processed item .... unfortunately, that trust doesn't exist due to abuses from users/members in the past. Some folks munging to "identifying" things from an e-mail such that the result was of no value to anyone. Some folks using a (now extinct) web-site data list to add in addresses for certain spam complaints. These addresses were also scraped off the web, so complaints were hitting secrataries, human resource folks, financial folks, salesmen, etc .... Thus came the limits on how many addresses could be added as additional report recipients. And the first "limit" was then scoped down again due to continued abuse of that option. on and on ...

Link to comment
Share on other sites

Well someone once said....

In case of no body..

<no body>

Works great.

34693[/snapback]

Lack of a reference kind of leaves one wondering what you mght be talking "to" ... as this post shows up immediately afer a bit of discussion about a spam with screwed up headers (but does have a body) ...????

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...