Hi,

My problem is with the following I received today:
http://www.spamcop.net/sc?id=z1954830148z7...411be5e497d510z
http://www.spamcop.net/sc?id=z1954829934z4...4bb7ec5b780d51z
http://www.spamcop.net/sc?id=z1954829368z3...92e94fc6b74568z
http://www.spamcop.net/sc?id=z1954827442z2...8456a832f99e21z
http://www.spamcop.net/sc?id=z1954844477z2...67513c00844d66z
http://www.spamcop.net/sc?id=z1954844440z0...59b8ad11d88808z
http://www.spamcop.net/sc?id=z1954844362z4...cfc19b386d3875z
http://www.spamcop.net/sc?id=z1954841927zc...409937232723f9z
http://www.spamcop.net/sc?id=z1954841881z3...87c559f52a6394z
http://www.spamcop.net/sc?id=z1954841736zc...a02c77207dab90z
http://www.spamcop.net/sc?id=z1954863462z6...f4517ff6ed042ez
http://www.spamcop.net/sc?id=z1954864751z5...9bc6a8f4b2ba64z

Claiming to be too old.

I've never encountered this before when I've received the spam the same day.

Is this a bug or have spammers found the "perfect spoof" to avoid being reported?

Cheers!

The key is the date/time that the message was received by your ISP, not the date/time that you retrieved it from the ISP. The tracking information you posted indicate that the messages were received by your ISP - web-mania.com on May 31 making them now too old to report.

So, it was a fubar at my mail server?

Thanks for the info

Not really something that anyone here can guess at. All we've got to go on is the header data seen in your Tracking URL examples. They show e-mail received by your ISP on either 31 May or 1 June ... all seem to have been collected by your client on 3 June. Thus the 'too old' issue.

Hi,

I have been receiving email normally the other days, spam too. That's why I was wondering if it was something the spammer can spoof somehow?

I have a webmail panel as well as my pop3 and there was nothing "stuck" over those days

*whistles Twilight Zone theme*

...It seems unlikely that a spammer could cause your e-mail provider's incoming server to "stamp" the e-mail as having been received at other than the date and time it was actually received.

Spamcop has this mistaken concept that certain ISP's are "trusted", and will trust their timestamps, even though the reporting party is not a client of the "trusted" ISP, and the "trusted" ISP may have sat on the spam for an extended period of time before delivering it to the RP's ISP.

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

Except in this case, the samples I saw only had 1 set of received headers, which would need to be the OP's ISP.

Beating the daed horse yet again .... and here it appeared your were happy with the response you received from the Deputies in that referenced Topic. On the other hand, I also see that I brought it right back to the issue between the way a MailHost Configured parse and a non-MailHost Configured parse selects the Date/Time header line to use for 'age' determination.

As Steven points out, your example doesn't match the example being discussed in this Topic at all. This Topic is not about a MailHost Configured Reporting Account. There are not 'multitudes' of servers involved in the tranmission and receipt of the e-mail involved within this Topic. So actually, there is no link between this Discussion and the one you referenced.

Let get a couple things straight..

1. I can't see the original email that the OP was talking about, so I can't look at the headers to determine if this example is the same as the problem that I reported.

2. There is a distinct difference between understanding why the reports referenced in my complaint are being bounced, and agreeing with the rationale for parsing them in that manner. I understand why the reports are being bounced, and I STRONGLY DISAGREE with the rationale. I suggest that you go back to the other topic, and read my response (post #11), which was essentially my response to the deputies.

3. The response from the deputies stated that the process can't be changed, and my response indicated that I thought that that response was completely bogus. I never received a follow-up response, so NO, I am NOT SATISFIED with the response from the deputies.
As far as I can tell, given the lack of follow-up response from the deputies, the problem still exists, and I will continue to complain about the problem when I encounter it until the problem is fixed.

Having mailhosts configured, should simply push the date parsing out to the first mailhost in the MX path.
Spamcop knows where my MX path begins, and they certainly could change the date parsing to begin at the entry to my MX path, and not several hops upstream of my first MX, in space controlled by an ISP that I AM NOT A CUSTOMER OF, that is not in my MX path, and that I have no reason to trust (and several reasons not to).

It's sort of like FedEx or UPS marking a package as having been delivered at the time it arrives at their first sorting center, as opposed to the time it arrives at my door, several days, truck/train/plane rides, and sorting centers later.

In case you missed it, I run my own mail servers, and mail is delivered directly to my servers. I'm not running a windows box, and
retrieving mail from an ISP using pop3/imap. I'm running multiple unix boxes running sendmail. My ISP (in this case, a university network), provides IP connectivity, but I'm not using their mail servers for inbound mail.

...Okay, fine, but doing so here is pretty much a waste of time -- both yours and ours (other users). The only way to be sure you're getting your message to the deputies is to e-mail to deputies[at]admin.spamcop.net -- they don't visit here.

Just like the rest of us, the use of a Tracking URL allows "us" to see the e-mail being discussed ... I don't quite understand why you "can't see the e-mail" involved. (The examples in this Discussion have not yet aged off the Reporting system.)

And yet you see seem to have totally discounted my remarks ... things like "has been complained about since inception"

I offered a follow-up in the referenced Dixscussion, also noting that I didn't grok the 'explanation' either. Yes, the parse differences still exist. You can complain all you want, but I believe I have stated often enough that this issue has existed from the beginning ... "we" are other users here for the most part ... so I'd specifically ask that you make your complaints in a way / place where it makes a bit more sense. As stated above, your complaint in this Discussion does not match the details of "this" Discussion. In general, complaining to other users who have already agreed that there is an issue, have raised their own complaints over the passing years, doesn't really seem to be a productive way to spend your time and energy.

And yet again, no one "here" can make the changes needed. Actually, Don/Deputies can't make the changes either, as none of them are programmers involved with the actual codebase. As I stated elsewhere, there is no known ticket, excalation, on-going work to resolve this issue that has been around since Day 1 of the MailHost Configuration of your Reporting Account process.

Yes ...???? Assumedly what you have missed is that the issue you want to complain about is the Parsing codebase differences between a non-MailHost configured and a MailHost configured Reporting Account. Not sure why I am still typing that phrase at this point.

Hi there,

I have read through this thread and am still unclear ...

I have had two reports dropped in the past week or so because the date was "Too old".
[This mail was received on Wed, 16 Jan 2002 13:46:02 +0000 Message is 2389.9 days old]

Now call me a suspicious old thing, but I really do not believe that this was "lying around for 2389.9 days waiting for delivery"! I don't see it having slipped down behind the sorting machine for 6+ years ....

OBVIOUSLY Spammers HAVE found a way to make sure that they are date stamped as "Too old to report".

I think that the point of the query at the top of this thread is valid and that "old" is no longer a reason not to report - it should be on my receipt and not that of some "trusted" date stamp.

Regards
Mike

Or the receiving system's incoming mail server has a clock that is seriously in need of resetting.

Or SpamCop got fooled by a forgery and the user needs to register his email providers with our Mailhost system so that the SpamCop parse can pinpoint the correct server to take the time from.

- Don D'Minion - SpamCop Admin -
.

Moderator Edit: extracted from http://forum.spamcop.net/forums/index.php?showtopic=8330

Hi there,

This one just back from spamcop:

http://www.spamcop.net/sc?id=z2158675724za...84e289c48a7b02z

Again it says that the date is: Wed, 30 Jan 2002 and is Too Old to Report ....

Surely it is blindingly obvious that someone in the spam World has managed to get at the date stamping?

OK, if a spam is a day or so out of date it MAY be a late call, but 6½ YEARS .... !

All I am saying is that SpamCop should treat these totally false dates as it does any other spam and report them. Is there something I am missing in this? There seems to be a lot of very aggressive defensive commenting in replies to this question. Some replies seem to say that we should be checking the various links in the sending line to discover the culprit Server ... ? It is irrelevant. They are spam and should just be treated with the contempt they deserve and reported. No more excuses.

Regards
Mike

As far as the incorrect date/time, it looks like the real problem lies with the server named "uk2mxserver1-7.uk2.net," and not with the originating server. Does that server regularly receive email on your behalf? If so, then you need to contact the admin for that server and have them fix the date/time.

DT

Defensive statements???? I keep pointing out that there is an issue with the MailHost Configured Reporting Account parsing and this issue has been around since its inception. How is that defensive???

A repeat example, your spam parsed via a non-MailHost Configured Reporting Account;
http://www.spamcop.net/sc?id=z2158869852zd...dda7844aa7b757z

Once again noting that where the parser decides to extract the TimeDate-stamp is different.

In this specific example, the sever that DavidT points out definitely has issues. Your parse certainly shows that this server is in fact part of your MailHost Configuration data-set. So to repeat DavidT's suggestion, contact them and get them to straighten things out.

Yes, there is something that you are missing. There are two different ways that the parser handles reporter submissions - one is with Mailhost Configuration and one without. I don't follow the technical details very well, but, for some reason, the parser chooses the date/time to determine whether it is too old or not at a certain point in the header when it is using the Mailhost Configuration going to the end of 'trusted' IPs. If that computer has a problem with its date/time setting, the parser says it is too old (even if it is 6 1/2 years too old - parsers don't think, if it is one more than what is allowed, it is too old - the parser doesn't look any further.)

Now, with the non-Mailhost Configuration, apparently, the parser gets the date/time correctly because it doesn't trust any computer, but if that computer had a date/time problem, then it would also say it was too old.

Computers do, IME, sometimes, for no apparent reason, go whacko on the date/time. I expect mail servers are no different. What you need to do is contact the owner of the computer that has the problem and let them know.

Miss Betsy

To expand the point:And, in demonstration of that, here is the parse without mailhost configuration:
http://www.spamcop.net/sc?id=z2159362199z8...061c6c394d08a0z
Mailhost configuration is necessary to ensure you don't report providers in your own 'supply chain', which is particularly a risk with quick reporting but also with 'standard' reporting. But it assumes, in the date assignments, that you have some ability to get the servers fixed within your supply chain. Well the sever admin shouldn't need prodding, but if (s)he does.

In an ideal world that shouldn't be a problem for you - in any event it is not a parser 'fault', nor is it likely to be anything done by spammers. If they have control of a server in your supply chain they could likely achieve just about anything - in which case your concern would be to find new providers. It is unlikely this is occurring. If they had such perfect opportunity why would they compromise it when they could instead remain 'invisible'? The only reason would be to protect the supposed injection source. And then maybe only from SC (there are other BLs with different rules). Why would they do that when they could forge the injection IP?

[on edit]This has happened to you before. Maybe it is time you looked for another provider, if it is the same one. As another poster said "Once happenstance, twice circumstance, third time enemy action." Well, that's what he should have said. Maybe just incompetence, not anything you should have to put up with anyway.

Mikescki,
Two weeks ago, you posted in a similar topic and the SpamCopAdmin responded to you with:

Looking at the headers in your Tracking URL, it appears that the first server receiving the message on your behalf is poorly managed, and was the source of the incorrect date/time, so Don was correct back then, but I guess you didn't think so....although you never responded to him.

Looks like you need to contact the Support department at UK2.net.

DT

Thanks for the look-up. Split the 'new' traffic from that other Topic, merged it into the Discussion you pointed out. PM sent to advise of the action.

OK,

Thanks for that - I see now that it is a balancing act to only report that originator.
I'll be contacting UK2 with the info and see what they can do about it.

Regards
Mike