Jump to content

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


Recommended Posts

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

 

Link to comment
Share on other sites

"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 by RobiBue
Link to comment
Share on other sites

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 by Martijn Lievaart
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by petzl
Link to comment
Share on other sites

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 by gnarlymarley
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...