Can't parse date of spam for age detection: 2015-Mar-07 20:37:53

[mortician 0]

Spamcop engine stalls when it gets this message, 'Can't parse date...etc.'. I have never gotten this message in the past (2+ years now).

Is a fix coming? I have gotten 4 of these in the last 3 days. Most were from our old friends at 'cantv.net'.

Excerpt, "Using abuse net on ipadmin[at]cantv.net
abuse net cantv.net = postmaster[at]cantv.net, ipadmin[at]cantv.net, soporte[at]cantv.net
Using best contacts postmaster[at]cantv.net ipadmin[at]cantv.net soporte[at]cantv.net
postmaster[at]cantv.net redirects to abuse[at]cantv.net
abuse[at]cantv.net redirects to soporte[at]cantv.net

Can't parse date of spam for age detection: 2015-Mar-07 20:37:53".

[Lking 0]

A tracking URL would be useful for the rest of us to see the complete header.

If you have received only 4 spam (from the same source?) it would appear to me that this spammer may have found a way to avoid being reported.

This thread may more correctly be under "reporting help"

[Farelf 0]

Yes, a tracking URL - http://forum.spamcop.net/forums/topic/4473-spamcop-glossary/#TURL

You don't have to wait for a new problem instance, you can retrieve an old one through your "Past Reports". Just don't quote the link with the Report ID (useless to others) you have to go to the report, follow the link to the parse, and pick it up from there.

The most common cause of "no date" recently has been goofy headers from goofy servers en-route. The "Received:" headers have to have both the IP address of the releasing server and a date-stamp from the receiving server (on the same line or continuation of the same line). The goofy headers split the information into two consecutive but separate headers. The parser can't work that out and will not offer to report if it can't determine that the age of the spam is within the allowable 48 hour window. There's no "fix" for that but lambasting the responsible parties and all their descendants in perpetuity is good catharsis.

[edit] Ah, belay that about getting the Tracking URL from "Past Reports". "Past Reports" detail is only kept for sent and cancelled reports, the links to "no date" cases won't be saved in your history, just a note "No reports filed" with date and time. Sorry about that - you will need to wait for a new instance after all and to be sure to copy and save the Tracking URL link before quitting the parser page.

Edited March 9, 2015 by Farelf
amended advice

[mortician 0]

Tracking url:

https://www.spamcop.net/sc?id=z6069509258zd12fd898515f90ab359152def5560a5ez

[petzl 0]

Tracking url:

https://www.spamcop.net/sc?id=z6069509258zd12fd898515f90ab359152def5560a5ez

Received: from core-mka10d.mail.aol.com (core-mka10.mail.aol.com [172.27.117.10])

Seems to be a intranet IP?

You getting headers from AOL WebMail?

[Farelf 0]

Thanks for the tracker mortician. Looks like the problem in that instance is that server webprd-a61.mail.aol.com is using a partial version the reversed date format of RFC 3339 (Date and Time on the Internet: Timestamps)/ISO 8601 - (YYYY-MM-DD) - instead of RFC 2822 (Internet Message Format) - DD-MMM-YYYY, and the parser can't handle that as revealed by the parser caution "Can't parse date of spam for age detection: 2015-Mar-09 22:05:51".

Not sure of the status of RFC 3339 (all my e-mails seem to use RFC 2822 format) but, since some of the internet evidently handles either-both, it would be nice if the parser did too and there may well be a case for a "capability upgade" - BUT the AOL usage isn't a precise implementation of RFC 3339 going by my rushed reading of it and we have the old problem that the parser can't possibly be tweaked for every idiosyncratic variation of the standards by which the major players are pleased to exercise their arrogance or ignorance at odd times.

Anyway, whatever we individual reporters see, the SC staff see a thousand time over. If the reversed dates are an emerging problem I would expect the Deputies to either be well aware of it or, in the event you have flagged the leading edge of what could develop into such a problem, they would very much want to be made aware of it. Can you e-mail deputies[at]admin.spamcop.net with your Tracking URL and a brief explanation in case it is the latter? In case they don't read it here.

Thanks for bringing this to attention mortician!

Edited March 10, 2015 by Farelf
correction DD-MMM-YYYY

[Dave_L 0]

In a case like this, would it be ok for the reporter to manually change the date in the header to an acceptable format?

[Farelf 0]

... would it be ok for the reporter to manually change the date in the header to an acceptable format?

Only Deputies or Admin could say.

[Lking 0]

Am I missing something?? From what you say Steve, the standards are either yyyy-MM-dd or dd-MM-yyyy The date objected to is yyyy-MMM-dd note the different month format.

As for changing the date so it passes the parser, I would think not. There is a slippery slop between changing the date in the header so that format requirements are met and changing the date so the 48hr requirement is met.

I'm sure others have better memories than I, but seems to me that changes that have been sanctioned have been limited to the body of the email, adding a blank line to mark the end of the header, truncating the body to get the size under 5kb, removing the body entirely - with a note. Changing the body so that links can be seen has not been approved. Any change to the header would bring into credibility the validity of any and all spam reports.

JMHO and I do not play a lawyer on TV.

PS what Steve said more succinctly.

[Farelf 0]

Am I missing something?? From what you say Steve, the standards are either yyyy-MM-dd or dd-MM-yyyy The date objected to is yyyy-MMM-dd note the different month format. ...

Well observed, what I should have said was dd-MMM-YYYY for RFC 2822 dates - earlier post corrected. Are you sure you're not Denny Crane?

[mortician 0]

Thanks for all the input.

I forwarded the Tracking URL to 'the deputies' as suggested by Farelf.

[Lking 0]

Are you sure you're not Denny Crane?

Yep I'm sure.... to lazy to look up the standard. Oh wait, A legend wouldn't have too. So we are back to a reversed, non-standard compliant, date. As with other variants in current discussions, 'Nothing to do' is my guess.

[mortician 0]

The Spamcop deputies said the date format error is AOL's problem. They said several requests to AOL to fix the date format problem had no results to date.

As a paid, monthly subscriber to AOL I forwarded the duputies comments to AOL with the tracking URL and requested they fix the date format error.

I am guessing the potential loss of $12.95 a month will scare AOL straight.

[Lking 0]

Yes, mortician, that should scare the bejesus out of them! </sarcasm>

[Farelf 0]

Thanks for the update mortician. I'm guessing that AOL date-time formats on servers sending to other networks are compliant or there would be more than just the occasional SpamCop reporter on their case. Either that or AOL's bizarre format has been accommodated by many/most other networks. I suspected that but the deputies response makes it seem unlikely. In which case AOL has found a neat way to avoid the bother of dealing with SC reports on spam reaching their network. Nice people! Presumably though, they have an internal spam reporting/flagging system for their members' use?

[teancum144 0]

I'm having the same problem: https://www.spamcop.net/sc?id=z6163694297z3f7e11166227089198f44d2b88e1ebf1z

Suggestions?

[Lking 0]

It is a quandary. If some servers will not make their email format compliant, should SpamCop adjust to their lack of standards or give them a pass on the spam?

There is a similar problem with web browsers and compliant HTML coding. In that case browsers want to display a webpage no matter how bad the HTML code. As a result, some non-compliant webpages look different depending on which browser is used. So the rendering may not be what was intended/correct.

And that is SpamCop's problem with email. If they can not be absolutely sure what is the correct parsing of the header, it is better to pass on reporting the spam than incorrectly accusing a source of sending spam.

So I guess, You win some, you lose some, and in this case you get rained out.