Spamcop cannot find source IP

[nzeid]

On 5/18/2018 at 7:47 PM, Lking said:

I suggest everyone take a deep breath and relax for a minute or two or more.  This thread needs to focus on the technical issues, NOT individuals, individual understanding nor motives.

Do keep in mind that how to work with the tool(s) available is the purpose of this forum (Reporting Help) and that there is low probability that any changes will be made to the SpamCop parser to accommodate a draft standard or miss formatted header lines currently being inserted by gmail/google.

That is the view of a volunteer moderator not employed by SpamCop in anyway.

This is a pretty aggressive problem that almost obsoletes SpamCop, and I'm not sure what to make of this particular response.

From what I understand reading so far, this header field is broken because the By-domain that Google is injecting is internal crap. But I'm actually impressed this is allowed at all... doesn't the Received field require a "from" section to begin with? If SpamCop already made the leap to handle such non-standard fields, why stop now? It's a small, innocuous change to the parser to simply skip a well-formatted field with consistent (bad) data. And if this kind of header mangling does in fact compromise the entire spam reporting process, why not take this opportunity to voice the dilemma in detail? We're all left scratching our heads wondering how this approach will encourage people to use SpamCop to report spam.

If you're not the right person to talk to, to whom can we refer this problem?

[RobiBue]

3 hours ago, nzeid said:

This is a pretty aggressive problem that almost obsoletes SpamCop, and I'm not sure what to make of this particular response.

From what I understand reading so far, this header field is broken because the By-domain that Google is injecting is internal crap. But I'm actually impressed this is allowed at all... doesn't the Received field require a "from" section to begin with? If SpamCop already made the leap to handle such non-standard fields, why stop now? It's a small, innocuous change to the parser to simply skip a well-formatted field with consistent (bad) data. And if this kind of header mangling does in fact compromise the entire spam reporting process, why not take this opportunity to voice the dilemma in detail? We're all left scratching our heads wondering how this approach will encourage people to use SpamCop to report spam.

If you're not the right person to talk to, to whom can we refer this problem?

Unfortunately, SpamCop is currently broken when it comes to some IPv6 addresses in the Received: line(s).

Since SpamCop is now a subsidiary of Cisco, and part of Talos, I sent them a message, asking them to update the parser to correctly parse private networks through the IPv6 format and especially in the 6to4 ranges. I do not know if this will do any good, but I am hopeful that it will land at someone competent's desk and get implemented soon.

Someone is misinformed and spreading this misinformation in regard to google and their email header injections.

Although it is fairly new, ARC headers have been under development since about 2015 and google has been inserting them since mid 2017 without it affecting SpamCop at all, since SpamCop doesn't even check those headers. SpamCop plainly ignores them.

The problem has been arising since google decided to insert IPv6 6to4 addresses in their Received: lines where it comes to their servers. This, unfortunately, breaks SpamCop and its ability to parse the Received: chain correctly.

Currently, the only "correct" way to parse spam and submit them without munging or falsifying headers is to convert the IPv6 Received: address which is usually a private network in the range of 2002:a00:: - 2002:aff:ffff:: to the equivalent IPv4 address space of 10.0.0.0/8. Well, it's still munging/falsifying the headers, but since the IPv6 address is a 6to4 (https://tools.ietf.org/html/rfc3056 and https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml) address, it's basically an IPv4 address in disguise.

An easy IPv6 to IPv4 translator is http://www.potaroo.net/cgi-bin/ipv6addr.

I am neither a google employee (although I wouldn't mind) nor am I directly involved with SpamCop (although I have been using it for over 10 years) so I am not the one to talk to either ?

But as I mentioned earlier, I am hopeful, that someone at Talos will fix the parser to comprehend correctly the IPv6 variant of the IPv4 Private networks.

 

[petzl]

2 hours ago, RobiBue said:

I am neither a google employee (although I wouldn't mind) nor am I directly involved with SpamCop (although I have been using it for over 10 years) so I am not the one to talk to either ?

But as I mentioned earlier, I am hopeful, that someone at Talos will fix the parser to comprehend correctly the IPv6 variant of the IPv4 Private networks.

 

I get mail from FastMail they use ARC without IPv6 IP's it passes OK?

https://www.spamcop.net/sc?id=z6465862542zde0280bc96b77cf07f6a8d426a2f559az

[nzeid]

12 hours ago, RobiBue said:

Unfortunately, SpamCop is currently broken when it comes to some IPv6 addresses in the Received: line(s).

Since SpamCop is now a subsidiary of Cisco, and part of Talos, I sent them a message, asking them to update the parser to correctly parse private networks through the IPv6 format and especially in the 6to4 ranges. I do not know if this will do any good, but I am hopeful that it will land at someone competent's desk and get implemented soon.

Someone is misinformed and spreading this misinformation in regard to google and their email header injections.

Although it is fairly new, ARC headers have been under development since about 2015 and google has been inserting them since mid 2017 without it affecting SpamCop at all, since SpamCop doesn't even check those headers. SpamCop plainly ignores them.

The problem has been arising since google decided to insert IPv6 6to4 addresses in their Received: lines where it comes to their servers. This, unfortunately, breaks SpamCop and its ability to parse the Received: chain correctly.

Currently, the only "correct" way to parse spam and submit them without munging or falsifying headers is to convert the IPv6 Received: address which is usually a private network in the range of 2002:a00:: - 2002:aff:ffff:: to the equivalent IPv4 address space of 10.0.0.0/8. Well, it's still munging/falsifying the headers, but since the IPv6 address is a 6to4 (https://tools.ietf.org/html/rfc3056 and https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml) address, it's basically an IPv4 address in disguise.

An easy IPv6 to IPv4 translator is http://www.potaroo.net/cgi-bin/ipv6addr.

I am neither a google employee (although I wouldn't mind) nor am I directly involved with SpamCop (although I have been using it for over 10 years) so I am not the one to talk to either ?

But as I mentioned earlier, I am hopeful, that someone at Talos will fix the parser to comprehend correctly the IPv6 variant of the IPv4 Private networks.

 

Thank you for the thorough explanation.

From my reading, it is in fact a violation of the 6to4 convention to use the private IPv4 space. Or it could simply be that SpamCop doesn't play well with IPv6 at all. But, as you probably agree, it doesn't justify a hard failure for spam reporting. Also, thanks for issuing a report on our behalf.

[SpamStoolie]

13 hours ago, RobiBue said:

…

Someone is misinformed and spreading this misinformation in regard to google and their email header injections.

Although it is fairly new, ARC headers have been under development since about 2015 and google has been inserting them since mid 2017 without it affecting SpamCop at all, since SpamCop doesn't even check those headers. SpamCop plainly ignores them.

The problem has been arising since google decided to insert IPv6 6to4 addresses in their Received: lines where it comes to their servers. This, unfortunately, breaks SpamCop and its ability to parse the Received: chain correctly.

…

Thank you.

 

51 minutes ago, nzeid said:

From my reading, it is in fact a violation of the 6to4 convention to use the private IPv4 space. Or it could simply be that SpamCop doesn't play well with IPv6 at all. But, as you probably agree, it doesn't justify a hard failure for spam reporting. Also, thanks for issuing a report on our behalf.

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.

 

[SpamStoolie]

On 5/19/2018 at 2:59 AM, petzl said:

I suspect ARC if used correctly supposed to delete emails that do not match the sending IP (from domain)? Not intended for sorting

There is no need for supposition. Take a few minutes, and read about ARC.

http://arc-spec.org/

Quote

 

…

What is ARC?

When an email sender or Internet domain owner uses email authentication to make it easier to detect fraudsters sending messages that impersonate their domain, some services like mailing lists or account forwarding may cause legitimate messages to not pass those mechanisms, and such messages might not be delivered. These services may be referred to as intermediaries because they receive a message, potentially make some changes to it, and then send it on to one or more other destinations. This kind of email traffic may be referred to as an indirect mailflow.

ARC preserves email authentication results across subsequent intermediaries (“hops”) that may modify the message, and thus would cause email authentication measures to fail to verify when that message reaches its final destination. But if an ARC chain were present and validated, a receiver who would otherwise discard the messages might choose to evaluate the ARC results and make an exception, allowing legitimate messages from these indirect mailflows to be delivered.

Between October 2015 and February 2017, the ARC protocol benefited from community review and input while several parties planned and then developed implementations. A number of interoperability events were held so that these implementations could be tested against each other. The IETF DMARC Working Group continues to analyze the protocol with an eye to future improvements.
…

 

 

[nzeid]

1 hour ago, SpamStoolie said:

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.

 

You're right, it would have to be OK by extension of 3056. I am intimately aware of tunneling interfaces and all that, but it didn't occur to me that this is something that would end up in the Received chain of an email.

I did some testing for kicks, though. It turns out that emails terminate at this 2002:: address regardless of whether you send your email over v4 or v6. This suggests that the boxes at which these emails terminate neither do end-to-end v4 or end-to-end v6. But this is still speculation. It could be that Google is imposing a v6 format out of sheer convenience.

[SpamStoolie]

27 minutes ago, nzeid said:

I did some testing for kicks, though. It turns out that emails terminate at this 2002:: address regardless of whether you send your email over v4 or v6. This suggests that the boxes at which these emails terminate neither do end-to-end v4 or end-to-end v6. But this is still speculation. It could be that Google is imposing a v6 format out of sheer convenience.

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.)

[lisati]

Just a thought: if Google, or any other provider for that matter, does something at their end that interferes with Spamcop's ability to correctly identify the source of an email, it's not necessarily Spamcop's fault.

The team at Spamcop are under no obligation to jump to attention and make changes every time we, the users, encounter something that trips up the parsing and reporting process. They will have their priorities, which might not always coincide with what we'd like to see happen.

There have been some good suggestions in this and similar discussions. I wish you all well.

[its8up]

Yo!  I've been using SPAMCOP for a long time (5-8 years -- IDK).  I got tired of the manual reporting grind about 3 years ago and automated the most tedious part of the process.  It is fairly simple to confirm spam by header info or body keywords and to email full header + body via scri_pt.google.com, thus only requiring a daily trip to the spamcop site to finalize all reports.  It even sends a copy to the FCC and to the abuse email address of the domains I see most frequently.  (I know double reporting is frowned upon, but f*%k ocn.ad.jp!)  It was all working great until a few months ago, as more and more gmail headers utilized the new Received line.

Now, just like the rest of you have discovered, ALL gmail has the same SPAMCOP incompatible header.  This header fiasco is really chafing my weiner.  Any email handling service that wishes to survive will ensure compatibility with the world's largest email provider.  SPAMCOP does not give a f*%k..  Google has only been the world's largest email provider for five years or so.  We who report spam are the minority among email users, and surely the majority of SPAMCOP reports are done via their free reporting service.  That means SPAMCOP cannot be a cash cow for Cysco.  As such, any changes to SPAMCOP's algorithm will happen if and when Cysco friggin feels like allowing it to happen.

I am no scripting guru, thus it is simpler to stop reporting to SPAMCOP all together rather than altering my scri_pt to cut out the problem data identified by PETZL.  However, I do thank you PETZL for your effort in this fiasco.

The only alteration my scri_pt ever needed was to also forward spam to scamback (thank you person who mentioned that service but whose username I do not remember!).

 

I may try back in a few months, but goodbye for now SPAMCOP community! 

[petzl]

5 hours ago, SpamStoolie said:

There is no need for supposition. Take a few minutes, and read about ARC.

http://arc-spec.org/

So it is pointy-head junk that does nothing better than the older method in fact seems more inferior way of sorting spam, example had a reply from Microsoft abusse that Gmail (2002:a6b:a74f:0:0:0:0:0) sorted to spam folder, Not impressed, also a lot of Gmail supposed internal IPv6  stamps are gobbledygook I report most spam from my account with Fastmail that use ARC sorting, SpamCop never have problems  with parsing them? Gmail seem to be on a death march IMO. No I'm not a mailbox provider or mailing list operator, I just don't like spam! But like spam.

I am working on this to me the problem is Gmail, I do like the idea of just reject email that's not set up right. The IP  "network" address given by Gmail  is gibberish does not specify a IP?

[SpamStoolie]

1 hour ago, petzl said:

So it is pointy-head junk that does nothing better than the older method in fact seems more inferior way of sorting spam, example had a reply from Microsoft abusse that Gmail (2002:a6b:a74f:0:0:0:0:0) sorted to spam folder, Not impressed, …

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

Quote

   The Authenticated Received Chain (ARC) protocol creates a mechanism
   whereby a series of handlers of an email message can conduct
   authentication of the email message as it passes among them on the
   way to its destination, and create an attached, authenticated record
   of the status at each step along the handling path, for use by the
   final recipient in making choices about the disposition of the
   message.  Changes in the message that might break existing
   authentication mechanisms can be identified through the ARC Set of
   header fields.

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

1 hour ago, petzl said:

internal IPv6  stamps are gobbledygook

Could you cite an example of an IPv6 “stamp” which is “gobbledygook?”

[ChuckGary61]

On 5/21/2018 at 5:16 AM, RobiBue said:

Unfortunately, SpamCop is currently broken when it comes to some IPv6 addresses in the Received: line(s).

Since SpamCop is now a subsidiary of Cisco, and part of Talos, I sent them a message, asking them to update the parser to correctly parse private networks through the IPv6 format and especially in the 6to4 ranges. I do not know if this will do any good, but I am hopeful that it will land at someone competent's desk and get implemented soon.

Someone is misinformed and spreading this misinformation in regard to google and their email header injections.

Although it is fairly new, ARC headers have been under development since about 2015 and google has been inserting them since mid 2017 without it affecting SpamCop at all, since SpamCop doesn't even check those headers. SpamCop plainly ignores them.

The problem has been arising since google decided to insert IPv6 6to4 addresses in their Received: lines where it comes to their servers. This, unfortunately, breaks SpamCop and its ability to parse the Received: chain correctly.

Currently, the only "correct" way to parse spam and submit them without munging or falsifying headers is to convert the IPv6 Received: address which is usually a private network in the range of 2002:a00:: - 2002:aff:ffff:: to the equivalent IPv4 address space of 10.0.0.0/8. Well, it's still munging/falsifying the headers, but since the IPv6 address is a 6to4 (https://tools.ietf.org/html/rfc3056 and https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml) address, it's basically an IPv4 address in disguise.

An easy IPv6 to IPv4 translator is http://www.potaroo.net/cgi-bin/ipv6addr.

I am neither a google employee (although I wouldn't mind) nor am I directly involved with SpamCop (although I have been using it for over 10 years) so I am not the one to talk to either ?

But as I mentioned earlier, I am hopeful, that someone at Talos will fix the parser to comprehend correctly the IPv6 variant of the IPv4 Private networks.

 

I was beginning to think SPAMMERS had found a new way to fool the spamcop parser!

If spam assumes new formats, spamcop - a paid service - should include adaptations or instructions on how to go around these issues.

Thank you RobieBue, this worked like a charm.

[petzl]

5 hours ago, SpamStoolie said:

Apparently, you don't grasp the purpose of ARC, or what Google is doing with it currently.

Thought I did (2002:a6b:a74f:0:0:0:0:0))? Not sure but if Gmail is nor "arsing"  about and would leave it alone forever, SpamCop could have it in as Mailhost overide 

[G. C.]

Right now Spamcop is failing to parse any GMail email source, either spam or legitimate.

The error message is always:

Mailhost configuration problem, identified internal IP as source
Mailhost:
Please correct this situation - register every email address where you receive spam
No source IP address found, cannot proceed.

Removing all the headers at the beginning of the message up to "ARC-Authentication-Results:"  included fixes the problem, but the parser is definitely broken for gmail messages.

G.

 

[SpamStoolie]

8 hours ago, petzl said:

Thought I did (2002:a6b:a74f:0:0:0:0:0))? Not sure but if Gmail is nor "arsing"  about and would leave it alone forever, SpamCop could have it in as Mailhost overide 

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:

On 5/21/2018 at 12:16 AM, RobiBue said:

An easy IPv6 to IPv4 translator is http://www.potaroo.net/cgi-bin/ipv6addr. 

This gives:

Quote

IPv6 Address Report

IPv6Address:		2002:a6b:a74f:0:0:0:0:0
AddressType:		2002:A6B:A74F:: 6to4 address
Subnet48Id:		0 (/48)
InterfaceId:		0:0:0:0
6to4IPv4:		10.107.167.79
Whois:		10.107.167.79

[petzl]

8 hours ago, SpamStoolie said:

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.)

I'm reasonably sure if google don't change this SpamCop could include this in their parser. They already do for network addresses on SpamCop email accounts.

[SpamStoolie]

Actually, I don’t believe the IPv6 address is the problem either.

 

Quote

Parsing header:
host 2002:a02:2107:0:0:0:0:0 (getting name) no name

0: Received: by 2002:a02:2107:0:0:0:0:0 with SMTP id e7-v6csp206472jaa; Tue, 22 May 2018 17:13:13 -0700 (PDT)
No unique hostname found for source: 2002:a02:2107:0:0:0:0:0

Possible forgery. Supposed receiving system not associated with any of your mailhosts
Will not trust this Received line.

Mailhost configuration problem, identified internal IP as source
Mailhost:
Please correct this situation - register every email address where you receive spam

No source IP address found, cannot proceed.
Add/edit your mailhost configuration
Finding full email headers
Submitting spam via email (may work better)
Example: What spam headers should look like

Nothing to do.

 

This server has no FQDN (i.e. no unique hostname.)

 

It is an internal IP address. (Internal to Google.)

 

---

[RJVB]

 

On 5/22/2018 at 1:04 AM, its8up said:

I may try back in a few months, but goodbye for now SPAMCOP community! 

 

I've had growing doubts as to SC's usefulness ever since their parsing engine started giving up on spams that contain too many links. Since then, more and more spam seems to have used this trick to avoid the automatic generation of reports to the spamvertised website ISPs. I've been hanging on though, but with just about all my email coming in on GMail I've also wondered why SC don't add a simple parsing rule to work around instead of breaking on the 2002: headers.

 

In the end I wrote a little filter that I added to the chain leading up to SpamAssassin (which handles the SC submission for me), a filter that does the IP6to4 translation described above in the message source. This is what SC should be doing, so it's an IMHO acceptable form of (de)mangling the headers.

If anyone is interested in the source (C++) I can upload it here or make it available some other way.

[RobiBue]

Since I'm using gmail, I wrote a little apps scri_pt (I am still trying to implement a few additions to it) and like RJVB, my scri_pt (de)munges the 6to4 address and replaces the the IPv6 with its IPv4 address equivalent and IMHO I do believe this is an acceptable form of header (de)munging.

Today I received a spam with an actual IPv6 address, and after (de)munging google's private 2002:axx:: address, SpamCop correctly identified the IPv6 sender, so I can attest, that SpamCop works when it comes to "valid" IPv6 addresses

https://www.spamcop.net/sc?id=z6466615389z4cdd3ad918544a33bcf0dc613af17294z

with "valid" I mean registered IPv6 addresses. I have yet to come by a 6to4 address from a registered IPv4 address to confirm the 2002:: working range when it comes to registered non-IPv6 addresses in the aforementioned 6to4 range.

[petzl]

26 minutes ago, RobiBue said:

I do believe this is an acceptable form of header (de)munging

If you can tell us how to run it on Windows 10 (not even WIN10 runs on WIN10) you have a winner.

[SpamStoolie]

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.

[RobiBue]

13 minutes ago, SpamStoolie said:

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.

I like the Comments: section. if it's ok with you I'll blatantly steal it

I did something similar, but when I tried it with the parens, SC did a weird thing:

Received:  by 10.176.8.72 (2002:ab0:848:0:0:0:0:0) with SMTP id b8-v6csp1225199uaf; Sat, 26 May 2018 19:22:05 -0700 (PDT)

Masking IP-based 'by' clause.

Received:  by 10.176.8.72 with SMTP id b8-v6csp1225199uaf; Sat, 26 May 2018 19:22:05 -0700 (PDT)

 

I've never seen that before...

[SpamStoolie]

7 minutes ago, RobiBue said:

Masking IP-based 'by' clause. 

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!

[klappa]

On 5/21/2018 at 6:16 AM, RobiBue said:

Unfortunately, SpamCop is currently broken when it comes to some IPv6 addresses in the Received: line(s).

Since SpamCop is now a subsidiary of Cisco, and part of Talos, I sent them a message, asking them to update the parser to correctly parse private networks through the IPv6 format and especially in the 6to4 ranges. I do not know if this will do any good, but I am hopeful that it will land at someone competent's desk and get implemented soon.

Someone is misinformed and spreading this misinformation in regard to google and their email header injections.

Although it is fairly new, ARC headers have been under development since about 2015 and google has been inserting them since mid 2017 without it affecting SpamCop at all, since SpamCop doesn't even check those headers. SpamCop plainly ignores them.

The problem has been arising since google decided to insert IPv6 6to4 addresses in their Received: lines where it comes to their servers. This, unfortunately, breaks SpamCop and its ability to parse the Received: chain correctly.

Currently, the only "correct" way to parse spam and submit them without munging or falsifying headers is to convert the IPv6 Received: address which is usually a private network in the range of 2002:a00:: - 2002:aff:ffff:: to the equivalent IPv4 address space of 10.0.0.0/8. Well, it's still munging/falsifying the headers, but since the IPv6 address is a 6to4 (https://tools.ietf.org/html/rfc3056 and https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml) address, it's basically an IPv4 address in disguise.

An easy IPv6 to IPv4 translator is http://www.potaroo.net/cgi-bin/ipv6addr.

I am neither a google employee (although I wouldn't mind) nor am I directly involved with SpamCop (although I have been using it for over 10 years) so I am not the one to talk to either ?

But as I mentioned earlier, I am hopeful, that someone at Talos will fix the parser to comprehend correctly the IPv6 variant of the IPv4 Private networks.

 

Does any ISP/Host/CERT organisation take these broken Spamcop reports seriously when one have to break out the Recieve line from the headers and write them down in the comments instead? 

Greateful for your input! It's very irritating reporting Spamcop using gmail nowadays. This wasn't the case until half a year ago.