Jump to content

Back dated spam


mMerlin
 Share

Recommended Posts

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

Link to comment
Share on other sites

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 -

.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

...*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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...