Jump to content
Sign in to follow this  
mortician

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

Recommended Posts

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".

Share this post


Link to post
Share on other sites

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"

Share this post


Link to post
Share on other sites

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 by Farelf
amended advice

Share this post


Link to post
Share on other sites

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 by Farelf
correction DD-MMM-YYYY

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

... 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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

Thanks for all the input.

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×