multiple blank lines between header and body

[DavidT]

FYI, this is what's causin the problem:

The parser is added the x-checked info after the content type. I assume that's due to a lame mail program the spammer used.

Well, no, not necessarily. We don't know for sure how the OP is submitting. In the first post, he asked whether or not Quick Reporting was working, but didn't say that's how these mangled messages are being submitted. He also mentioned using Thunderbird, so it's possible that he's getting the messed-up source from Thunderbird, but we can't know much for sure unless he graces us with his presence and answers some questions.

DT

[Lking]

... he asked whether or not Quick Reporting was working, ... He also mentioned using Thunderbird, so it's possible that he's getting the messed-up source from Thunderbird, but we can't know much for sure unless he graces us with his presence and answers some questions.

David as you said this is all guess work, but I don't think Quick Reporting using Thunderbird is the issue. That is the process I use without problems. - Could be a bad install but...

Didn't I see somewhere in a header that the spam came through a SpamCop mail account? But others report from SC mail.

Oh will the OPer, having been told the same thing here and in the news groups and seems to have said 'think you' and gone.

[DavidT]

David as you said this is all guess work, but I don't think Quick Reporting using Thunderbird is the issue.

...but that's not what I'm (speculating, due to an AWOL OP) is going on. I'm guessing that he's doing something himself that's mangling the headers, and then pasting them into the web-based reporting form.

Didn't I see somewhere in a header that the spam came through a SpamCop mail account? But others report from SC mail.

Yep...and we never see the commingling of headers that was seen in the examples here. Hence, my theory that the problem might lie between the keyboard and the chair...

Oh will the OPer, having been told the same thing here and in the news groups and seems to have said 'think you' and gone.

Something like that...whatever....a big waste of time, actually...on to something more productive.

DT

[StevenUnderwood]

Yep...and we never see the commingling of headers that was seen in the examples here. Hence, my theory that the problem might lie between the keyboard and the chair...

David: Never would be an overstatement. I have seen these (though very few and several years ago). They showed the same "long non-split" headers as thie original here did in the parser (but not in the display version). I assumed at the time that they were spammer mess ups because the headers affected are ones that would be provided by the sending system, not those added by the receiving server.

[DavidT]

They showed the same "long non-split" headers as thie original here did in the parser (but not in the display version).

Are you referring to the TU supplied by Don?

I assumed at the time that they were spammer mess ups because the headers affected are ones that would be provided by the sending system, not those added by the receiving server.

Not sure I follow you. The headers misplaced in the example parse Don posted where not those from the sending server, but rather from the SpamCop email system...the X-SpamCop lines, which had body elements misplaced above them. I'm not understanding you, and I still think we're simply wasting time due to a lack of cooperation from the OP.

DT

[Farelf]

...and I still think we're simply wasting time due to a lack of cooperation from the OP.

The OP has given more detail on his submission process in the NGs - and clarified that the mangled headers-body were exactly how they were received. That would be the SECOND tracker Don provided. There may be things to learn but the NG is his preferred venue and that is where he has continued. If there is a conclusion over there it will be noted here.

[StevenUnderwood]

Are you referring to the TU supplied by Don?

Not sure I follow you. The headers misplaced in the example parse Don posted where not those from the sending server, but rather from the SpamCop email system...the X-SpamCop lines, which had body elements misplaced above them. I'm not understanding you, and I still think we're simply wasting time due to a lack of cooperation from the OP.

Yes, the second TU:

http://www.spamcop.net/sc?id=z2187237559z9...a3c3c540035c44z

SpamCop's server is not looking for specific headers to place it's own headers, it is looking for that first blank line which indicates the end of the headers. I see no blank line before the spamcop headers where SpamCop "misplaced" it's headers.

Looking at the headers as the parser did (not as displayed in the "Display" view), the long line of headers starting with "Message-ID:" are all provided by the sending server, all the way to the "------=_NextPart" line. If the spamcop server did not detect any blank line until after that line, all those lines are detected as headers and SpamCop adds it's X-SpamCop-* lines at that point.

Even in the "Display" view, there is no blank line before the MIME boundary to indicate to the receiving server the the body is beginning and for SpamCop to add it's headers.

Now, I admit that this could be something the sending machine is doing or some problem with SpamCop's servers (under very specific conditions maybe) or some fluke in the transmission. In my experience it is very rare (way before the current set of servers was implemented).

That one long line is what is actually causing the unparsable result, however, as the parser does not see the individual headers in the line and as Don mentioned, the parser does not see all the headers it needs to see to determine it is a full set of headers. This explains why the display view parses fine (even without removing the multiple lines as done by the OP). It has fixed that one long line.

The one long line is the thing I have seen in the past.

[DavidT]

This explains why the display view parses fine (even without removing the multiple lines as done by the OP). It has fixed that one long line.

The one long line is the thing I have seen in the past.

Ah...thanks. Now I'm starting to get it. I'm left wondering why the "display" view would show us something other than the actual raw source of the message, in that the link that brings it up is labeled "View entire message." That view should, IMO, show us the raw source of the message, as submitted, with only the munging that the system performs to protect the identity of the reporter. If there's additional reformatting going on, that's news to me (and I rather doubt that it's covered anywhere in the FAQs).

DT

[scubak1w1]

Hello,

I am getting spam with multiple blank lines between the header and the body...

(i) is Quick Reporting reporting or dropping spams of this nature?

(ii) if using the 'full reporting', can I legitimately edit the spam to have just one blank line between the headers and the body, and the parser will process the header at least? (e.g., http://mailsc.spamcop.net/mcgi?action=gett...rtid=3419147922)

(iii) how should I edit the spam to get the parser to see the body as well? (as Thunderbird sees it just fine, if I choose to open it)

(iv) If this sort of editing is "OK" (ish), do I need to add a note to that effect? (much like adding a "[no body]" note as a body for header-only spams?)

Cheers:

skiwi

Wazoo asked that I give a SUM of what was noted over in the newsgroup in various responses, etc... (apologies by the way if taking it over there caused frustation and confusion, even though I mentioned that I was doing that...)

Here are some quotes with some snippage, including from my self, that I think might be pertinent to the original question - as well as confirming IMHO that I in no way mangled the submission somehow as has been suggested here and there...

scubak1w1 [at] 08/31/08:

In reply to other [posts], this is how the spam arrives at my "spamcop.net" In Box - no changes are made as part of the reporting process. SpamCop catches these spams, I go to mailsc.spamcop.net, Held Mail, and IF I decide that day to do full reporting this is what I see for these spams (I full report (sic) every few days a number of emails to try and ensure that the mailhosts are still "set right", etc.)

Otherwise I Quick Report from Web Mail - and would not see these emails not being parsed of course (and to be frank, I only cursorily scan the Quick Report [summary] emails that the SpamCop sends me.)

[address]id=z2196747351z6ba68eb26809c77d606d0bd53e487873z shows the spam EXACTLY how the email is presented to me by the SpamCop system - no cutting and pasting as no need of course. Presumably this is an email sent to my InBox that SpamCop (validly) intercepts and sticks in my Held Mail for me to process using the provided tools. This is all "teaching my grandmother how to suck eggs" to you all, but I just wanted to confirm that I have no reason to work outside the tools provided.

Mike Easter [at] ### inline context with above, see newsgroup for that if you need this exactly:

[snip]

If I copy that item, introduce some missing empty lines, and move the 2 displaced spamcop filter's xlines back into the header where they belong, I get this satisfactory experimental parse:

http://www.spamcop.net/sc?id=z2204381662z8...6e17ab43540c0az this email is too old

If reported today, reports would be sent to:

Re: 210.101.195.35 (Administrator of IP block - statistics only)

cglee[at]primeit.com

Re: http://independencehelp.com/ (Administrator of network hosting

website referenced in spam)

abuse[at]comhem.com

<too old relieves the need to cancel.>

[snip]

I'm still accepting the veracity of your description and I'm still saying the original spam is slightly flawed and something about its flaw results in the spamcop filter mishandling the header/body relationship which

aggravates the original flaw into a worse one. The combination of the original flaw and its aggravation by the headerline placement of the filtering header stamping process results in a suboptimal parse.

I'm still accepting that your handling is not what is mangling the placement of the filter's xlines into the spambody.

SpamCop Admin, back channel [at] 09/06/08:

The problem is the "Message-ID" line... The subsequent lines, such as "From", "To", "Subject", etc have gotten run together with it into one long line. The long line itself is OK, but it prevents the parse from seeing critical elements of the headers, such as the lines that are run into the "Message-ID" line, and fools the parse into thinking that the headers are incomplete.

This is all one long line in the headers:

Message-ID: <b288019dbcdc$2a2b2884$53b854ee[at]sesmail.com> From: "=?windows-1251?B?QWJiaWUgQ2hhbWJlcnM=?=" <silvesterm[at]sesmail.com> To: <skiwi[at]spamcop.net> Subject: =?windows-1251?B?U29sdXRpb24gZm9yIHlvdXIgc2V4dWFsIGxpZmU=?= Date: Fri, 29 Aug 3609 13:23:17 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=----=_NextPart_000_0023_78_47D9E246.5E19FA3C X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180

Nothing I can do about that.

- Don D'Minion - SpamCop Admin -

[munge]

http://www.spamcop.net/

Thanks for all your replies here as well, at least the ones that addressed the original question!

[Wazoo]

Wazoo asked that I give a SUM of what was noted over in the newsgroup in various responses, etc... (apologies by the way if taking it over there caused frustation and confusion, even though I mentioned that I was doing that...)

Wrong!! Wazoo said that feedback was needed in several places, starting with this Topic. What I was looking for was answers to a number of questions asked. As I stated in the newsgroup, I am still waiting for a response to my questioned scenario about your multiple acounts. Your offer of deleting both accountsz so you can then re-register yet another is not acceptable.