Jump to content

SpamStoolie

Members
  • Content Count

    34
  • Joined

  • Last visited

Community Reputation

0 Neutral

About SpamStoolie

  • Rank
    Member

Recent Profile Visitors

161 profile views
  1. SpamStoolie

    Spamcop cannot find source IP

    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!
  2. SpamStoolie

    Spamcop cannot find source IP

    FWIW: there are a few differences here. The G-Mail header is received by a 6to4 address, for an internal address (with no FQDN, and none can be resolved for it.) 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.) 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.
  3. SpamStoolie

    Spamcop cannot find source IP

    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); ?>
  4. SpamStoolie

    Spamcop cannot find source IP

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

    Spamcop cannot find source IP

    In mid-March, the ratio of spam reports to spam submissions dropped to about 1 to 1. In late march, the number of submissions was briefly higher than the number of reports. Now, the ratio of reports to submissions is increasing, but both are lower than before. I wonder if anyone who matters is watching the numbers…
  6. SpamStoolie

    Spamcop cannot find source IP

    I think this graph is quite telling: https://www.spamcop.net/spamgraph.shtml?spamyear
  7. SpamStoolie

    Spamcop cannot find source IP

    https://www.rfc-editor.org/rfc/rfc822.txt 3.4.3. COMMENTS A comment is a set of ASCII characters, which is enclosed in matching parentheses and which is not within a quoted-string The comment construct permits message originators to add text which will be useful for human readers, but which will be ignored by the formal semantics. Comments should be retained while the message is subject to interpretation according to this standard. However, comments must NOT be included in other cases, such as during protocol exchanges with mail servers. I currently modify the Gmail Received: header like so, commenting the 6to4 address with parentheses and inserting the IPv4 equivalent : Received: by 10.2.33.9 (2002:a02:2109:0:0:0:0:0) with SMTP id e9-v6csp39361jaa; Thu, 24 May 2018 20:09:34 -0700 (PDT)
  8. SpamStoolie

    Spamcop cannot find source IP

    Interesting… masking to see if it is in the same subnet perhaps? As for the Comments: section—“theft is the sincerest form of compliment” (or something like that…) be my guest!
  9. SpamStoolie

    Spamcop cannot find source IP

    I now have a scri_pt which modifies the headers like so: Delivered-To: x Comments: The following Received: header has been modified. Comments: SpamCop chokes on the 6to4 [RFC-3964] address (now parenthesized.) Comments: The equivalent IPv4 address has been inserted. Received: by 10.2.33.9 (2002:a02:2109:0:0:0:0:0) with SMTP id e9-v6csp39361jaa; Thu, 24 May 2018 20:09:34 -0700 (PDT) It appears to work. I may rewrite it to be cross-platform.
  10. SpamStoolie

    Spamcop cannot find source IP

    Actually, I don’t believe the IPv6 address is the problem either. This server has no FQDN (i.e. no unique hostname.) It is an internal IP address. (Internal to Google.)
  11. SpamStoolie

    Spamcop cannot find source IP

    Nothing about this is “gobbledygook.” You can translate this manually into its corresponding IPv4 address, by following the RFC: https://tools.ietf.org/html/rfc3056#section-2 The subscriber site is then deemed to have the following IPv6 address prefix, without any further assignment procedures being necessary: Prefix length: 48 bits Format prefix: 001 TLA value: 0x0002 NLA value: V4ADDR This is illustrated as follows: | 3 | 13 | 32 | 16 | 64 bits | +---+------+-----------+--------+--------------------------------+ |FP | TLA | V4ADDR | SLA ID | Interface ID | |001|0x0002| | | | +---+------+-----------+--------+--------------------------------+ Thus, this prefix has exactly the same format as normal /48 prefixes assigned according to [AGGR]. It can be abbreviated as 2002:V4ADDR::/48. Within the subscriber site it can be used exactly like any other valid IPv6 prefix, e.g., for automated address assignment and discovery according to the normal mechanisms such as [CONF, DISC], for native IPv6 routing, or for the "6over4" mechanism [6OVER4]. The (hexadecimal) IPv6 address, 2002:a6b:a74f:0:0:0:0:0 translates to the IPv4 address 0A:6B:A7:4f (hex) or 10.107.167.79 (decimal.) If you prefer, you can use the tool RobiBue pointed us to: This gives:
  12. SpamStoolie

    Spamcop cannot find source IP

    Apparently, you don't grasp the purpose of ARC, or what Google is doing with it currently. https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-14 https://luxsci.com/blog/arc-and-smtp-mta-sts.html However, the point is moot, since, the ARC headers are not the problem. The problem is also not IPv6 addresses. You say Could you cite an example of an IPv6 “stamp” which is “gobbledygook?”
  13. SpamStoolie

    Spamcop cannot find source IP

    My thought is, whether transported via IPv4 or IPv6, they still arrive at the same host, where they are handled by the same SMTP software, which creates a Received: header using the same address (in this case an IPv6 address.)
  14. SpamStoolie

    Spamcop cannot find source IP

    There is no need for supposition. Take a few minutes, and read about ARC. http://arc-spec.org/
  15. SpamStoolie

    Spamcop cannot find source IP

    Thank you. I don’t believe it is a violation (so long as Google has “at least one valid, globally unique 32-bit IPv4 address”): https://tools.ietf.org/html/rfc3056#section-2 Suppose that a subscriber site has at least one valid, globally unique 32-bit IPv4 address, referred to in this document as V4ADDR. This address MUST be duly allocated to the site by an address registry (possibly via a service provider) and it MUST NOT be a private address [RFC 1918]. https://tools.ietf.org/html/rfc3056#section-5.9 There is nothing to stop the above scenario being deployed within a private corporate network as part of its internal transition to IPv6; the corporate IPv4 backbone would serve as the virtual link layer for individual corporate sites using 2002:: prefixes. The V4ADDR MUST be a duly allocated global IPv4 address, which MUST be unique within the private network. The Intranet thereby obtains globally unique IPv6 addresses even if it is internally using private IPv4 addresses [RFC 1918]. Regardless, it seems like an easy enough case to handle.
×