Back dated spam

[mMerlin]

I got 'fresh' spam this morning, but spamcop refuses to process as being 'too old'.

Here is a slightly munged extract from the spamcop parsing, and raw headers. The top received line is the only one I can 'confirm' as being good. That is where my mail host received the message. On typical 'good' mail, that would be the only received header. Is that 5 day jump in the message chain timestamps 'real', or something spammy forged, but spamcop accepted as valid?

0: Received: from mail-ie0-f190.google.com [209.85.223.190] by xxx with SMTP; Fri, 30 Nov 2012 05:55:05 -0800

Hostname verified: mail-ie0-f190.google.com

TechComm.ca received mail from Gmail/Postini ( 209.85.223.190 )

1: Received: from mailout-us.mail.com (mailout-us.mail.com. [74.208.122.35]) by gmr-mx.google.com with SMTP id d5si1194249iga.1.2012.11.25.09.16.17; Sun, 25 Nov 2012 09:16:17 -0800 (PST)

Hostname verified: mailout-us.mail.com

Gmail/Postini received mail from sending system 74.208.122.35

2: Received: from static.215.239.9.176.clients.your-server.de (EHLO 43.187.4.190) [176.9.239.215] by mail.gmx.com (mp-us011) with SMTP; 25 Nov 2012 11:57:49 -0500

Hostname verified: static.215.239.9.176.clients.your-server.de

Possible forgery. Supposed receiving system not associated with any of your mailhosts

Will not trust anything beyond this header

Received: from mail-ie0-f190.google.com [209.85.223.190] by xxx with SMTP;

  Fri, 30 Nov 2012 05:55:05 -0800

Received: by mail-ie0-f190.google.com with SMTP id k10sf375837iea.17

  for <xxx>; Fri, 30 Nov 2012 05:55:06 -0800 (PST)

Received: by 10.50.37.242 with SMTP id b18mr11172269igk.6.1354283706705;

  Fri, 30 Nov 2012 05:55:06 -0800 (PST)

Received: by 10.50.6.199 with SMTP id d7ls441289iga.14.gmail; Fri, 30 Nov 2012

  05:54:20 -0800 (PST)

Received: by 10.42.247.69 with SMTP id mb5mr1128827icb.4.1354283660904;

  Fri, 30 Nov 2012 05:54:20 -0800 (PST)

Received: by 10.50.0.146 with SMTP id 18msige;

  Sun, 25 Nov 2012 09:16:17 -0800 (PST)

Received: by 10.50.159.193 with SMTP id xe1mr9693087igb.0.1353863777680;

  Sun, 25 Nov 2012 09:16:17 -0800 (PST)

Received: by 10.50.159.193 with SMTP id xe1mr9693086igb.0.1353863777665;

  Sun, 25 Nov 2012 09:16:17 -0800 (PST)

Received: from mailout-us.mail.com (mailout-us.mail.com. [74.208.122.35])

  by gmr-mx.google.com with SMTP id d5si1194249iga.1.2012.11.25.09.16.17;

  Sun, 25 Nov 2012 09:16:17 -0800 (PST)

Received: (qmail invoked by alias); 25 Nov 2012 16:57:49 -0000

Received: from static.215.239.9.176.clients.your-server.de (EHLO 43.187.4.190) [176.9.239.215]

  by mail.gmx.com (mp-us011) with SMTP; 25 Nov 2012 11:57:49 -0500

[turetzsr]

Hi, mMerlin!

...Have you configured your SpamCop reporting account with the "Mailhosts" feature?

[SpamCopAdmin]

It looks like gmr-mx.google.com hoarded the email for a while before releasing it.

- Don D'Minion - SpamCop Admin -

- Service[at]Admin.SpamCop.net -

>- ...Have you configured your SpamCop reporting account with the "Mailhosts" feature?

Yes, he has. You can tell from the 0: 1: 2: parts of the parse info. That's unique to a Mailhost parse.

Plus, Mailhosts doesn't have anything to do with date parsing.

- Don D'Minion - SpamCop Admin -

- Service[at]Admin.SpamCop.net -

.

[turetzsr]

It looks like gmr-mx.google.com hoarded the email for a while before releasing it.

...*Slaps forehead with palm* Now that I actually read the first few lines of the parse carefully, I don't know how I missed that! <blush>

<snip>

>- ...Have you configured your SpamCop reporting account with the "Mailhosts" feature?

Yes, he has. You can tell from the 0: 1: 2: parts of the parse info. That's unique to a Mailhost parse.

...Ah, okay, thanks!

Plus, Mailhosts doesn't have anything to do with date parsing.

...I asked that to try to better understand parse line "1" because I didn't understand how mailout-us.mail.com. [74.208.122.35] wound up above the "Will not trust anything beyond this header line" due to the fact that I missed the "from" part!

...So, mMerlin, line 1, not line 0, shows where the e-mail entered your e-mail provider's (Google's) network and that happened on Nov 25. Why server gmr-mx.google.com held it for five days before sending it on (line 0) for you to see is a question only Google can answer (AFAIK).

...Good luck!

[mMerlin]

...*Slaps forehead with palm* Now that I actually read the first few lines of the parse carefully, I don't know how I missed that! <blush>...Ah, okay, thanks!...I asked that to try to better understand parse line "1" because I didn't understand how mailout-us.mail.com. [74.208.122.35] wound up above the "Will not trust anything beyond this header line" due to the fact that I missed the "from" part!

...So, mMerlin, line 1, not line 0, shows where the e-mail entered your e-mail provider's (Google's) network and that happened on Nov 25. Why server gmr-mx.google.com held it for five days before sending it on (line 0) for you to see is a question only Google can answer (AFAIK).

...Good luck!

In this context at least, google is not *my* e-mail provider. The munged first line is what mailhosts knows about. But spamcop 'trusted' the google related headers anyway, so continued on down. Otherwise it would have been reporting mail-ie0-f190.google.com [209.85.223.190] as the spam source. If those headers really are valid, the question becomes what caused the (google internal?) 10.50.0.146 server to hold the mail for 5 days, and as mentioned, that's a question for google. I got several spam mails today that had all been held for varying times like that, that all traced back to 1and1.com

Only the last 2 were new enough to actually report. First guess from other header info, is spammy used a google group to send the spam. Still do not know why it got held for up to 5 days though.

[lisati]

In this context at least, google is not *my* e-mail provider. The munged first line is what mailhosts knows about. But spamcop 'trusted' the google related headers anyway, so continued on down. Otherwise it would have been reporting mail-ie0-f190.google.com [209.85.223.190] as the spam source. If those headers really are valid, the question becomes what caused the (google internal?) 10.50.0.146 server to hold the mail for 5 days, and as mentioned, that's a question for google. I got several spam mails today that had all been held for varying times like that, that all traced back to 1and1.com

Only the last 2 were new enough to actually report. First guess from other header info, is spammy used a google group to send the spam. Still do not know why it got held for up to 5 days though.

My best guess at the moment is that there was a lot of email for Google to process, which took them a long time to get through. Even then, five days does seem a long time.