Spamcop reporting No source IP address found, cannot proceed.

[jab]

Spamcop is reporting No source IP address found, cannot proceed.

But I can see the source host name and resolve it to an IP, why is this happening?

Received: from alb-dmz1.massey.ac.nz (Not Verified[10.100.252.3]) by tur-mm4.massey.ac.nz with Trustwave SEG
        id <B576897500001>; Tue, 21 Jun 2016 13:24:32 +1200
Received: from apn-77-112-51-51.dynamic.gprs.plus.pl (alb-cfw1-managed.massey.ac.nz [10.100.3.228])
        by alb-dmz1.massey.ac.nz (Postfix) with ESMTP id 8BA0710A8
        for <a.l.welch@massey.ac.nz>; Tue, 21 Jun 2016 13:24:31 +1200 (NZST)
Message-Id: <~B576897500001.5769a21c0000.0002.mml.1487990781@massey.ac.nz>

[Lking]

Jab,  If you could provide the Tracking URL for your submitted spam I would help others see what the parser is doing, and maybe when/why it chokes.

[jab]

The tracking URL is:

https://www.spamcop.net/sc?id=z6250056514ze6acd50c90629cc27647bc52d4386f7cz

[Lking]

Reading the results from the parser tells the story.

Quote

Received:  from alb-dmz1.massey.ac.nz (Not Verified[10.100.252.3]) by tur-mm4.massey.ac.nz with Trustwave SEG id <B576897500001>; Tue, 21 Jun 2016 13:24:32 +1200

host 10.100.252.3 (getting name) no name

10.100.252.3 discarded

 

Received:  from apn-77-112-51-51.dynamic.gprs.plus.pl (alb-cfw1-managed.massey.ac.nz [10.100.3.228]) by alb-dmz1.massey.ac.nz (Postfix) with ESMTP id 8BA0710A8 for <x>; Tue, 21 Jun 2016 13:24:31 +1200 (NZST)

host 10.100.3.228 (getting name) no name

 

10.100.3.228 discarded

No source IP address found, cannot proceed.

 

So the parser obviously gets hung-up on he internal IP addresses 10.x.x.x   If the Received line were properly formatted and not forged, the domain names and IP addresses that you and I can see would be good.  The parser "knows" that the IP is bad and therefore does not trust any of the Received: line.

[DRSpalding]

https://www.spamcop.net/sc?id=z6250422071z6edcfa3163cf7ddc87032aa5cce1a840z

Let me know if the link gives you the information you need or not.  I'll post the relevant headers if necessary.

The Received lines after the X-Yahoo-* stuff are fakes/filler and the dates are being noted by SpamCOP and not allowing the spam to be reported even though the spam is quite fresh.  Perhaps SpamCOP is thinking that these lines are legitimate internal hand-offs.  However, it then continues and goes on to the following Received lines with external IP addresses in them and parsed out the abuse recipient of abuse at Hawaii.edu for 166.122.98.137 from what I am pretty sure are spammer inserted Received lines.

It appears that this persistent set of spammers on Yahoo have been trying to get past SpamCOP reporting for awhile.  First it was repeating large blocks of bogus text in the body to grow the message past 50kb and SpamCOP would chop off the shortened links (generally bit.ly or tinyurl.com) near the end of the message and now, putting in some rather shifty headers that fool SpamCOP.

Can anything be done here?  Can I edit the header to remove the bogus Received lines so that it will report it to Yahoo as it should?

I hope that the spammer doesn't actually know that they have stumbled upon this technique, but for now, I will report by hand to Yahoo and cloudflare.

Addendum: I received a nearly identically formed spam a bit later but it parsed correctly.  The only meaningful difference to my eye was that the X-YMail-OSG block was a couple of lines shorter in the mail that parsed correctly.

 

[lisati]

6 hours ago, DRSpalding said:

https://www.spamcop.net/sc?id=z6250422071z6edcfa3163cf7ddc87032aa5cce1a840z

Let me know if the link gives you the information you need or not.  I'll post the relevant headers if necessary.

The Received lines after the X-Yahoo-* stuff are fakes/filler and the dates are being noted by SpamCOP and not allowing the spam to be reported even though the spam is quite fresh.  Perhaps SpamCOP is thinking that these lines are legitimate internal hand-offs.  However, it then continues and goes on to the following Received lines with external IP addresses in them and parsed out the abuse recipient of abuse at Hawaii.edu for 166.122.98.137 from what I am pretty sure are spammer inserted Received lines.

<snip>

 

I see what you mean about the dates on some of the received lines being problematicel, the thought that an email could be stuck in a queue for nearly 10 years stretches the credibility somewhat.