Spamcop cannot find source IP

[ChuckGary61]

1 hour ago, SpamStoolie said:

OK, at long last, I took some time to write a version in PHP.

It works for me. Maybe it will work for you.

SpamCopKludge.php

"Sorry, there is a problem

This attachment is not available. It may have been removed or the person who shared it may not have permission to share it to this location.
Error code: 2C171/1"

That's what that link turns up to me.

[BoZz]

Yes same here

[SpamStoolie]

8 hours ago, ChuckGary61 said:

This attachment is not available.

Hmmm…

SpamCopKludge.php

 

<?php
ini_set("auto_detect_line_endings", true);

switch ($argc)
{
    case 2 : $InputFile = $argv [1]; $OutputFile = $argv [1]; break;
    case 3 : $InputFile = $argv [1]; $OutputFile = $argv [2]; break;
    default : die('Usage: php SpamCopKludge InputFile [OutputFile]' . PHP_EOL);
}

if (file_exists($InputFile))
    $InputLines = file($InputFile);
else
    die ('The file, ' . $InputFile . ', does not exist!'  . PHP_EOL);

if ((!strncmp($InputLines[0],'Delivered-To:',13)) and (!strncmp($InputLines[1],'Received: by 2002:',18)))
{
                $IPv6 = strstr(strstr($InputLines[1],'2002:'),' ',true);

                $hextets = explode(':',$IPv6,8);

                $octets[0] = floor(hexdec($hextets[1])/256);
                $octets[1] = hexdec($hextets[1]) % 256;
                $octets[2] = floor(hexdec($hextets[2])/256);
                $octets[3] = hexdec($hextets[2]) % 256;
                $IPv4 = implode('.', $octets);

                $Kludge = $IPv4 . ' (' . $IPv6 .')'; /* Comment the IPv6 address, insert the IPv4 equivalent. */

                $KludgedLine1 = str_replace ($IPv6, $Kludge, $InputLines[1]);

                $OutputHandle = fopen($OutputFile,'w');

                fwrite ($OutputHandle, $InputLines[0]);
                fwrite ($OutputHandle, 'Comments: The following Received: header has been modified.' . PHP_EOL);
                fwrite ($OutputHandle, '          SpamCop chokes on the 6to4 [RFC-3964] address (now parenthesized.)' . PHP_EOL);
                fwrite ($OutputHandle, '          The equivalent IPv4 address has been inserted.' . PHP_EOL);
                fwrite ($OutputHandle, $KludgedLine1);

                for ($LineCount = 2; $LineCount <= count($InputLines); $LineCount++)
                       fwrite($OutputHandle, $InputLines[$LineCount]);

                fclose ($OutputHandle);
}
else
    if ($argc == 3)
                                file_put_contents($OutputFile, $InputLines, LOCK_EX);
?>

[ChuckGary61]

parenthesis being handshake-kosher or not, Hotmail spam with IPv6 format works!

"Received: from AM5EUR02HT112.eop-EUR02.prod.protection.outlook.com
 (2603:10a6:3:cf::25) by HE1PR03MB1338.eurprd03.prod.outlook.com with HTTPS
 via HE1P191CA0015.EURP191.PROD.OUTLOOK.COM; Sat, 23 Jun 2018 13:10:24 +0000"

parses correctly as:

Report spam to:

Re: 2603:10a6:3:cf:0:0:0:25 (Administrator of network where email originates)
 To: report_spam@hotmail.com (Notes)

so WHY doesn't Gmail's IPv6 header spam work? munging headers seems to be much less "kosher", IMO!

[SpamStoolie]

1 hour ago, ChuckGary61 said:

Received: from AM5EUR02HT112.eop-EUR02.prod.protection.outlook.com
 (2603:10a6:3:cf::25) by HE1PR03MB1338.eurprd03.prod.outlook.com with HTTPS
 via HE1P191CA0015.EURP191.PROD.OUTLOOK.COM; Sat, 23 Jun 2018 13:10:24 +0000

FWIW: there are a few differences here.

1. The G-Mail header is received by a 6to4 address, for an internal address (with no FQDN, and none can be resolved for it.)
2. The header you quote is received from a FQDN. The IPv6 address is commented out (parenthesized) so, effectively it is only the FQDN which is used. It is also received by a FQDN (with no IPv6 address.)
3. The G-Mail header uses a relaxed syntax.

Notice how these examples from the RFC supply both a from and a by host. Notice also that host names are used, as in the example you gave.

https://tools.ietf.org/html/rfc2822#appendix-A.4

A.4. Messages with trace fields

   As messages are sent through the transport system as described in
   [RFC2821], trace fields are prepended to the message.  The following
   is an example of what those trace fields might look like.  Note that
   there is some folding white space in the first one since these lines
   can be long.

----
Received: from x.y.test
   by example.net
   via TCP
   with ESMTP
   id ABC12345
   for <mary@example.net>;  21 Nov 1997 10:05:43 -0600
Received: from machine.example by x.y.test; 21 Nov 1997 10:01:22 -0600
From: John Doe <jdoe@machine.example>
To: Mary Smith <mary@example.net>
Subject: Saying Hello
Date: Fri, 21 Nov 1997 09:55:06 -0600
Message-ID: <1234@local.machine.example>

This is a message just to say hello.
So, "Hello".
----

 

Compare those to this:

Received: by 2002:a02:2115:0:0:0:0:0 with SMTP id e21-v6csp2430371jaa;
        Sat, 23 Jun 2018 18:14:27 -0700 (PDT)

 

However, the specification allows the syntax used by G-Mail.

https://tools.ietf.org/html/rfc2822#section-3.6.7

3.6.7. Trace fields

   The trace fields are a group of header fields consisting of an
   optional "Return-Path:" field, and one or more "Received:" fields.
   The "Return-Path:" header field contains a pair of angle brackets
   that enclose an optional addr-spec.  The "Received:" field contains a
   (possibly empty) list of name/value pairs followed by a semicolon and
   a date-time specification.  The first item of the name/value pair is
   defined by item-name, and the second item is either an addr-spec, an
   atom, a domain, or a msg-id.  Further restrictions may be applied to
   the syntax of the trace fields by standards that provide for their
   use, such as [RFC2821].

 

https://tools.ietf.org/html/rfc2822#appendix-B

Appendix B. Differences from earlier standards

   This appendix contains a list of changes that have been made in the
   Internet Message Format from earlier standards, specifically [RFC822]
   and [STD3].  Items marked with an asterisk (*) below are items which
   appear in section 4 of this document and therefore can no longer be
   generated.

   1. Period allowed in obsolete form of phrase.
   2. ABNF moved out of document to [RFC2234].
   3. Four or more digits allowed for year.
   4. Header field ordering (and lack thereof) made explicit.
   5. Encrypted header field removed.
   6. Received syntax loosened to allow any token/value pair.

 

Regardless, yes, I agree, SpamCop should handle the G-Mail headers. Yes, my scri_pt is a self-proclaimed kludge. Like all good kludges it is written out of pragmatism. I would like to report spam received by my G-Mail accounts, and this method allows me to do that.

[ChuckGary61]

1 hour ago, SpamStoolie said:

I would like to report spam received by my G-Mail accounts

... so I'll keep munging the headers from Gmail spam.

[SpamStoolie]

Well, I guess we need to define “munge.” If you mean “modify” that's what my kludge does. It modifies the header, in an automated fashion, maintaining all relevant information, and warning that (in fact) the header has been modified. I supplied it only to save others a bit of work.

If you prefer to do it manually, be my guest!

[ChuckGary61]

yup, you keep klunging I'll keep munging, friend. just a little copy/paste isn't that big a hassle. but I would rather SpamCop would parse all spam correctly, since I'm paying for it. But maybe not for much longer...

[klappa]

On 5/8/2018 at 5:52 AM, Axellence said:

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.

This will never be resolved. I am grateful for the quick replies i get from the Spamcop devs. But this seems to be running into a black hole. I wished i was more experienced like others in this thread but unfortunately i am not.