Borged dates in the header making spam unreportable.

[sigma]

My current spammer is borging the header such that although the spam was sent and arrived yesterday 2nd Dec,2021, they have borged the header to include an August date as well which Spamcop manages to parse and then refuses to submit reports.  Ohers reporting the same IP addy in www.abuseipdb.com suggest they are experiencing the same problem and that the spam is designed to bypass Spamcop.

Any suggestion as to how to deal with this?

 

Edited December 3, 2021 by sigma
typo

[gnarlymarley]

33 minutes ago, sigma said:

although the spam was sent and arrived yesterday 2nd Dec,2021, they have borged the header to include an August date as well which Spamcop manages to parse and then refuses to submit reports.

SpamCop uses the date in the Received header, which is placed by my email server.  I enabled mailhosts so SpamCop would use the correct date.  Spammers have been adding other headers with bogus dates for a while.

[sigma]

Thanks.  Unfortunately, this on my personal email account at home provided by my ISP, rather than the mail server I look after at work.   There is a correctly dated recieved by header put in by my ISP's server, but Spamcop seems to carry on processing past that, past more genuine headers until it gets to:

Several of these:

Received: from MW3PR22MB2107.namprd22.prod.outlook.com (2603:10b6:303:46::24)
 by BN6PR22MB0082.namprd22.prod.outlook.com with HTTPS; Tue, 10 Aug 2021
 00:30:21 +0000

before this:

From: x x<microsoft-noreply@microsoft.com>
Date: Tue, 10 Aug 2021 00:30:17 +0000
Subject: The most effective way to make money using bitcoin.

The analyisi does seem to correctly identify the source - I agree with what it identifies, but the reporting fails because of the borged dates seeming to dominate.

 

[gnarlymarley]

33 minutes ago, sigma said:

There is a correctly dated recieved by header put in by my ISP's server, but Spamcop seems to carry on processing past that, past more genuine headers until it gets to:

Enabling mailhosts on your SpamCop account should prevent SpamCop from looking past your ISP's server with the correct date, as long as you do not have a outlook.com also on your mailhosts.  It is possible that an admin found a hung queue and released it.

[sigma]

Thanks again, I'll do that. 

It's bitcoin spam, deliberately designed to make reporting "difficult".  

[sigma]

I've enabled mailhosts and done the email exchange to correctly enable it.   I always submit via email as it picks up the urls so much better.

It's still picking up the bad date/ forged header I'm not on Outlook, my ISP uses synchronoss.net.  The email arrived today Mon, 6 Dec 2021 16:13:46 +0000 (UK)

host 2603:10a6:20b:461:cafe:0:0:1a (getting name) no name
host 2603:10a6:20b:461:0:0:0:19 (getting name) no name
host 2603:10b6:5:1b3:cafe:0:0:4d (getting name) no name
host 2603:10b6:5:1b3:0:0:0:46 (getting name) no name

0: Received: from NAM02-DM3-obe.outbound.protection.outlook.com (mail-dm3nam07on2050.outbound.protection.outlook.com [40.107.95.50]) by mail241c28.carrierzone.com (8.14.9/8.13.1) with ESMTP id 1A5HB74k005364 for <x>; Fri, 5 Nov 2021 13:11:10 -0400

Hostname verified: mail-dm3nam07on2050.outbound.protection.outlook.com

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

Will not trust this Received line.

Mailhost configuration problem, identified internal IP as source

Mailhost:
Please correct this situation - register every email address where you receive spam

No source IP address found, cannot proceed.

Add/edit your mailhost configuration
Finding full email headers

Submitting spam via email (may work better)

Example: What spam headers should look like

Nothing to do.

[sigma]

Happy that it does submit via the web interface, even though the urls in the content get ignored that way.  That's still a whole step forward.

[gnarlymarley]

One quick note when your mailhost was changed, you can go back to all your old tracking URLs that previously didn't report and report any that are less than two days old.

[sigma]

Thanks.  I get one or two every day.  Always better to report than ignore I think.

[sigma]

Nulled post. 

Edited December 7, 2021 by sigma
Fixed problem by submittimg properly.

[sigma]

I'm still having problems with these.  Here's one I reported earlier.  https://www.spamcop.net/sc?id=z6734521748z31344c1b98ac107ec335fc366cc181e2z

Is it possible to unpick where it's really comming from?

[gnarlymarley]

On 12/20/2021 at 4:50 PM, sigma said:

I'm still having problems with these.  Here's one I reported earlier.  https://www.spamcop.net/sc?id=z6734521748z31344c1b98ac107ec335fc366cc181e2z

Is it possible to unpick where it's really comming from?

If the Received: lines can be trusted, then you can look at the "from" of the Received: line and trace it back.  I think the issue of unpicking it is technically difficult as you can only trust the Received: lines that are placed by your ISP or your mail server.  You would only be able to trace it back to the specific server that sent it to your mail server.

Edited January 3, 2022 by gnarlymarley
grammar

[sigma]

Thanks again.