Reporting time - - again

[Lking]

For all of you that are concerned about your "average reporting time" how would you handle this?

Link

In the "quick reporting data" email from SC they proudly declare "warning:Yum, this spam is fresh! Message is -3 hours old" Say what??

The date of the reporting data message is "Date: Mon, 24 Nov 2008 21:29:11 GMT"

The date of the reported spam is "Date: Tue, 25 Nov 2008 02:39:26 +0530 (IST)"

All the receive lines are close to "Received: (qmail 28755 invoked by uid 60001); 24 Nov 2008 21:09:27 -0000"

As has been said here on several threads, 'the meaning of the average reporting time is what?'

This is a record for me, reporting spam 3 hours before it was sent. (got to get a life)

[Farelf]

Yeah, everything trusted/mailhosted all the way down to the first server which happens to have wonky date setting. The parser never has tested for <0. The paranoid would say this is just another spammer way to tag/code their stuff, discover the secret identities of those who oppose them and crush them mercilessly beneath a further deluge of spam. Not me though.

[Wazoo]

The date of the reporting data message is "Date: Mon, 24 Nov 2008 21:29:11 GMT"

The date of the reported spam is "Date: Tue, 25 Nov 2008 02:39:26 +0530 (IST)"

Yep, still another aspect of the 'problem' with a MailHost Configured Reporting Account. In this case, it's the crossing of the DateLine that causes the issue .... note the IST timezone used which is +5:30. As Farelf notes, yet another small programming issue that should have been noted, really needs to be fixed. There has never been an explanation offered as to why the e-mail Date/Time selection decision is so dfferent between a MailHost Configured and a non-MailHost Configured Account/parse result .. of at least anything that made much sense to me ...??? I'm still of the thought that Julian never finished that code branch and the current programming crew just hasn't gotten around to figuring it out at all, but that's just me.