Jump to content

Headers incomplete - Nothing to do


Firefly

Recommended Posts

Over the past few weeks I have been getting a deluge of spam which the SpamCop email system properly filters into Held Mail, but which I can't report. The report page says:

This header is incomplete. Please supply the full headers of the spam you're trying to report.

No source IP address found, cannot proceed.

I see a source IP in the headers. The Received lines look like this:

Received: from unknown (192.168.1.88)

by blade2.cesmail.net with QMQP; 31 Dec 2008 20:18:44 -0000

Received: from unknown (HELO localhost) (58.220.253.242)

by mxin1.cesmail.net with SMTP; 31 Dec 2008 20:18:41 -0000

Why can't SpamCop identify 58.220.253.242 as the source IP?

Examples:

http://www.spamcop.net/sc?id=z2492328169z5...f8bc0a816f90f6z

http://www.spamcop.net/sc?id=z2492328239z4...e7ebf43b62335az

Link to comment
Share on other sites

Over the past few weeks I have been getting a deluge of spam which the SpamCop email system properly filters into Held Mail, but which I can't report. The report page says:

This header is incomplete. Please supply the full headers of the spam you're trying to report.

No source IP address found, cannot proceed.

I see a source IP in the headers. The Received lines look like this:

Received: from unknown (192.168.1.88)

by blade2.cesmail.net with QMQP; 31 Dec 2008 20:18:44 -0000

Received: from unknown (HELO localhost) (58.220.253.242)

by mxin1.cesmail.net with SMTP; 31 Dec 2008 20:18:41 -0000

Why can't SpamCop identify 58.220.253.242 as the source IP?

A quick look at SCBL indicates that 58.220.253.242 will be on the BL for the next 23 hours for sending spam to spam traps.

The listing also indicates that the dns listing has issues so can't send notice anyway. If they keep hitting the spam traps ("twice in the last 4.3 days") they will stay on the list.

I know that doesn't answer your question. But they are on the block list until tomorrow.

Link to comment
Share on other sites

Over the past few weeks I have been getting a deluge of spam which the SpamCop email system properly filters into Held Mail, but which I can't report. The report page says:

This header is incomplete. Please supply the full headers of the spam you're trying to report.

No source IP address found, cannot proceed.

I see a source IP in the headers. The Received lines look like this:

Received: from unknown (192.168.1.88)

by blade2.cesmail.net with QMQP; 31 Dec 2008 20:18:44 -0000

Received: from unknown (HELO localhost) (58.220.253.242)

by mxin1.cesmail.net with SMTP; 31 Dec 2008 20:18:41 -0000

Why can't SpamCop identify 58.220.253.242 as the source IP?

For exactly what the error message describes .... the header block contains some bad data. Specifically, the lack of "new lines" after content, starting with the Message-ID: line, including the From:, Date:, Content:, etc. lines.

Your sample issue appears to match exactly the content being discussed over in the newsgroups, the Archive link found at [scspamcop] Broken headers Tim McGraw No response yet provided from Don, Deputies, or JT.

Link to comment
Share on other sites

Yes, I agree it is the same issue. The emails I am getting are sent directly to my spamcop.net address, so there is no other mail host corrupting the headers. (I do not use this address in public, but it was on a domain registration so I am sure that is how the spammers got it.)

I received several more of these today.

Link to comment
Share on other sites

Yes, I agree it is the same issue.

I received several more of these today.

Newsgroup traffic has T.McGraw stating that a manual parse handled some of these, but attempting the VER interface remained a failure. I've asked for a bit more data 'over there' .... specifically a Tracking URL pf one of those that flew.

Link to comment
Share on other sites

I've commented in the NG thread - synopsis, I'm betting all/most of the damage is caused by the incorrect boundary declaration. When a boundary is declared:

Content-Type: multipart/alternative;

boundary=----=_NextPart_000_0023_36_B7116CD0.D0B0954A

and the first instance of a boundary encountered is:

------=_NextPart_000_0023_36_B7116CD0.D0B0954A

then 'most things' will see that as the end of the message becase it contains the 2 extra dashes expected in a termination. IF the boundaries are designated:

----=_NextPart_000_0023_36_B7116CD0.D0B0954A - as stipulated by the declaration, I'm thinking maybe the SC processing might handle it. Sure, the missing CR LF line break will cause a problem but maybe that too is an 'artifact' of the bodgied boundary. Certainly BOTH things need to be fixed for it to work as a paste-in for parsing and I'm only guessing that SC processing could do that little bit of mangling by eliminating a line break. In Tim McGraw's NG cases something in the SC handling is adding some X-line headers out of place which leads to the thought of that as a possibility.

Bottom line, we've seen much spammer mangling of message formats in the past, all of which which just faded away in time. Apparently they are (mostly/all) simple incompetence rather than a deliberate attempt to prevent SC parsing. Their persistence would depend on whether their payloads were readable by the target demographic or not, I suppose. I have no idea about that.

Anyway, here is one of Tim McGraw's tricked to work properly by adjusting the boundaries and by adding the missing line break.

http://www.spamcop.net/sc?id=z2497670889zd...a56a2ffc640c80z

I don't think it (they) can be made to work completely without both changes. It is not allowable to generate SC reports by making these changes, IMO.

Link to comment
Share on other sites

While we are on the topic of crippled MIME, I have been getting a lot of these (tracking URL) for the past few months. I expect that the MIME structure is buggered so that SpamCop won't peek into the body. I am not sufficiently motivated to pinpoint the problem right now, and anyway the source reports always work fine.

I suspect that lots of others get these as well. I'm wondering aloud whether this might be something that the parser could be modified to "forgive" and include in the analysis. After all, I suspect my mail program would forgive it and display the body for me.

-- rick

Link to comment
Share on other sites

While we are on the topic of crippled MIME, I have been getting a lot of these (tracking URL) for the past few months. I expect that the MIME structure is buggered so that SpamCop won't peek into the body. I am not sufficiently motivated to pinpoint the problem right now, and anyway the source reports always work fine. ...
It is exactly as I said before - the first (also second) instance of the boundary contains the 2 extra 'terminating' dashes thus the parser halts its quest, believing in strict accordance with RFCs that the message has terminated right at the start of the body (so, effectively there is none). Here it is with that defect corrected - http://www.spamcop.net/sc?id=z2504298945z0...3939b4206aa289z

But that is very interesting - the link in the spam is not detected anyway, I'm not quite sure why, some other form of 'non compliance' apparently (7/8 bit, 3D hexcode instead of "=" character, mumble, incomprehension ...) but in any event seems little point in making the MIME 'behave' because the payload is still undetected. And the parse of the headers is different. Okay, no mailhosting set up for 'mine' and (is that the reason?) 'yours' and 'mine' deal with

Received: from 206.46.232.11 ([116.74.118.3]) by vms169133.mailsrvcs.net ...

quite differently; "Verizon received mail from sending system 116.74.118.3" and "vms169133.mailsrvcs.net looks like a dynamic host, untrusted as relay" respectively. Yeah, I guess you have Verizon in your hosting and that's the difference there. You could verify it by trying the same 'doctored' version as mine (which simply pares off the 2 termination dashes in the 2 MIME boundary instances within the body - leaving the initial declaration and the final termination in original form).

...I suspect that lots of others get these as well. I'm wondering aloud whether this might be something that the parser could be modified to "forgive" and include in the analysis. After all, I suspect my mail program would forgive it and display the body for me.
That exact point has been made many times, in relation to many and varied parser 'shortcomings' though admittedly mostly in relation to undetected URLs. "We" have always supposed that spamvertizement-chasing is low priority and anyway it would be a major task to try to keep track of and safely emulate the outrageous things M$ in particular does to the 'standards' in order to give the punters what it decides they need in order to maximize M$ corporate advantage when said M$ cannot even assure the security of its products, in part because of resultant frenetic development (not to put too fine a point upon it and before my foaming alarms the office intern :D ).

But you're just wondering about that 'one' feature. Well, it wouldn't have made any difference in the case instanced. MIME and encoding do seem to keep coming up, one way or another though. But 'reading' the actual body content, the object of such suggestions, appears to have little official backing, as we know.

Link to comment
Share on other sites

I expect that the MIME structure is buggered so that SpamCop won't peek into the body. I am not sufficiently motivated to pinpoint the problem right now, and anyway the source reports always work fine.

I suspect that lots of others get these as well. I'm wondering aloud whether this might be something that the parser could be modified to "forgive" and include in the analysis. After all, I suspect my mail program would forgive it and display the body for me.

First line of the body is a BOUNDARY 'end' marker. Anything that tries to render anything beyond 'plain text' should see this line and stop 'processing' any further data.

Second line of body describes a 'plaint text' section, yet all content is wrapped within HTML mark-up.

The HTML section is wrapped by two more BOUNDARY 'end' markers.

Parser will not and will never try to work around those issues ..... any e-mail client operating in other than 'plain text' mode should not render any portion of that body.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...