Spamcop cannot find source IP

[petzl]

15 minutes ago, SpamStoolie said:

If this header is removed, the message parses properly.

Some spammer is using spamware to fake headers (sometimes removing 2nd header works, not always).

Anyhow it is giving Gmail a hernia, sometimes sending spam to ones sent folder.
https://www.spamhaus.org/whitepapers/spamware/

Spamware is normally developed "by criminals for criminals" specifically for illegal use, often containing features such as the ability to falsify email headers to hide the true source of the spam, to insert fraudulent headers, to use dozens or hundreds of mail servers simultaneously, and to make use of proxies (trojan-infected computers). Features which no normal bulk email program would ever need and no legitimate buk email sender could ever use legally.

[SpamStoolie]

Yes, you keep repeating that that is the problem. I don’t believe that it is.

This appears to me to be a legitimate Gmail header, which is simply not being parsed properly by the SpamCop parser.

[BoZz]

Yes it does or sort of. I did the same thing and removed the second line and indeed the message parsed however I noticed that now Spamcop could not read the spamvertized web links within the emails and reported "

Finding links in message body

Parsing text part

error: couldn't parse head

Message body parser requires full, accurate copy of message"

Please advice.

Thank you

 

 

 

 

[SpamStoolie]

The sample you posted did not appear to include the body. I assume the copy you attempted to parse did…

[petzl]

2 hours ago, BoZz said:

Yes it does or sort of. I did the same thing and removed the second line and indeed the message parsed however I noticed that now Spamcop could not read the spamvertized web links within the emails and reported "

Finding links in message body

Parsing text part

error: couldn't parse head

Message body parser requires full, accurate copy of message"

Please advice.

Thank you

 

 

 

 

Works when you start copying headers at (this removes fake headers)

ARC-Authentication-Results: i=1; mx.google.com;

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

[BoZz]

12 hours ago, SpamStoolie said:

The sample you posted did not appear to include the body. I assume the copy you attempted to parse did…

Yes it did

[BoZz]

12 hours ago, petzl said:

Works when you start copying headers at (this removes fake headers)

ARC-Authentication-Results: i=1; mx.google.com;

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

Yes it does, work likes a charm. Thank you for this. Appreciate

[petzl]

10 hours ago, BoZz said:

Yes it does, work likes a charm. Thank you for this. Appreciate

I were getting this a lot of the time, the (Gmail) headers are spoofed.
I did become VERY active in reporting with spoofed headers. Now (so far) I get none. One can be better than SpamCop which is a great tool for combating spam.

I have nothing to do with running SpamCop just a user of it

[Axellence]

Hi all,

I'm new on the forums but I've been using SpamCop to report spam for years. So far only manually.

I noticed this issue recently and decided to investigate. My conclusion is that this is an issue of SpamCop parser and might be related to how it handles IPv6 addresses.

The allegedly "spoofed" internal source IP addresses (e.g. 2002:a4f:d0c:0:0:0:0:0) appear in headers of all legitimate mail sent to Gmail accounts. While it's somewhat true that 2002:0000::/16 is "internal" as the space is allocated for 6to4 connection ( RFC3056 ) as one of IPv6 global unicast addresses and IANA IPv6 Special-Purpose Address Registry.

I can see many addresses from 2002:0000::/16 space in my mailhosts configuration for Gmail/Postini entry but 2002:a4f:d0c:0:0:0:0:0 is not in the list. I decided to do test by replacing a rejected IPv6 address by one of the addresses from the supposedly valid relaying IPv6 list but it was still rejected with same error: "Mailhost configuration problem, identified internal IP as source".

For example of legitimate non-SPAM, here are headers from my forum account confirmation mail (attempted and rejected report id: z6461656360ze0de39c07007d4266f319e51c6c48c57z )

Delivered-To: <x>
Received: by 2002:a4f:d0c:0:0:0:0:0 with SMTP id 12-v6csp521891ivn;
        Fri, 27 Apr 2018 01:59:45 -0700 (PDT)
X-Google-Smtp-Source: AB8JxZp8WM/6SO2Mvqz1evriecBCFsoKSSszBe4U0l5u+ugfNfkM9FYmaSfFK1pZKAfVCltF2iKz
X-Received: by 10.55.204.134 with SMTP id n6mr1075284qkl.429.1524819585481;
        Fri, 27 Apr 2018 01:59:45 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1524819585; cv=none;
        d=google.com; s=arc-20160816;
        b=S6de573RWOjuGu+63Zv7sAeioqwM2zPtoahrSZOX67HU4H74SWTskNK6mQJ/VBP2k4
         Z1uVoLrpnprkmVcHKOOGafPdF0c2XRVJBfmeZ57Ox5vkQsZ1EVZlH8/13ozLpTgLV5zr
         s7KjftL6iRtEyQZUj1cgCcC6dDwTIr907U0dKcDaBLGcFRD8jW4mTT1OOd+I2MBBHVoa
         SNQ/Hrx0eLNTN6Lqc5vZarJ4u+4wRelYbBl2ByjeuTyn2Icr2h7P9GHnwDqw14spj8Kk
         axmTa4KPtjUfT/NbNg9EdsLXdHdhaFXuRiN4jGWjklOg7PWnsa5K4Co9O5oAKjQvX4Bb
         DKgA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=content-transfer-encoding:auto-submitted:date:subject:from:to
         :mime-version:message-id:arc-authentication-results;
        bh=BzioCZzTC3avQjTOgW/zqX3R/OP8J4GncNxZ5A/1R0Y=;
        b=X51Ogdk+g+uXBlEVMh7FJh2POYCf2UHjGJ5bxqbNx3R6s1UXfQrji/RRkoJFujdWBN
         fNGgR8AuOaYsHomLVRfTqpawqzPFT86bmi+tHr+0kmj7M3rIy8qyrlk0h8bTxvJOE6kD
         I4u/f6f0k4oUhIhNBiOaGUqL5jcbd3z47OK2vmxb9vGE19FX/mrlb4du/vCxkF1h272U
         spx0v5PuwcIL1TWbyUl5/qOTG+q0TKG6Dq9t/sU2IgMHfYPRuc52RPl+CFjbqy/QD0dw
         lVj0ejCpjwOV8Xw5IIoG+ByuZTNNcQiPBzY7TEb7AqgJEeAYHOg5/rGR7EAGUYLEsyVr
         TaoQ==
ARC-Authentication-Results: i=1; mx.google.com;
       spf=neutral (google.com: 18.204.20.215 is neither permitted nor denied by best guess record for domain of noreply@spamcop.invisionmanaged.net) smtp.mailfrom=noreply@spamcop.invisionmanaged.net
Return-Path: <noreply@spamcop.invisionmanaged.net>
Received: from ip-172-31-36-239.ec2.internal (ec2-18-204-20-215.compute-1.amazonaws.com. [18.204.20.215])
        by mx.google.com with ESMTPS id f130si857673qkb.193.2018.04.27.01.59.45
        for <x>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 27 Apr 2018 01:59:45 -0700 (PDT)
Received-SPF: neutral (google.com: 18.204.20.215 is neither permitted nor denied by best guess record for domain of noreply@spamcop.invisionmanaged.net) client-ip=18.204.20.215;
Authentication-Results: mx.google.com;
       spf=neutral (google.com: 18.204.20.215 is neither permitted nor denied by best guess record for domain of noreply@spamcop.invisionmanaged.net) smtp.mailfrom=noreply@spamcop.invisionmanaged.net
Received: from localhost (localhost [127.0.0.1]) by ip-172-31-36-239.ec2.internal (8.14.4/8.14.4) with ESMTP id w3R8xjMO029899 for <x>; Fri, 27 Apr 2018 08:59:45 GMT
Message-Id: <201804270859.w3R8xjMO029899@ip-172-31-36-239.ec2.internal>
MIME-Version: 1.0
To: <x>
From: SpamCop Discussion <noreply@spamcop.invisionmanaged.net>
Subject: Your registration is complete!
Date: Fri, 27 Apr 2018 08:59:45 +0000
Auto-Submitted: auto-generated
Content-Type: multipart/alternative; boundary="--==_mimepart_f9b41e5d8e2afc934769b5867abe951f"; charset=UTF-8
Content-Transfer-Encoding: 8bit

It seems to indicate that there is something wrong with how SpamCop handles IPv6 addresses and that the list of relaying IPv6 addresses for Gmail is incomplete.

Can this be escalated to the right people for investigation?

[petzl]

11 hours ago, Axellence said:

It seems to indicate that there is something wrong with how SpamCop handles IPv6 addresses and that the list of relaying IPv6 addresses for Gmail is incomplete.

Can this be escalated to the right people for investigation?

I were getting a lot of this also. but by cutting the spoofed headers it stopped coming, now I only get real headers. never the spoofed variety.

These are genuine Gmail headers  https://www.spamcop.net/sc?id=z6461350211z4ef67168cec9b57a466a6e5a240b31c7z 

[klappa]

I've got a dozen of these lately. What should i do. Spamcop can't parse the Received line because of this. I have to manually remove it everytime.

 

On 4/28/2018 at 12:20 AM, petzl said:

I were getting a lot of this also. but by cutting the spoofed headers it stopped coming, now I only get real headers. never the spoofed variety.

These are genuine Gmail headers  https://www.spamcop.net/sc?id=z6461350211z4ef67168cec9b57a466a6e5a240b31c7z 

How can cutting the spoofed headers make them stop coming? I have been receiving them more and more lately. I think Spamcop can't handle the IPv6 addresses. And by removing that line they will throw the spamcop reports away.

 

Just one example

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

[Axellence]

It might have been unclear but my point was that the supposedly invalid Receive header is not spoofed.

As I wrote, the "internal" IPv6 2002:0000::/16 addresses appear in Received headers of all Gmail messages, not just SPAM. That's why I suggested to look into Spamcop IPv6 address handling.

@klappa for now, removing the Receive headers is the only way to make Spamcop process Gmail SPAM messages. This should work for those who submit them manually, not using forwarding.

[Lking]

42 minutes ago, klappa said:

How can cutting the spoofed headers make them stop coming? I have been receiving them more and more lately.

It is easy to forget that there is not a direct link between submitting spam and you not receiving similar spam, unless your ISP is using the SCBL to filter your incoming email.

Generally for you to stop receiving the spoofed spam, the spammer's ISP or in this case gmail needs to cut the spammer from the internet or block the spoofed email.  By cutting spoofed header lines, and including those lines in the remarks section of the report as petzl suggest, the spam can be parsed, reports sent to ISPs, and giving them the information needed to block the spam.

[petzl]

41 minutes ago, Axellence said:

It might have been unclear but my point was that the supposedly invalid Receive header is not spoofed.

As I wrote, the "internal" IPv6 2002:0000::/16 addresses appear in Received headers of all Gmail messages, not just SPAM. That's why I suggested to look into Spamcop IPv6 address handling.

@klappa for now, removing the Receive headers is the only way to make Spamcop process Gmail SPAM messages. This should work for those who submit them manually, not using forwarding.

Gmails genuine "ARC" headers are parsed easily and correctly by SpamCop. Test it with one of your genuine emails. It will work. (of course CANCEL don't submit)

I also were getting a lot of spoofed Gmail headers, being aggressive with spammers. I try to be better than SpamCop, finding REAL contacts including FaceBook and Twitter to complain to. Consequently the spoofed headers have stopped coming. Yes "submit them manually, not using forwarding" is the only way, Gmail have reported that they are getting spoofed headers with many confusing Gmails sorting program with many ending up in sent folder. https://www.theregister.co.uk/2018/04/23/spammers_slipping_spoofed_gmails_sent_folder/

[SpamStoolie]

8 minutes ago, petzl said:

Gmails genuine "ARC" headers are parsed easily and correctly by SpamCop. Test it with one of your genuine emails. It will work. (of course CANCEL don't submit)

I also were getting a lot of spoofed Gmail headers, being aggressive with spammers. I try to be better than SpamCop, finding REAL contacts including FaceBook and Twitter to complain to. Consequently the spoofed headers have stopped coming. Yes "submit them manually, not using forwarding" is the only way, Gmail have reported that they are getting spoofed headers with many confusing Gmails sorting program with many ending up in sent folder. https://www.theregister.co.uk/2018/04/23/spammers_slipping_spoofed_gmails_sent_folder/

This is not the problem. I am not winding up with spurious messages in my sent folder.

As Axellence said, legitimate Gmail messages do not parse at this point.

[petzl]

4 hours ago, SpamStoolie said:

As Axellence said, legitimate Gmail messages do not parse at this point.

Gmail always parse for me? I also had none in my sent box when were getting spoofed headers. Heres one reported today.
https://www.spamcop.net/sc?id=z6463670430z2f708982f0ba63f6146d9669b2a833b8z

[SpamStoolie]

A recent legitimate Gmail message produces:

SpamCop v 4.9.0 © 2018 Cisco Systems, Inc. All rights reserved.
Here is your TRACKING URL - it may be saved for future reference:
(…)
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.

[petzl]

21 minutes ago, SpamStoolie said:

A recent legitimate Gmail message produces:

SpamCop v 4.9.0 © 2018 Cisco Systems, Inc. All rights reserved.
Here is your TRACKING URL - it may be saved for future reference:
(…)
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.

you are time wasting no track suspect you need to be plonked?

[Axellence]

4 hours ago, petzl said:

Gmail always parse for me? I also had none in my sent box when were getting spoofed headers. Heres one reported today.
https://www.spamcop.net/sc?id=z6463670430z2f708982f0ba63f6146d9669b2a833b8z

I compared headers from your report to the legitimate message report I posted in this comment (z6461656360ze0de39c07007d4266f319e51c6c48c57z). Your report does not contain an IPv6 address in first Received header. However, the header contains an IPv4 address 10.236.176.22 which is in the 10.0.0.0/8 block used for private networks. For some reason, SpamCop parser is able to skip past that internal IP address and detect the actual receiving system.

Let me emphasize once more that the headers are not spoofed and this issue is reproducible with completely legit Gmail messages containing block 2002:0000::/16 IPv6 addresses in Received header.

BTW, all email notifications from this forum are marked as SPAM by Gmail.

[petzl]

11 minutes ago, Axellence said:

I compared headers from your report to the legitimate message report I posted in this comment (z6461656360ze0de39c07007d4266f319e51c6c48c57z). Your report does not contain an IPv6 address in first Received header. However, the header contains an IPv4 address 10.236.176.22 which is in the 10.0.0.0/8 block used for private networks. For some reason, SpamCop parser is able to skip past that internal IP address and detect the actual receiving system.

Let me emphasize once more that the headers are not spoofed and this issue is reproducible with completely legit Gmail messages containing block 2002:0000::/16 IPv6 addresses in Received header.

BTW, all email notifications from this forum are marked as SPAM by Gmail.

these are spoofed headers?

Delivered-To: x
Received: by 2002:a4f:d0c:0:0:0:0:0 with SMTP id 12-v6csp521891ivn;
        Fri, 27 Apr 2018 01:59:45 -0700 (PDT)
X-Google-Smtp-Source: AB8JxZp8WM/6SO2Mvqz1evriecBCFsoKSSszBe4U0l5u+ugfNfkM9FYmaSfFK1pZKAfVCltF2iKz
X-Received: by 10.55.204.134 with SMTP id n6mr1075284qkl.429.1524819585481;
        Fri, 27 Apr 2018 01:59:45 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1524819585; cv=none;
        d=google.com; s=arc-20160816;
        b=S6de573RWOjuGu+63Zv7sAeioqwM2zPtoahrSZOX67HU4H74SWTskNK6mQJ/VBP2k4
         Z1uVoLrpnprkmVcHKOOGafPdF0c2XRVJBfmeZ57Ox5vkQsZ1EVZlH8/13ozLpTgLV5zr
         s7KjftL6iRtEyQZUj1cgCcC6dDwTIr907U0dKcDaBLGcFRD8jW4mTT1OOd+I2MBBHVoa
         SNQ/Hrx0eLNTN6Lqc5vZarJ4u+4wRelYbBl2ByjeuTyn2Icr2h7P9GHnwDqw14spj8Kk
         axmTa4KPtjUfT/NbNg9EdsLXdHdhaFXuRiN4jGWjklOg7PWnsa5K4Co9O5oAKjQvX4Bb
         DKgA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=content-transfer-encoding:auto-submitted:date:subject:from:to
         :mime-version:message-id:arc-authentication-results;
        bh=BzioCZzTC3avQjTOgW/zqX3R/OP8J4GncNxZ5A/1R0Y=;
        b=X51Ogdk+g+uXBlEVMh7FJh2POYCf2UHjGJ5bxqbNx3R6s1UXfQrji/RRkoJFujdWBN
         fNGgR8AuOaYsHomLVRfTqpawqzPFT86bmi+tHr+0kmj7M3rIy8qyrlk0h8bTxvJOE6kD
         I4u/f6f0k4oUhIhNBiOaGUqL5jcbd3z47OK2vmxb9vGE19FX/mrlb4du/vCxkF1h272U
         spx0v5PuwcIL1TWbyUl5/qOTG+q0TKG6Dq9t/sU2IgMHfYPRuc52RPl+CFjbqy/QD0dw
         lVj0ejCpjwOV8Xw5IIoG+ByuZTNNcQiPBzY7TEb7AqgJEeAYHOg5/rGR7EAGUYLEsyVr
         TaoQ==

Removed parse fine?  https://www.spamcop.net/sc?id=z6463773946zc33f66145c6de6e5767456405e9916a6z

[Axellence]

6 minutes ago, petzl said:

these are spoofed headers?

[snip]

Removed parse fine?  https://www.spamcop.net/sc?id=z6463773946zc33f66145c6de6e5767456405e9916a6z

No, those headers are not spoofed. That is a legit confirmation message from this forum. I tested the message and posted it as a proof of the issue.

My point is that we shouldn't have to remove legitimate headers when reporting spam. SpamCop parser should handle the IPv6 private-block addresses in receive headers the same way it does with IPv4 counterparts.

[klappa]

10 hours ago, Axellence said:

It might have been unclear but my point was that the supposedly invalid Receive header is not spoofed.

As I wrote, the "internal" IPv6 2002:0000::/16 addresses appear in Received headers of all Gmail messages, not just SPAM. That's why I suggested to look into Spamcop IPv6 address handling.

@klappa for now, removing the Receive headers is the only way to make Spamcop process Gmail SPAM messages. This should work for those who submit them manually, not using forwarding.

Yea it works but does hosting abuse contact or whatever know that i cut the Received line? Those this hinder my report in any way? Should i also cut the Received line when sending to respective country CERT team?

10 hours ago, Lking said:

It is easy to forget that there is not a direct link between submitting spam and you not receiving similar spam, unless your ISP is using the SCBL to filter your incoming email.

Generally for you to stop receiving the spoofed spam, the spammer's ISP or in this case gmail needs to cut the spammer from the internet or block the spoofed email.  By cutting spoofed header lines, and including those lines in the remarks section of the report as petzl suggest, the spam can be parsed, reports sent to ISPs, and giving them the information needed to block the spam.

See above! Yes of course but are those really spoofed emails? See example further below.

9 hours ago, SpamStoolie said:

This is not the problem. I am not winding up with spurious messages in my sent folder.

As Axellence said, legitimate Gmail messages do not parse at this point.

Not me either.

5 hours ago, petzl said:

Gmail always parse for me? I also had none in my sent box when were getting spoofed headers. Heres one reported today.
https://www.spamcop.net/sc?id=z6463670430z2f708982f0ba63f6146d9669b2a833b8z

No IPv6 address.

26 minutes ago, Axellence said:

No, those headers are not spoofed. That is a legit confirmation message from this forum. I tested the message and posted it as a proof of the issue.

My point is that we shouldn't have to remove legitimate headers when reporting spam. SpamCop parser should handle the IPv6 private-block addresses in receive headers the same way it does with IPv4 counterparts.

Yea! I find it hard that their spoofed. Spamcop should look into this.

This is another example recently.

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

[petzl]

1 hour ago, klappa said:

Yea! I find it hard that their spoofed. Spamcop should look into this.

This is another example recently.

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

That/your link parsed perfectly?

[klappa]

2 hours ago, petzl said:

That/your link parsed perfectly?

After I removed the Received line. Otherwise it wouldn't Parse because of that IPv6 address. I've gotten different sources of spam. The only common denominator is the IPv6 which isn't the same but still a IPv6 address that breaks the parsing.

[SpamStoolie]

7 hours ago, petzl said:

you are time wasting no track suspect you need to be plonked? 

You are wasting our time.

Here is the tracking URL for the notification of your reply: https://www.spamcop.net/sc?id=z6463822062z8cea344e1ac8a0c262e9cf021e05903cz

It does not parse. — Mailhost configuration problem, identified internal IP as source

Here is a version which does parse: https://www.spamcop.net/sc?id=z6463822656za92385fcecb72345790cc09bcf381478z

What’s the difference? I removed this legitimate Received header:

Received: by 2002:a19:2203:0:0:0:0:0 with SMTP id i3-v6csp2712149lfi;
        Sun, 6 May 2018 22:35:22 -0700 (PDT)

This tool: https://toolbox.googleapps.com/apps/messageheader/  parses the message in its original form just fine. (Notice that it has parsed the offending header, identifying it as the final [Google] SMTP server to handle the message.)

#	Delay	From *			To *	Protocol	Time received
0	2 sec	localhost	→		ip-172-31-39-65.ec2.internal	ESMTP	5/7/2018, 1:32:19 AM EDT
1	3 mins	ec2-54-164-168-129.compute-1.amazonaws.com.	→	[Google]	mx.google.com	ESMTPS	5/7/2018, 1:35:21 AM EDT
2			→	[Google]	2002:a50:db8c::	SMTP	5/7/2018, 1:35:21 AM EDT
3	1 sec		→	[Google]	2002:a19:2203:0:0:0:0:0	SMTP	5/7/2018, 1:35:22 AM EDT

So, unless you believe that the SpamCop Forum is a spammer, inserting “spoofed headers” to confuse SpamCop in a very subtle way…