Jump to content

Error message : This email contains no date


Freddie

Recommended Posts

http://www.spamcop.net/sc?id=z965065222z02...631cba12fa268az

As stated previously, SpamCop has a need to verify the timeliness of reports and I suggest that the date validation be done on the FIRST Receive line ONLY. This line must exist and be correct or my server could not have received it before I reported it.

Hmmmm, and as stated previously, the first (and only) Received Line: in this sample is "broken" .....

please read through this "discussion" from the beginning ... especially noting that the same software seems to be in use ...

Link to comment
Share on other sites

  • 2 weeks later...
  • Replies 79
  • Created
  • Last Reply

Is this an example of the same problem, or something else? http://www.spamcop.net/sc?id=z976884779z6f...599942ba2df7afz

More or less the same - the parser has decided the source is IP address 125.244.22.130 in Bora.net but the date/time for that entry is misconfigured -

Sun Jun 18 05:58:52 UYT 2006

instead of something like

18 Jun 2006 05:58:52 -0300

Not sure how this could happen - I would be suspecting that whole layer is spoofed.

Link to comment
Share on other sites

Not sure how this could happen - I would be suspecting that whole layer is spoofed.

Yes, that's what I thought too. AFAICT, the third Received header is the last one that can be trusted, but SpamCop seems to trust the relaying site for some reason, and that seems to be making it trust the last Received line, which is probably spoofed and uses an invalid date format.

Link to comment
Share on other sites

Yes, that's what I thought too....
Whatever the analysis, 'taint supposed to happen - maybe you would like to email deputies[at]admin.spamcop.net to see if it is something they would like to be aware of? Just include the link to your tracking URL (or your post here) and the suggestion that either the date handling in the parser needs attention or (worse) that a forgery is fooling it.
Link to comment
Share on other sites

  • 2 weeks later...

Over the past weeks I have received an increasing number of spams that I am unable to report through the SpamCop reporting service. Take the following as an example:

http://www.spamcop.net/sc?id=z985678412z0c...d0d18e40f2b113z

The parser says:

Can't parse date of spam for age detection: Wed Jun 28 09:35:01 UYT 2006
Message is old

It seems the same or a similar issue was discussed a few days ago, but as far as I can see, nothing really came of it.

What's stopping me from reporting this and other messages? Is it the bogus "UYT" timezone code, or is it SpamCop misinterpreting the "Received" headers? Should I contact the SpamCop deputies directly?

Link to comment
Share on other sites

It seems the same or a similar issue was discussed a few days ago[/url], but as far as I can see, nothing really came of it.

And because it appears to be "the same issue" .. this "new" Topic/post was merged into that existing discussion.

Link to comment
Share on other sites

What's stopping me from reporting this and other messages? Is it the bogus "UYT" timezone code, or is it SpamCop misinterpreting the "Received" headers? Should I contact the SpamCop deputies directly?
Whatever reason, it shouldn't be happening - suggest you contact deputies. In "your" case, FWIW, the whole Uruguay link looks bogus.

[sp]

Link to comment
Share on other sites

Oh yeah - if you do email Deputies, be sure to include a recent tracking URL showing the problem and details of what email setup and applications you use and exactly how in making your submission. Since there is a chance the original source is getting manged by the submission process it might be an idea to also provide a tracking URL for another submission that worked (to help eliminate some possibilities).

It could be as simple as a misleading error/warning message from the parser (like instead of the "full, un-modified headers are required" one) or it could be a significant flaw in the parsing - either way it should be kicked upstairs IMO.

Link to comment
Share on other sites

  • 1 month later...

The topic "Re: SpamCop parsing barfs on unknown timezones" has recently come up in the NGs. Mike Easter would hate to be quoted out of context but hope he would forgive carting over his opinion in this context:

"I think that the parser can handle RFC noncompliant timestamps from

other timezones, so programming for UYT would likely be possible."

So yes, it seems to me there would be a point to emailing Deputies concerning UYT (or other) timezone problems affecting the parser, re-affirming advice given earlier. (Mike's opinion is generally deemed to be well worth heeding).

[sp]

Link to comment
Share on other sites

  • 2 weeks later...

Just to bring this up to date. Current thinking is that might be an unrealistic expectation to have the parser changed. Note Wazoo's quote of Mike Easter's NG post in Spamcop can't parse date - I think it's the tz addr

A workaround for the dedicated might be to parse/submit through an account with no mailhost configuration since (apparently) the parser then deals with date lines differently.

Link to comment
Share on other sites

Me too... here is the source

Return-Path: <peterytdl[at]ilott.com>

Received: from centrmimpi01.cox.net ([68.111.106.84])

by centrmmtai09.cox.net

(InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP

id <20060815093743.CKGD13416.centrmmtai09.cox.net[at]centrmimpi01.cox.net>

for <dhanna[at]cox.net>; Tue, 15 Aug 2006 05:37:43 -0400

Received: from BSN-61-56-172.dial-up.dsl.siol.net ([86.61.56.172])

by centrmimpi01.cox.net with IMP

id A9YQ1V02g3iwhuW0000000

Tue, 15 Aug 2006 05:32:33 -0400

Received: from mail.jsl.com

by BSN-61-56-172.dial-up.dsl.siol.net (8.9.3/8.9.3) with ESMTP id 5T5nmz0bw8T8

for <dhanna[at]cox.net>; Tue, 15 Aug 2006 03:32:59 -0400

Received: from unknown (dsnat [168.166.166.9])

by mail.jsl.com with SMTP

for <dhanna[at]cox.net>; Tue, 15 Aug 2006 03:32:59 -0400

Reply-To: "Rosario Carroll" <peterytdl[at]ilott.com>

From: "Rosario" <peterytdl[at]ilott.com>

Message-ID: <2523481650.20060815033259[at]opcqethmo>

Date: Tue, 15 Aug 2006 03:32:59 -0400

To: <dhanna[at]cox.net>

Subject: Get replicas from Vacheron Constantin watch here

MIME-Version: 1.0

Content-Type: text/plain; charset="iso-8859-1"

Content-Transfer-Encoding: 7bit

Jaeger-LeCoultre replica watch – irreplaceable part of your image

Wanna amaze everybody with your taste? Buy the Chronoswiss watch

Noticeable discounts on replica watches from best brands

http://57txbvswawtv0nnlannlann5.wardwiteji.st/

Top-rank replica watches from Tag Heuer at best price

I submitted using forwarding the entire email first but when the error came up I went back through the forwarded email and used the submit form, receiving the same error. I can see the date just fine, why is it doing this?

Two emails this morning that were not processed because of this.

Link to comment
Share on other sites

... Me too... I can see the date just fine, why is it doing this? ...
Hi dhanna. IIUC there is a difference between the way the parser handles the datelines (specifically, which date line it "picks" as the key one) depending on whether mailhosts are configured or not. Once you have mailhosts configured, emailing or pasting-in methods both use the configuration.

Here is your example parsed without mailhosts (that is, using a separate account to the mailhost-configured one I usually use): http://www.spamcop.net/sc?id=z1031237867ze...5369eac249cd49z

You can see that "as advertized", the parse works fine. One trusts there's some excellent technical reason for the difference in approach but I'm afraid I haven't taken it on board. There's been some continuing discussion over in one of the NGs about it and the general concensus (and/or Mike Easter) seems to be that it is kosher IIUC. Obviously SC does too in which case the chances of getting it "fixed" are probably negligible.

So, to report such spam the options are to pick out the IP address of the spammer and manually find and report to the host or to maybe get a second account for the parsing as demonstrated. There are pitfalls in having two accounts, obviously it wouldn't suit many reporters. Depends how "dedicated" you want to be. Think most would content themselves with wishing a spot of myiasis on the perps and let it go. There's no evidence that it is a deliberate avoidance ploy.

[Having another look at your data, I'm blessed if I can see what was "wrong" with the dates in the first place - it's not the problem I thought, seems to be something else. Maybe you'd best post a tracking URL of one of your problem cases. The data you pasted in is badly mangled (line wrapping), "we" need to see exactly what the parser sees - could be something that can be fixed after all. Hopefully someone can look at it for you, past my bedtime in +0800!]

Link to comment
Share on other sites

Having another look at your data, I'm blessed if I can see what was "wrong" with the dates in the first place - it's not the problem I thought, seems to be something else. Maybe you'd best post a tracking URL of one of your problem cases. The data you pasted in [add - "here"] is badly mangled (line wrapping), "we" need to see exactly what the parser sees - could be something that can be fixed after all. Hopefully someone can look at it for you, past my bedtime in +0800!
Apologies dhanna, I must have been preoccupied with impending encotment. Occurs to me now (following decotment :) ) that you maybe can't get a tracking URL, that is if the parser refuses to file any sort of report. In that case, try to compare the "full message" depiction of what you are trying to parse (on a new attempt) with the example in the tracking URL I posted above. Conjecture is fruitless but that's never stopped me - seems like there might be some mangled lines, rather like the ones you posted above, which are somehow getting in the way. In that case it is presently unclear whether a non-mailhost configured parse would be any more successful than the normal attempt. To produce the parse that I did with your data I manually untangled the lines as you will see by comparing with the "source" from your post.

Identifying the precise source of the problem may suggest a solution to you or to those more experienced (not to include myself in that description) if you care to bring back some more information.

[Oh yeah, if you could confirm the application(s) you have been using. You've said you get the same error whether submission is by email or paste-in - if you could confirm no additional apps are involved, such as WordPad or Notepad. Review of all of the earlier postings in this thread might be enlightening.]

HTH

Link to comment
Share on other sites

http://www.spamcop.net/sc?id=z1031856297z6...f9b12db7dfe5f0z

Out of 50 I forwarded, about 10 came back with the no date error.

I use outlook 2003 and just forward the email through a gmail account (SMTP). All my email accounts have the mailhosts configured. I have been submitting this way for months with no errors until yesterday.

When I paste into the submittion form, I use Outlook with the spamsource add in.

http://www.spamcop.net/sc?id=z1031873098za...70f9382aeb7eabz

Another one, and it was about 10 min old when I sent it in

Link to comment
Share on other sites

I would be going with Wazoo on that, like (ignore line wrapping, those continuations are supposed to be indented)

Received: from YOUR-XHTR8HVC4P ([75.16.219.182])

by centrmimpi01.cox.net with IMP

id AQrQ1V00k3wipQT0000400

Tue, 15 Aug 2006 20:52:21 -0400

when maybe the expected is

Received: from YOUR-XHTR8HVC4P ([75.16.219.182])

by centrmimpi01.cox.net with IMP

id AQrQ1V00k3wipQT0000400;

Tue, 15 Aug 2006 20:52:21 -0400

The strange thing is, the line selected in the other example (my tracker) has a missing semicolon in that spot too, yet it parses (even though it is the "spam" line). Maybe that's another difference in the mailhost/no mailhost parses (not a reason to abandon mailhosts though). You could try a parse by pasting one of those examples in and manually inserting the semicolon, see if it works then. If it does it would be well worth raising with SC IMO.

[Regret I can't experiment for you from where I am just now]

Link to comment
Share on other sites

First Tracking URL offered up, parsed via a non-MailHosted account .. yep, slides right by ....

http://www.spamcop.net/sc?id=z1031904491z5...302ae65d304019z

Of course, this could (and probably does) also fall back on the decision point of "which" line to grab the Date/Time-stamp data from .... the top-most valid line for non-MailHosted parsing, the top-most 'foreign' line for MailHosted parsing .... right back to where we started <g>

Link to comment
Share on other sites

http://www.spamcop.net/sc?id=z1032231897z3...2fb0ff15ff211fz

http://www.spamcop.net/sc?id=z1032231951z7...2f9ab72ed96c0dz

http://www.spamcop.net/sc?id=z1032232034z3...6984ef38a19b7az

I guess the question now is, what has changed to cause this problem. I just do not have time to resubmit these, or mess around and figure out what is going on. The unfortunate thing is, if it does not report, I must move on and go to one that does.

Since I submit via forwarding the email, and I forward 30 to 40 at a time, they get dumpped in a folder for 20 days or so then deleted. I just do not have time to go back and find out which ones I submitted that did not report correctly.

We are in our busy season at work and I am working 60 to 70 hour weeks, have been for a month. I sent 6 in this morning and those three above had the issue.

Did the spammer come up with a cleaver way of avoiding being reported?

Link to comment
Share on other sites

It's all about the semicolon. All of the spam that I have had a problem with are missing the semicolon, and adding it in while manually reporting has solved the problem. Maybe a more sophisticated grep could grab the date even when the semicolon is missing, or grab it and do a semicolon insertion.

Link to comment
Share on other sites

...Did the spammer come up with a cleaver way of avoiding being reported?
Who knows, would classify it as a parser shortcoming myself. The experimentation from all sides seems to confirm it is unnecessarily "fragile" (thanks captkirk for further insight). Would think it worthy of a little programing effort, the effectiveness of the SCBL is a touch compromised in the meantime ...
Link to comment
Share on other sites

From: "Wazoo"

To: "SpamCop, Argyle"

Cc: "SpamCop, Deputies"

Subject: Date/Time stamp used for a MailHosted Parse

Date: Wed, 16 Aug 2006 15:21:49 -0500

Newsgroup traffic galore with no input from staff.

Once again, it's now an issue in the Forum, so I'm

taking the time to specifically ask .... is there any

work being done to resolve the Date/Time-stamp

issues involved in a MailHosted parse?

It has been documented for quite a while that;

the non-MailHosted parse snags the date/time from

the top-most valid Received line ... but the MailHosted

parse code seems to attempt to select that data from

(assumedly) the first 'foreign' Received: line.....

And even that issue isn't the end of it .... the code

involved seems to fail on a number of items that don't

seem to faze the non-MailHosted code.

http://forum.spamcop.net/forums/index.php?showtopic=6442

for instance .. I'm talking about a missing semi-colon in some

samples from yesterday/this morning ...

Newsgroup dialog included the failings of a UYT server and

those timestamps .... one of the most recent threads can be

found at;

Newsgroups: spamcop

Subject: parser showing no date

Date: Wed, 16 Aug 2006 08:02:49 -0700

Message-ID: <ebvbqt$2t1$1[at]news.spamcop.net>

Link to comment
Share on other sites

Thanks Wazoo, current parser performance in this regard is perplexing a good number of the vociferous (and who knows how many others), causing additional reporting time for some, reducing the effectiveness of the SCBL and perhaps prompting the occasional bit of "material alteration" - your ping was thoroughly justified IMO, signifying as it does something approaching a common cause.

Link to comment
Share on other sites

Thanks Wazoo, current parser performance in this regard is perplexing a good number of the vociferous (and who knows how many others), causing additional reporting time for some, reducing the effectiveness of the SCBL and perhaps prompting the occasional bit of "material alteration" - your ping was thoroughly justified IMO, signifying as it does something approaching a common cause.

What I find strange, is that everything was working just fine for me until about a week to 10 days ago, then I started seeing the "no date" message pop up. At first, it was only on a few messages; now, it's virtually every one I try to submit. What's the point in even submitting if the system won't accept the damn message?

Lyle

Link to comment
Share on other sites

What I find strange, is that everything was working just fine for me until about a week to 10 days ago, then I started seeing the "no date" message pop up. At first, it was only on a few messages; now, it's virtually every one I try to submit. ...
Thanks for clarification.

... What's the point in even submitting if the system won't accept the damn message?...
True, hopefully the powers that be will give this some priority accordingly. Not saying it is "their fault" - could be something external that has changed ... but a problem for some in any event.
Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...