mortician Posted March 8, 2015 Share Posted March 8, 2015 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.netabuse net cantv.net = postmaster[at]cantv.net, ipadmin[at]cantv.net, soporte[at]cantv.netUsing best contacts postmaster[at]cantv.net ipadmin[at]cantv.net soporte[at]cantv.netpostmaster[at]cantv.net redirects to abuse[at]cantv.netabuse[at]cantv.net redirects to soporte[at]cantv.net Can't parse date of spam for age detection: 2015-Mar-07 20:37:53". Link to comment Share on other sites More sharing options...
Lking Posted March 8, 2015 Share Posted March 8, 2015 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" Link to comment Share on other sites More sharing options...
Farelf Posted March 8, 2015 Share Posted March 8, 2015 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. Link to comment Share on other sites More sharing options...
mortician Posted March 10, 2015 Author Share Posted March 10, 2015 Tracking url: https://www.spamcop.net/sc?id=z6069509258zd12fd898515f90ab359152def5560a5ez Link to comment Share on other sites More sharing options...
petzl Posted March 10, 2015 Share Posted March 10, 2015 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? Link to comment Share on other sites More sharing options...
Farelf Posted March 10, 2015 Share Posted March 10, 2015 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! Link to comment Share on other sites More sharing options...
Dave_L Posted March 10, 2015 Share Posted March 10, 2015 In a case like this, would it be ok for the reporter to manually change the date in the header to an acceptable format? Link to comment Share on other sites More sharing options...
Farelf Posted March 10, 2015 Share Posted March 10, 2015 ... 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. Link to comment Share on other sites More sharing options...
Lking Posted March 10, 2015 Share Posted March 10, 2015 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. Link to comment Share on other sites More sharing options...
Farelf Posted March 10, 2015 Share Posted March 10, 2015 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? Link to comment Share on other sites More sharing options...
mortician Posted March 10, 2015 Author Share Posted March 10, 2015 Thanks for all the input. I forwarded the Tracking URL to 'the deputies' as suggested by Farelf. Link to comment Share on other sites More sharing options...
Lking Posted March 10, 2015 Share Posted March 10, 2015 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. Link to comment Share on other sites More sharing options...
mortician Posted March 12, 2015 Author Share Posted March 12, 2015 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. Link to comment Share on other sites More sharing options...
Lking Posted March 12, 2015 Share Posted March 12, 2015 Yes, mortician, that should scare the bejesus out of them! </sarcasm> Link to comment Share on other sites More sharing options...
Farelf Posted March 12, 2015 Share Posted March 12, 2015 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? Link to comment Share on other sites More sharing options...
teancum144 Posted September 17, 2015 Share Posted September 17, 2015 I'm having the same problem: https://www.spamcop.net/sc?id=z6163694297z3f7e11166227089198f44d2b88e1ebf1z Suggestions? Link to comment Share on other sites More sharing options...
Lking Posted September 17, 2015 Share Posted September 17, 2015 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. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.