Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Axellence

  • Rank
  1. Axellence

    Spamcop cannot find source IP

    Yes, SpamCop parser is just a tool. But it is also a piece of software and software can b3 improved and should be improved when new issues pop up. Take this from a software developer. How many times do we have to repeat that the headers are not spoofed? Same receiving addresses appear in all legitimate Gmail messages, so they are not spoofed. I'd rather have a conversation with someone who knows the internals of the SpamCop setup. As a proof of the issue, I just reported a real SPAM message but I was only able to do so by replacing the IPv6 address with mx.google.com . Here's the parse result: https://www.spamcop.net/sc?id=z6463956991zb94e10c6789e02261b2ccf5ce24b67cdz Originally the first header was this: Received: by 2002:a4f:d0c:0:0:0:0:0 with SMTP id 12-v6csp3518497ivn; Mon, 7 May 2018 15:19:34 -0700 (PDT) That might be a better solution than removing the headers but still, it doesn't seem right. And I have also confirmed that the headers are not spoofed by sending a message containing bare minimum of headers to my Gmail address form a mailserver I control.
  2. Axellence

    Spamcop cannot find source IP

    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.
  3. Axellence

    Spamcop cannot find source IP

    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 which is in the 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.
  4. Axellence

    Spamcop cannot find source IP

    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.
  5. Axellence

    Spamcop cannot find source IP

    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 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: 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. []) by mx.google.com with ESMTPS id f130si857673qkb.193.2018. 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: is neither permitted nor denied by best guess record for domain of noreply@spamcop.invisionmanaged.net) client-ip=; Authentication-Results: mx.google.com; spf=neutral (google.com: 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 []) 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?