Parsing issue with date

Hi, the following header refuses to be parsed by SpamCop, netting the error 
"email has no date" but as far as I can tell, it does.  It is UTC +8
hours, 
but it seems fairly well-formed.

--- Begin Header ---
Return-Path: <x>
Delivered-To: x
Received: (qmail 24776 invoked from network); 28 Feb 2007 20:49:54 -0000
Received: from 218.0.116.189 by ns50.webmasters.com
Received: from urep ([103.227.106.189]) by ervyi (8.13.3/8.13.3) with SMTP 
id l1SL7gHB054779;
  Thu, 1 Mar 2007 05:07:42 +0800
Message-ID: <45E5EE36.1010502@maryboroughharcourts.com.au>
Date: Thu, 1 Mar 2007 05:03:50 +0800
From: Jake Y.Wise <x>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: x
Subject: excerpt
Content-Type: multipart/related;
 boundary="------------050104010607040102030507"
X-Spam-Filter[M]: F2_Possible_Virus_Attachment: .gif
X-Sent-To: x

--- End Header ---

Can someone provide an explanation?

Thanks,
DRS 

Posted to spamcop & .spam;  f/ups to spamcop

DS wrote:
> Hi, the following header refuses to be parsed by SpamCop, netting the
> error "email has no date"

Correct.

Here is your TRACKING URL - it may be saved for future reference:
http://www.spamcop.net/sc?id=z1239699092z8df677237381a9a23ada1429cfba48b5z

<SC> This email contains no date

> but as far as I can tell, it does.  It is
> UTC +8 hours, but it seems fairly well-formed.

No, whatever +8 date line you are looking at is not the correct one.

SC has a fairly specific method of reading the date/time, and it differs
for mailhosted vs nonmailhosted account parses, and it does not involve
using the Date: information which is easily forged.

The most important headerlines for tracing and determination of the
timestamp are the Received tracelines.  This item has two tracelines and
neither of them are compliant.

Tracelines need to contain a 'from' field with the IP from which the
server received the item, and a 'by' field with the domainname of the
server, and a properly configured time/date stamp after 'the other'.

SC derives the date 'generally' from the topmost good Received
traceline, in this case, the topmost Received traceline, which should be
the most reliable, is completely missing a time/datestamp.

The other next further down Received traceline is noncompliant in that
its 'by' does not contain the domainname of the server, and also, since
the topline is most likely the sourceline, that means the next line down
is a bogus line and it further means that your own server is the one
which is screwed up and noncompliant and not stamping its datestamp in
the traceline.

> Can someone provide an explanation?

-- 
Mike Easter
kibitzer, not SC admin

Posted to spamcop & .spam;  f/ups to spamcop

DS wrote:
> Hi, the following header refuses to be parsed by SpamCop, netting the
> error "email has no date"

Correct.

Here is your TRACKING URL - it may be saved for future reference:
http://www.spamcop.net/sc?id=z1239699092z8df677237381a9a23ada1429cfba48b5z

<SC> This email contains no date

> but as far as I can tell, it does.  It is
> UTC +8 hours, but it seems fairly well-formed.

No, whatever +8 date line you are looking at is not the correct one.

SC has a fairly specific method of reading the date/time, and it differs
for mailhosted vs nonmailhosted account parses, and it does not involve
using the Date: information which is easily forged.

The most important headerlines for tracing and determination of the
timestamp are the Received tracelines.  This item has two tracelines and
neither of them are compliant.

Tracelines need to contain a 'from' field with the IP from which the
server received the item, and a 'by' field with the domainname of the
server, and a properly configured time/date stamp after 'the other'.

SC derives the date 'generally' from the topmost good Received
traceline, in this case, the topmost Received traceline, which should be
the most reliable, is completely missing a time/datestamp.

The other next further down Received traceline is noncompliant in that
its 'by' does not contain the domainname of the server, and also, since
the topline is most likely the sourceline, that means the next line down
is a bogus line and it further means that your own server is the one
which is screwed up and noncompliant and not stamping its datestamp in
the traceline.

> Can someone provide an explanation?

-- 
Mike Easter
kibitzer, not SC admin

"Mike Easter" <MikeE@ster.invalid> wrote in message 
news:es513n$dtn$1@news.spamcop.net...
>
> SC has a fairly specific method of reading the date/time, and it differs
> for mailhosted vs nonmailhosted account parses, and it does not involve
> using the Date: information which is easily forged.
>
> The most important headerlines for tracing and determination of the
> timestamp are the Received tracelines.  This item has two tracelines and
> neither of them are compliant.
>
> Tracelines need to contain a 'from' field with the IP from which the
> server received the item, and a 'by' field with the domainname of the
> server, and a properly configured time/date stamp after 'the other'.
>
> SC derives the date 'generally' from the topmost good Received
> traceline, in this case, the topmost Received traceline, which should be
> the most reliable, is completely missing a time/datestamp.
>
> The other next further down Received traceline is noncompliant in that
> its 'by' does not contain the domainname of the server, and also, since
> the topline is most likely the sourceline, that means the next line down
> is a bogus line and it further means that your own server is the one
> which is screwed up and noncompliant and not stamping its datestamp in
> the traceline.
>

Thanks Mike.  I was afraid you were going to say that the last valid 
Received: line that wasn't a qmail internal forwaring would have to have a 
date on it.  Since I am merely a paying customer of a webhosting business, I 
probably won't have much luck in getting them to fix the issue, but I'll 
give it a shot anyway.

Thanks again,
DRS

DS wrote:
> "Mike Easter"

>> The most important headerlines for tracing and determination of the
>> timestamp are the Received tracelines.  This item has two tracelines
>> and neither of them are compliant.
>>
>> Tracelines need to contain a 'from' field with the IP from which the
>> server received the item, and a 'by' field with the domainname of the
>> server, and a properly configured time/date stamp after 'the other'.
>>
>> SC derives the date 'generally' from the topmost good Received
>> traceline, in this case, the topmost Received traceline, which
>> should be the most reliable, is completely missing a time/datestamp.

> Thanks Mike.  I was afraid you were going to say that the last valid
> Received: line that wasn't a qmail internal forwaring would have to
> have a date on it.  Since I am merely a paying customer of a
> webhosting business, I probably won't have much luck in getting them
> to fix the issue, but I'll give it a shot anyway.

I would definitely give it a shot;  the line is 'grossly'
noncompliant/incompetent.  Of the various types of noncompliant Received
tracelines 'we' run into around here, the webmasters.com one of your
example is one of the worst;  that is, I can't recall having seen a
traceline with no datestamp.  If I were the admin for the webmasters
server, I would be ashamed for people to be talking about 'my'
configuration of my server's line, and I would fix the problem
'immediately'.

Received: from 218.0.116.189 by ns50.webmasters.com

<end of line, no other components or folding>


-- 
Mike Easter
kibitzer, not SC admin