Seemingly incorrect too old to file message

[mMerlin]

I got a bunch of 'fresh' spam this morning that show back dated in my email client, and Spamcop is saying is too old to file. Examining the headers, I see a common pattern:

... standard stuff ...

Received: by mail-vc0-f187.google.com with SMTP id hz10sf1509630vcb.24

for <x>; Tue, 17 Sep 2013 00:56:59 -0700 (PDT)

Received: by 10.50.12.67 with SMTP id w3ls2409537igb.25.canary; Tue, 17 Sep

2013 00:55:40 -0700 (PDT)

Received: by 10.50.73.1 with SMTP id h1msigv;

Wed, 11 Sep 2013 09:42:33 -0700 (PDT)

Received: from oms-md02.mx.aol.com (oms-md02.mx.aol.com. [64.12.81.146])

The final time stamp for today is identical on all of the spam (to the second), but the old date varies. I might be tempted to say that some internal google server was broken, and held on to the mail for awhile until something was reset this morning, but the 10.50.x.x address pair around the time warp also vary. Here are some tracking URLs

http://www.spamcop.net/sc?id=z5565604476z1...bc28c374a0cbd5z

http://www.spamcop.net/sc?id=z5565660357z4...704d377d5949ebz

http://www.spamcop.net/sc?id=z5565665336z5...b67ff266547161z

http://www.spamcop.net/sc?id=z5565667792z9...43030bcfe86a6ez

http://www.spamcop.net/sc?id=z5565668896z0...739afe1808a512z

http://www.spamcop.net/sc?id=z5565670132ze...1b99c304da17e4z

http://www.spamcop.net/sc?id=z5565671091z5...a6d0fc561f61c6z

Is this a parsing problem, trusting headers that have been faked, or was that batch of mail really delayed internally at google?

[turetzsr]

Hi, mMerlin,

...Looking at your first Tracking URL (thanks for providing those!), I see, in part:

<snip> 
Received: by mail-vc0-f187.google.com with SMTP id hz10sf1509630vcb.24
        for <x>; Tue, 17 Sep 2013 00:56:59 -0700 (PDT)
Received: by 10.50.12.67 with SMTP id w3ls2409537igb.25.canary; Tue, 17 Sep
 2013 00:55:40 -0700 (PDT)
Received: by 10.50.73.1 with SMTP id h1msigv;
        Wed, 11 Sep 2013 09:42:33 -0700 (PDT)
Received: from oms-md02.mx.aol.com (oms-md02.mx.aol.com. [64.12.81.146])
        by gmr-mx.google.com with ESMTPS id q1si4065847qce.0.1969.12.31.16.00.00
        (version=TLSv1 cipher=RC4-SHA bits=128/128);
        Wed, 11 Sep 2013 09:42:33 -0700 (PDT)
<snip>

...If I understand correctly, SpamCop is saying that your e-mail provider's internal server 10.50.12.67 received the incoming e-mail from internal server 10.50.73.1 on Sep 17 but that the latter received it on Sep 11. Seems like something you will, in fact, have to raise with your e-mail provider. Normally, e-mail providers find and fix these sorts of issues fairly quickly so there's a good chance that by the time you contact them it will already be fixed.

[mMerlin]

Hi, mMerlin,

...Looking at your first Tracking URL (thanks for providing those!), I see, in part:

<snip> 
Received: by mail-vc0-f187.google.com with SMTP id hz10sf1509630vcb.24
        for <x>; Tue, 17 Sep 2013 00:56:59 -0700 (PDT)
Received: by 10.50.12.67 with SMTP id w3ls2409537igb.25.canary; Tue, 17 Sep
 2013 00:55:40 -0700 (PDT)
Received: by 10.50.73.1 with SMTP id h1msigv;
        Wed, 11 Sep 2013 09:42:33 -0700 (PDT)
Received: from oms-md02.mx.aol.com (oms-md02.mx.aol.com. [64.12.81.146])
        by gmr-mx.google.com with ESMTPS id q1si4065847qce.0.1969.12.31.16.00.00
        (version=TLSv1 cipher=RC4-SHA bits=128/128);
        Wed, 11 Sep 2013 09:42:33 -0700 (PDT)
<snip>

...If I understand correctly, SpamCop is saying that your e-mail provider's internal server 10.50.12.67 received the incoming e-mail from internal server 10.50.73.1 on Sep 17 but that the latter received it on Sep 11. Seems like something you will, in fact, have to raise with your e-mail provider. Normally, e-mail providers find and fix these sorts of issues fairly quickly so there's a good chance that by the time you contact them it will already be fixed.

That section has nothing to do with *my* email provider. The headers for that is in the part that got snipped. This section is before it got to my ISP servers. The problem section *looks* like internal handoff, or something, between aol and google.

Probably nothing to do with the mail delivery problem, but that whole batch of spam is claiming that I received it because (it says) I am subscribed to a google groups group that I have never heard of. If google is allowing email addresses to be signed up to groups without the owners authorization, there is a big problem someplace.

[turetzsr]

That section has nothing to do with *my* email provider.

...In that case, you may need SpamCop help. The most direct way to get that is to send a note directly to the SpamCop Deputies at e-mail address deputies[at]admin.spamcop.net. You may wish to include a sample or two of the spams themselves (as attachments) and the Tracking URLs associated with those spams.

<snip>

that whole batch of spam is claiming that I received it because (it says) I am subscribed to a google groups group that I have never heard of.

<snip>

...Please see Spammer Rules rules #1 and #2 and Crissman's Corollary. <g>

[petzl]

I got a bunch of 'fresh' spam this morning that show back dated in my email client, and Spamcop is saying is too old to file. Examining the headers, I see a common pattern:

The final time stamp for today is identical on all of the spam (to the second), but the old date varies. I might be tempted to say that some internal google server was broken, and held on to the mail for awhile until something was reset this morning, but the 10.50.x.x address pair around the time warp also vary. Here are some tracking URLs

http://www.spamcop.net/sc?id=z5565604476z1...bc28c374a0cbd5zIs this a parsing problem, trusting headers that have been faked, or was that batch of mail really delayed internally at google?

Botnet stuff can often be delayed

198.143.159.154

http://cbl.abuseat.org/lookup.cgi?ip=198.143.159.154

It's not a email server so delivery of spam may be intermittent if infected computer is switched off and sends when switched on

This is where gre listing is good

Botnets hammer your email when you don't have it

My Greylist stopped working when switched on the amount of rejections was 18 pages

Screen capture

https://dl.dropboxusercontent.com/u/50667687/GREYLIST.png

Now its back to "normal" with only a few rejections about 5 now

https://dl.dropboxusercontent.com/u/50667687/GREYLISTnow.png

198.143.159.154 need to block outbound port 22 this means sending email can only be done via ISP's email server.

[mMerlin]

Botnet stuff can often be delayed

198.143.159.154

http://cbl.abuseat.org/lookup.cgi?ip=198.143.159.154

It's not a email server so delivery of spam may be intermittent if infected computer is switched off and sends when switched on

This is where gre listing is good

Botnets hammer your email when you don't have it

My Greylist stopped working when switched on the amount of rejections was 18 pages

Screen capture

https://dl.dropboxusercontent.com/u/50667687/GREYLIST.png

Now its back to "normal" with only a few rejections about 5 now

https://dl.dropboxusercontent.com/u/50667687/GREYLISTnow.png

198.143.159.154 need to block outbound port 22 this means sending email can only be done via ISP's email server.

Thanks. That nicely accounts for both the source of the spam, and a possible reason for the time delay, although the delay looks like it was on server later in the chain. To bad spamcop is not equipped to detect and send appropriate reports about that too.

[SpamCopAdmin]

SpamCop takes the date from the "Received" line containing the source IP.

In this case:

http://www.spamcop.net/sc?id=z5565604476z1...bc28c374a0cbd5z

Received: from 90.132.11.8 (unknown [198.143.159.154]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma06.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 054F5E0006DE for <x>; Wed, 11 Sep 2013 12:42:30 -0400 (EDT)

- Don D'Minion - SpamCop Admin -

- Service[at]Admin.SpamCop.net -

.

[Lking]

To bad spamcop is not equipped to detect and send appropriate reports about that too.

As has been said many times, trying to do everything makes you a master of none. It seems that just identifying the source of spam is a big enough part for the puzzle. Getting it right, give all the tricks used to hide the spammers source, is even harder.