[Resolved] SpamCop using wrong date to check for > 48 hours

[Morac]

I received a spam message at Tue, 16 Oct 2007 18:05:23 -0700 according to the headers. I reported it to SpamCop and SpamCop said it was too old to report since it was received on Sat, 06 Oct 2007 01:56:42 PDT. Well this is wrong.

The problem is that SpamCop is checking the date in an additional From header field at the top of the message instead of checking the next line which is the Received: header field. I've noticed this a bunch of times the past day or two so it must be something new.

See http://www.spamcop.net/sc?id=z1481446365z8...e267d2548e8e89z

[turetzsr]

<snip>

The problem is that SpamCop is checking the date in an additional From header field at the top of the message instead of checking the next line which is the Received: header field. I've noticed this a bunch of times the past day or two so it must be something new.

<snip>

...While the "From" header field at the top does have the date received that SpamCop is using, I do not believe that is what SpamCop actually is using. I believe it is using this line:

<snip>

Received: from [218.254.190.69] by web57514.mail.re1.yahoo.com via HTTP; Sat, 06 Oct 2007 01:56:42 PDT

<snip>

All the "Received" headers down to that line appear to me to be internal handoffs within Yahoo (your e-mail provider?) whereas 218.254.190.69 appears to be the source of the spam.

[Wazoo]

I received a spam message at Tue, 16 Oct 2007 18:05:23 -0700 according to the headers. I reported it to SpamCop and SpamCop said it was too old to report since it was received on Sat, 06 Oct 2007 01:56:42 PDT. Well this is wrong.

Agreed. However, this is an age-old complaint / situation. I have asked, pointed to, explained, referenced, etc. this issue since the MailHost Configuration of your Reporting Account was brought into being .... numerous references within this Forum, a number of newsgroups posts, countless e-mails to "staff"

A 'normal' parse uses the Date/Time from the topmost 'valid' Received: line.

A 'MailHost Configured' parse uses the Date/Time from the bottommost 'valid' Received: line.

No one will say why.

No one will say "I've opened a ticket"

No one will say "It's being worked on"

[Lking]

No one will say why.

No one will say "I've opened a ticket"

No one will say "It's being worked on"

Then I would venture to say "That is the way it is, the end."

Considering that parsing to find the correct sender and secondarily, identifying spamvertizers is more important maybe effort should be sent there.

Also sense the 48 hour cutoff is just a capricious time. Dues it really matter which time stamp is used to apply the 48 hour cutoff?

An answer to "why?" would be nice.

JMHO

[DavidT]

Well...this is symptomatic of bigger problems, I think. For example, something that always seems a bit of a "red flag" to me is an out-of-date copyright footer on a website...at the bottom of the SpamCop pages, one currently sees the following:

Copyright © 1998-2006, IronPort Systems, Inc.

Yes, I know that IronPort was acquired by Cisco earlier this year, but somebody could surely do something as mundane as incrementing the copyright date on the site.

DT

[Farelf]

...A 'normal' parse uses the Date/Time from the topmost 'valid' Received: line.

A 'MailHost Configured' parse uses the Date/Time from the bottommost 'valid' Received: line. ...

As confirmed by comparing an un-mailhosted parse with the one given above:

http://www.spamcop.net/sc?id=z1482106247z7...40ca135347325bz

Even the sagest of newsgroup commentators have groused about this too (repeatedly), with no hint of resolution. Here's another sage grouse http://www.western.edu/bio/young/gunnsg/Goodsg.jpg

[techie]

Here's an example that was just bounced by the >48 hour rule.

http://www.spamcop.net/sc?id=z1559793977z3...a052cd2406212cz

From george_wst_food[at]yahoo.com Mon Dec 10 21:31:00 2007

Received: from ($my_secondary_MX)

by ($my_primary_mailhost) (8.13.8/8.13.8) with ESMTP id lBB5UiiI040131

for <$my_email_address>; Mon, 10 Dec 2007 21:31:00 -0800 (PST)

(envelope-from george_wst_food[at]yahoo.com)

Received: from flpi102.prodigy.net (flpi102.sbcis.sbc.com [207.115.20.71])

by ($my_secondary_MX) (8.13.8/8.13.8) with ESMTP id lBB5Ud0a009728

for <$one_of_my_aliases>; Mon, 10 Dec 2007 21:30:44 -0800 (PST) <<---actual time spam arrived

(envelope-from george_wst_food[at]yahoo.com)

X-ORBL: [70.235.83.62]

Received: from User (adsl-70-235-83-62.dsl.mrdnct.sbcglobal.net [70.235.83.62])

by flpi102.prodigy.net (8.13.8 out.dk.spool/8.13.8) with SMTP id lB9Kg7h6005110;

Sun, 9 Dec 2007 12:42:15 -0800 <<<<<<<-------Spamcop used this (bogus) timestamp.

Message-ID: <200712092042.lB9Kg7h6005110[at]flpi102.prodigy.net>

Reply-To: <george_wst_foods[at]yahoo.com>

From: "George Weston Foods"<george_wst_food[at]yahoo.com>

Subject: Job Offer

Date: Sun, 9 Dec 2007 15:44:15 -0500

This can't be that hard to fix.. Spamcop knows what hosts are listed as MailHosts, so parse for the first timestamp in the MX path. Any timestamp earlier in the path is under the control of the spam relay, and should not be believed, otherwise spammers could simply backdate the timestamp to avoid spamcop reporting.

[Wazoo]

This can't be that hard to fix..

??? 99.9999%+ of the folks here have no 'say' about what the paid staff do. The MailHost Configuration of your Reporting Account was originally derived by Julian. Credits now show that IronPort staff are maintaining the codebase, though noting that this is in the 'original/official' FAQ that has been complained about for years for being incomplete, out-of-date, etc. etc. etc. Of course, one could also add in priorities.

You are more than welcome to contact paid staff directly yourself and ask (yet again) about this issue and see if you can get an answer. It's not like it hasn't been asked before over the previous years.

[techie]

Yet another example:

From service[at]bankofcastile.com Wed Apr 23 02:11:34 2008

Return-path: <service[at]bankofcastile.com>

Received: from ($MY-SECONDARY_MX) by ($MY_PRIMARY_MX) (8.13.8/8.13.8) with ESMTP id m3N9BITC012720 for <(ADDRESS[at]$MY_PRIMARY_MX)>; Wed, 23 Apr 2008 02:11:33 -0700 (PDT) (envelope-from service[at]bankofcastile.com)

Received: from k2smtpout06-01.prod.mesa1.secureserver.net (k2smtpout06-01.prod.mesa1.secureserver.net [64.202.189.102]) by ($MY_SECONDARY_MX) (8.13.8/8.13.8) with SMTP id m3N9AfA0080528 for <ADDRESS[at]($MY_SECONDARY_MX)>; Wed, 23 Apr 2008 02:10:47 -0700 (PDT) (envelope-from service[at]bankofcastile.com)

Message-ID: <200804230910.m3N9AfA0080528[at]($MY_SECONDARY_MX)>

Received: (qmail 11191 invoked from network); 23 Apr 2008 09:10:41 -0000

Received: from unknown (HELO manejate.com) (68.178.164.30) by k2smtpout06-01.prod.mesa1.secureserver.net (64.202.189.102) with ESMTP; 23 Apr 2008 09:10:41 -0000

Received: (qmail 13534 invoked from network); 16 Apr 2008 21:09:21 -0000

Received: from webmail.waterwise.co.uk (HELO User) (80.177.179.9) by b.com.uy with SMTP; 16 Apr 2008 21:09:21 -0000

Reply-To: <service[at]bankofcastile.com>

From: "The Bank of Castile"<service[at]bankofcastile.com>

Subject: Security requirements

Date: Wed, 16 Apr 2008 22:06:37 +0100

MIME-Version: 1.0

Content-Type: text/html; charset="Windows-1251"

Content-Transfer-Encoding: 7bit

X-Priority: 1

X-MSMail-Priority: High

X-Mailer: Microsoft Outlook Express 6.00.2600.0000

X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000

To: undisclosed-recipients:;

Note the lines in red, which were obviously added by the spammer, as they have no association with the lines above them. However, it appears that SpamCop is using that line to determine the date.

I just tried editing out the lines in red, and the resubmitted spam was parsed properly.

[turetzsr]

Yet another example:

<snip>

...And the answer is still the same: 61572[/snapback]. Have you tried contacting SpamCop paid staff directly, as previously suggested? What was the response?

[techie]

...And the answer is still the same: 61572[/snapback]. Have you tried contacting SpamCop paid staff directly, as previously suggested? What was the response?

Yes.

> The crux of the question is why the system jumped over the lines

> immediately preceding your network, when normally it reports the

> connecting IP. The reason for this happening is that the Godaddy

> servers are trusted in our database, so they are essentially treated the

> same as your own record of mailhosts.

>

> Which brings us to the question of whether the last received line is

> forged. Looking at this and looking at several other example of Godaddy

> handling mail, the line is consistent (as screwed up looking as it is)

> with how the Godaddy server stamps its injection received line.

>

> With that information I have to conclude the received line is correct

> and the mail truly was sent on April 16. The Godaddy server then sat on

> the mail for a week before passing it onto your server.

This appears to actually be correct, the first server used multiple names during this handoff..

Received: from unknown (HELO manejate.com) (68.178.164.30) by k2smtpout06-01.prod.mesa1.secureserver.net (64.202.189.102) with ESMTP; 23 Apr 2008 09:10:41 -0000

Received: (qmail 13534 invoked from network); 16 Apr 2008 21:09:21 -0000

Received: from webmail.waterwise.co.uk (HELO User) (80.177.179.9) by b.com.uy with SMTP; 16 Apr 2008 21:09:21 -0000

[1:27pm-109]> host b.com.uy

b.com.uy has address 68.178.164.30

b.com.uy mail is handled (pri=10) by mail.b.com.uy

[1:27pm-110]> host mail.b.com.uy

mail.b.com.uy has address 68.178.164.30

>

> The system takes the timestamp from the first server we trust to handle

> the mail. That being the Godaddy server, the system accepts the mail

> was sent on April 16 and is now too old to report.

>

> Right or wrong, that's how the system handles stuff and not something we

> can change without breaking some other things.

Of course, I'm not a Godaddy customer, and I don't trust Godaddy as far as I can throw their datacenter.

I get a lot of spam from Godaddy, and I can't add them to my local blocklist because I also have subscribers to a couple of my mailing lists who are Godaddy customers.

This argument says that Godaddy (or a Godaddy customer) can delay spam for 48+ hours, and avoid having the spam reported to them, or counted against them, just because Godaddy is "trusted".

My argument is that if "trusted" ISP's can do this, how are they ever going to know if spam is flowing through their network, or if one of their customers is spamming, and delaying the spam to avoid reporting.

The date parsing for purposes of determining the age of the spam should begin at the point where it enters my MX path, not the "trusted" spam relay upstream of me. Spamcop can still trust the path within Godaddy, but the date parsing should begin at the handoff to my first MX.

[turetzsr]

Yes.

<snip>

> Right or wrong, that's how the system handles stuff and not something we

> can change without breaking some other things.

<snip>

This argument says that Godaddy (or a Godaddy customer) can delay spam for 48+ hours, and avoid having the spam reported to them, or counted against them, just because Godaddy is "trusted".

My argument is that if "trusted" ISP's can do this, how are they ever going to know if spam is flowing through their network, or if one of their customers is spamming, and delaying the spam to avoid reporting.

The date parsing for purposes of determining the age of the spam should begin at the point where it enters my MX path, not the "trusted" spam relay upstream of me. Spamcop can still trust the path within Godaddy, but the date parsing should begin at the handoff to my first MX.

...Thanks for posting the reply!

...You may be right but we users have to treat paid SpamCop staff replies like this as authoritative. There's not much anyone here can do, other than commiserate with you. Sorry. As such, I am marking this thread as "Resolved."

[Miss Betsy]

If you really feel strongly about it, then you can send a manual report to Godaddy. Even a complaint about their date stamp.

Miss Betsy

[Wazoo]

Yes.

>

> The system takes the timestamp from the first server we trust to handle

> the mail. That being the Godaddy server, the system accepts the mail

> was sent on April 16 and is now too old to report.

>

> Right or wrong, that's how the system handles stuff and not something we

> can change without breaking some other things.

First of all, congrats on getting an answer to something asked/talked/complained about for years.

Having to agree with Steven's words about the answers received from on-high, I still don't grok what was offered. There is nothing stated that I see that actually explains the difference between a MailHost Configured parse and a non-MailHost Configured parse. One is apparently supposed to key on the phrase "the first server we trust" ..... yet, the parse results differ still ...????

The best I can make out of the words offered, it boils down to the definition of the word "first" ...

Non-MailHost Configured parse seems to point to the last host to touch the e-mail, i.e. the first host seen by the parser.

MailHost Configured parse seems to point to the earliest (the first?) 'trusted' host to touch the e-mail.

And that's actually the difference that's been complained about since the MailHost Configuration of your Reporting Account came into being. In my mind, there is yet more to the story about the code involved, but .... those thinga don't make it out into the light.