Re: error: couldn't parse head

Flower Power wrote:

> This is my first post, and I'm a spamcop newbie, so I hope this is
> posted in the correct group.

Sure;  this is fine.

> In posting the following spam to spamcop today:
>
www.spamcop.net/sc?id=z813081185zd334b68a2fec1233180387e3a14cac64z

Good start;  posting a tracker is the absolutely best way to communicate
about any problem involving a parse of a spam -- or also to show a spam
or mail for other reasons than parsing problems.

> I noted the error message "error: couldn't parse head" in the report
> and read the associated FAQ file.

Excellent.  Your tracker also allows me to see the verbose parsing
result, which shows me that you are configured as being mailhosted.
Further, the tracker gives me access to a 'copy' of the original spam.

The 'couldn't parse head' in this case actually means the header was
parsed, but not the body.

> The FAQ indicates that the error was
> probably  that the "Content-type" header is not indented when carried
> over to a second line. The FAQ further insists that I introduced the
> error, but it appears to me to be in the original message.

That content-type header line is the root of the problem.  It is
'funky'.  A content-type headerline doesn't normally contain a
datestamp, much less an improperly wrapped datestamp.

Just for experimental and demonstration purposes [that means do *not* do
this to 'solve' the problem] - an identical spam which parsing isn't
mailhosted and which does /not/ have the faulty content type condition
[that is, turned into a 'normal' content type condition absent the bad
or spurious datestamp line under the content type line] shows this
normal parse result:

http://www.spamcop.net/sc?id=z813118971zb034f81cfaf92481191f0774d572c98az

Report Spam to:
Re: 72.25.27.57 (Administrator of network where email originates)
   To: [email protected] (Notes)
Re: http://qqrtexfa6npb8.mononame1.com/?ra=s1250 (Administrator of
network hosting website referenced in spam)
   To: [email protected] (Notes)

<cancelled>

... meaning that the parser was able to parse the body when there isn't
a faulty header condition.  See description of normal headers below.

> My reporting method is to preview all messages with an old version of
> MailWasher (version 1.32), from which I copy and paste the offending
> message into spamcop and then delete the message without it even being
> picked up by my mail reader (Thunderbird). This method has worked
> flawlessly for several weeks/months, now, so I can't see any error on
> my part. I even cancelled the first report and resubmitted the
> offending message--with the same result.

I'm not able to answer for you why the bad line 'crept into' the
headers.

> So, I guess my point is to question the certainty of the FAQ entry or
> to determine if, in fact, I really did something to cause the error.

SC will not parse 'faulty' headers.

The rules for headers is that headers are supposed to have proper
'beginnings' of lines, which is the header field which contains no
spaces and ends with a colon space.  Then follows the header value which
is either all on one line, or, if the line wraps, the 'wrappage' must
result in the proper leading whitespace before the rest of the header
value.

The 'end' of the header or last headerline is 'signalled' by an empty
line.  Then the body begins.  So, if any lines should come along which
do not conform to that condition, SC will recognize that something bad
has happened to the header or to the relationship between the header and
the body.

The bad thing which came along in this case was that datestamp just
under the content-type line of the header.  That line does not conform
to what I described above and it 'screws up' the header and/or header to
body relationship, so SC has to bail on the parse of the body.  It
provides a parse of the headers for source, because SC can 'understand'
that much of the header situation.

-- 
Mike Easter
kibitzer, not SC admin