Jump to content

No blank line delineating headers from body - abort


MyNameHere

Recommended Posts

I have gotten a couple of these in the past day or so. The parser chokes, saying "No blank line delineating headers from body - abort"

From what I see, the blank line between the headers and bodyis missing. Is your email client showing this as well?

This:

Message-ID: <2014___________________v468[at]pcrjtdxgcpwzrtx>
<html>

Should be this:

Message-ID: <2014___________________v468[at]pcrjtdxgcpwzrtx>

<html>

Link to comment
Share on other sites

My email client is the SpamCop webmail service.

In the email list, it shows "Unknown Date Invalid Address [No Subject]"

When it displays the email, it renders some of the body (the headline and a hyperlink) as part of the header information (between the To line and the Subject line). This is a bit disconcerting, because it means it can cause a webmail service to render HTML (and perhaps execute scripts) even when it's not set up to do that.

When I look at the source, you're right, there is no blank line. If I insert a blank line as you did, then parse the result, it parses properly.

Link to comment
Share on other sites

My email client is the SpamCop webmail service.

<snip>

...This seems like something you would want to bring to the attention of the e-mail admins, either via the help form or via e-mail or both. There may be a problem with CES e-mail or something the spammer is doing that they may need to address.
Link to comment
Share on other sites

...This seems like something you would want to bring to the attention of the e-mail admins, either via the help form or via e-mail or both. There may be a problem with CES e-mail or something the spammer is doing that they may need to address.

I will do that, but if it's a problem, it looks like it would be a Horde IMP problem, so they won't be able to do anything about it.

:rolleyes:

Link to comment
Share on other sites

To get the full headers and text of a message from the SpamCop webmail interface...

Open the message so you can read it. Then look for the "Message Source" command that is located in the little toolbar that is just above the message when you're reading it.

If you click on the "Message Source" command, it will open a new window in your browser and show you the raw email with full headers and text.

All you do then is copy the raw headers and body text and then open another browser window and go to our web form at http://www.spamcop.net/mcgi?action=mhreturn

Paste what you copied from the "Message Source" window into our web form and hit the "Process Sample" button.

SpamCop is looking for the full headers in one contiguous block of text, followed by a blank line, which signals the end of the headers, and then followed by the body text of the spam. The parse won't accept headers if there is no body text with them.

- Don D'Minion - SpamCop Admin -

service[at]admin.spamcop.net

Link to comment
Share on other sites

Thanks, Don--not to be disrespectful, but I already know how to get the source from the webmail interface, and I don't see how "Process Sample" helps because I already parsed the source and found out that it didn't work. We also know why: the spammer, perhaps deliberately, malformed the email by leaving out the blank line.

I am curious what the Process Sample page is for and whether there is a way to navigate to it from the SpamCop reporting system.

My last inquiry had to do with the fact that the webmail interface actually renders some of the HTML from the spam as if it were in the header. That sounds like a flaw that could turn into an exploit (getting webmail to execute a scri_pt, for example).

Link to comment
Share on other sites

To get the full headers and text of a message from the SpamCop webmail interface...

[...]

Paste what you copied from the "Message Source" window into our web form and hit the "Process Sample" button.

The button is in fact "Process spam"

Link to comment
Share on other sites

No idea. I've never seen that page before, don't know how to navigate to it, and don't know what it does.

The purpose of http://www.spamcop.net/mcgi?action=mhreturn is to submit your mailhost emails that are sent out on a test. Anyone who has ever setup mailhosts has used this link. I believe what Don was mentioning was to try and manually separate the header and body and see if it works.

Link to comment
Share on other sites

In reference to this forum thread.

I have received several spam messages that fit this description in the past week, and there are a couple of new issues:

  1. If I click on "View full message," SpamCop sends me a ".sc" file that, of course, the browser doesn't know how to open. I save it and open it with Notepad and see that it is a text file with no apparent line breaks. In Wordpad, it does show line breaks. I don't have the tools here to see what the line break character is.
  2. The SpamCop parser displays a very large portion of the message rather than just the headers, and it seems to know where the lines break, too.

As before, the parser fails to detect the body AS the body, and so is unable to parse any URLs in the body.

If I insert a blank line in the proper place and paste the resulting message into the parser, it parses normally, including the body URLs.

Example of parsing failure and unusually long message display:

http://www.spamcop.net/sc?id=z5923835285ze...ab314479fe9baaz

Link to comment
Share on other sites

  • 2 years later...

Given the length (time wise) of this and related threads, it appears not.  That does reflect the philosophy often seen in  similar threads, 'why can't SpamCop work around such-and-such mis-formed email?'  Generally if the email header does not conform with the standards, the parser throws it out. The resent problem with a double dot in URLs comes to mind.

The approach by the parser vs email applications:

  • email applications, like browsers try their best to be fault tolerant so that no matter what they receive they can display something. This makes the user happy with little risk.
  • SpamCop on the other hand wants to be absolutely sure they have correctly identified the source of the spam before impugning the reputation of an IP address. Guessing what a misformed header format could have been/intended to mean just adds another degree of uncertainty.  The risk are high that if to many errors are made SpamCop's reputation will suffer. Unfortunately, this does not make reporters happy.
Link to comment
Share on other sites

Archived

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

×
×
  • Create New...