Tracking message source: fd00:9742:5500:452:0:0:0:93

[Martijn Lievaart]

Tracking message source: fd00:9742:5500:452:0:0:0:93:

Display data:
"whois fd00:9742:5500:452:0:0:0:93@whois.arin.net" (Getting contact from whois.arin.net )
nothing found

No reporting addresses found for fd00:9742:5500:452:0:0:0:93, using devnull for tracking.

 

This is wrong, it's an internal handoff:

 

$ whois fd00:9742:5500:452:0:0:0:93
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object

inet6num:     fc00:0:0:0:0:0:0:0/7
descr:        Unique Local Unicast

remarks:      http://tools.ietf.org/html/rfc4193

source:       IANA

 

[RobiBue]

"Internal handoff" means that there is no reporting address to be found since it is internally and could be anywhere in any company.

It's basically the same as either of the three private IPv4 addresses: 10.0.0.0/8, 172.16.0.0/12, or the more common home network 192.168.0.0/16 used in most home networks.

This means that there is no set "reporting address" to contact the "owner" or its upstream owner.

SC is correct in this assessment and, no matter how strongly you might feel about it being wrong, it still won't find a reporting address since there is none to find.

 

I hope this explanation helps

Just in case I am unable to explain it clearly, there is a Wikipedia article related to Unique Local Address

Especially in the Properties section

Edited September 30, 2021 by RobiBue

[Martijn Lievaart]

What happens when Spamcop sees headers with addresses in 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16? It decides it is an internal handoff and moves on to the next header. It should do the same here as this is also an internal handoff. Instead it gives up.

 

Have a look at https://www.spamcop.net/sc?id=z6724892527z2437cf7d57aac95851075e601931e01dz for instance. Spamcop should report to the owner of 81.7.6.78 instead of giving up.

Edited September 30, 2021 by Martijn Lievaart

[gnarlymarley]

1 hour ago, Martijn Lievaart said:

0.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16?

Not much difference between RFC1918 and RFC4193.  The name and the number of bits in the address make the difference.

Hopefully, they don't change it again like they did with fec0::/10.

[Martijn Lievaart]

No progress? I would say headers with adresses fc00:0:0:0:0:0:0:0/7 should be skipped like the rfc1918 addresses.

[petzl]

4 hours ago, Martijn Lievaart said:

No progress? I would say headers with adresses fc00:0:0:0:0:0:0:0/7 should be skipped like the rfc1918 addresses.

You need a email server that does not send through its network first. For SpamCop to accurately parse.
Or read the headers yourself and then report.
source mail server 81.7.6.78
https://mxtoolbox.com/SuperTool.aspx?action=smtp%3a81.7.6.78&run=toolpage

Edited October 3, 2021 by petzl

[gnarlymarley]

16 hours ago, petzl said:

You need a email server that does not send through its network first.

Martijn, you might need to manually remove the private Received lines from the top and leave your border server at the top line until SpamCop gets this resolved.

Edited October 4, 2021 by gnarlymarley

[Martijn Lievaart]

6 hours ago, gnarlymarley said:

Martijn, you might need to manually remove the private Received lines from the top and leave your border server at the top line until SpamCop gets this resolved.

Thanks, that is what I'm doing now.