Jump to content

Address 2002:adf:aa91:0:0:0:0:0 (gmail) not associated with any of your mailhosts


Recommended Posts

See spamcop parse result https://www.spamcop.net/sc?id=z6464480599z64a33ffd866670e22830aad1a6dd529fz parsing a mail I got (AFAIK) from gmail. The topmost Received line says:

Received: by 2002:adf:aa91:0:0:0:0:0 with SMTP id h17-v6csp1171932wrc;
        Fri, 11 May 2018 10:04:10 -0700 (PDT)

but SC cannot parse that, it says:

host 2002:adf:aa91:0:0:0:0:0 (getting name) no name

0: Received: by 2002:adf:aa91:0:0:0:0:0 with SMTP id h17-v6csp1171932wrc; Fri, 11 May 2018 10:04:10 -0700 (PDT)

No unique hostname found for source: 2002:adf:aa91: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.

 

Well, the only address where I receive _any_ mail is my @gmail address. How do I reconfigure my _already existing_ mailhost? Should I edit the header and change the mailhost address in it to the equivalent (but more usual) 2002:adf:aa91:: ?

 

Best regards,

Tony.

Link to comment
Share on other sites

Applying an idea from next topic (No source address found, cannot proceed), I tried to snip away as little as possible (to paste it back in a user comment). I kept the "Delivered-To" line, the "X-Received" line, and removed the two headers in-between ("Received" and "Google-Smtp-Source"). Then it parsed.

Best regards,

Tony.

Link to comment
Share on other sites

P.S. Looks to me like Google is adding IPv6 mailhosts by the boatload and SC is having a hard time keeping up.

Best regards, Tony.

Link to comment
Share on other sites

15 minutes ago, A.J.Mechelynck said:

Applying an idea from next topic (No source address found, cannot proceed), I tried to snip away as little as possible (to paste it back in a user comment). I kept the "Delivered-To" line, the "X-Received" line, and removed the two headers in-between ("Received" and "Google-Smtp-Source"). Then it parsed.

Best regards,

Tony.

P.P.S. https://www.spamcop.net/sc?id=z6464487608z235a710f4a3681c5c236b5073b8b8ab0z

Link to comment
Share on other sites

5 minutes ago, Lking said:

Have you read the related threads? Do a search for gmail to find the 2-3 resent thread.

No luck looking for both "gmail" and "resent" in the subject. Do you mean resend (send again) or recent (latest)? Or do you have a topic URL?

Link to comment
Share on other sites

33 minutes ago, Lking said:

Searching for "gmail" without the ""

SpamCop cannot find source IP it is long put it does discuss an issue with gmail and forged IPv6 lines in email headers

That thread I read, though maybe not post by post from A to Z: that's where I got the idea of snipping away the 2 headers between "Delivered-To" and "X-Received" exclusive (see earlier up).

Recently there was a problem with IPv6 (or, it seems, the IPv6 side of 6to4) X-Received lines (see "IPv6 still unsupported?"

) but that went away after some time. I hope (and I believe) that SC programmers will fix the present problem like they did the earlier one.

Link to comment
Share on other sites

3 hours ago, A.J.Mechelynck said:

but that went away after some time. I hope (and I believe) that SC programmers will fix the present problem like they did the earlier one.

After months I  just now get another Gmail with spoof headers?

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

Remove/cut out spoofed headers parses fine, this spamware must be getting passed on? pasted cutout spoof in comments

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

Link to comment
Share on other sites

The 2002:a17:90a:b016:0:0:0:0 IPv6 address in your top Received line is a 6to4 address for 10.23.9.10, and that's what SC converts it to when I paste the naked IPv6 address into the reporting page. Now IIRC all addresses in 10.0.0.0/8 are non-routable so I suppose that that Received line is for an internal handoff and IMHO it should be skipped by the parser as "internal handoff or trivial forgery". Similarly for all addresses in 2002:a00::/24 which are in the same category.

Best regards,

Tony.

Link to comment
Share on other sites

6 hours ago, A.J.Mechelynck said:

trivial forgery". Similarly for all addresses in 2002:a00::/24 which are in the same category.

The first genuine line is

ARC-Authentication-Results: i=1; mx.google.com;

 

Everything above that is spoofed by spamware. I just cut then past into notes headed "cut spoofed headers below" eventually I will get list washed

Link to comment
Share on other sites

I'm not convinced that it's spoofed by spamware: remember, routers add their Received-line before anything already present, so a topmost Received-line could only have been spoofed by spamware if said spamware were intercepting incoming mail at the client sites (i.e. both mine and yours), or outgoing mail being sent from gmail to its clients.

IMHO that line with some address in the IPv6 2002:a00::/24 range, just like the equivalent Received-lines in the IPv4 10.0.0.0/8 range, means that the message was passed from one router to another at Google's.

Experiment shows that removing only the Received line with 2002:axx: etc. (including any continuation lines) makes the parse succeed. Then I paste it back as part of the "user comments".

Link to comment
Share on other sites

You might be right as to not being spoofed?

Parsing my Gmail non-spam emails never get spoofed headers. These headers are only from my spam folder?

This makes me believe these headers are in-fact spoofed!

Link to comment
Share on other sites

Do your non-spam email have a Received line at that place (i.e. 2nd header from top)? If they do, I would think that line isn't spoofed.

— Oh, and BTW, the notification email I got about your latest post had the following line there (2nd header, topmost Received-line, imediately below the "Delivered-To" line):

Received: by 2002:adf:aa91:0:0:0:0:0 with SMTP id h17-v6csp2888495wrc;
        Sat, 12 May 2018 18:21:24 -0700 (PDT)

So, what do you think? Are SC forum notification email messages "spoofed" with a spammy Received-line? I wouldn't think so.

Link to comment
Share on other sites

7 hours ago, A.J.Mechelynck said:

Do your non-spam email have a Received line at that place (i.e. 2nd header from top)? If they do, I would think that line isn't spoofed.

— Oh, and BTW, the notification email I got about your latest post had the following line there (2nd header, topmost Received-line, imediately below the "Delivered-To" line):


Received: by 2002:adf:aa91:0:0:0:0:0 with SMTP id h17-v6csp2888495wrc;
        Sat, 12 May 2018 18:21:24 -0700 (PDT)

So, what do you think? Are SC forum notification email messages "spoofed" with a spammy Received-line? I wouldn't think so.

Would like a track on that. But you are perhaps correct ?

OK what I saw as spoofed headers is Gmail stamping "Authentication" markings above email header received lines below is reply from a Gmail support group

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

Link to comment
Share on other sites

1 hour ago, petzl said:

Would like a track on that. But you are perhaps correct ?

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

for the notification about your newer post quoted above. Or you can see the full message (headers & body) at http://users.skynet.be/antoine.mechelynck/other/SC_notification.eml

N.B. I'm moving tomorrow, and the phone line will only be reconnected Thursday at my new address, so I may be AFK for ½ week starting tomorrow morning.

Best regards, Tony.

Link to comment
Share on other sites

It is part of Gmail spam sorting which they are stamping above the real headers. Seems they have a database validating email addresses which appear above headers. Only got this from a email sent from a Gmail user group today

Link to comment
Share on other sites

Hm, it's true Gmail diagnoses these notifications as "spam" (and sends them to my spam webmail folder), but that 2002:axx: etc. header which throws SC off-balance comes from Gmail, not from a spammer. So I hope that (when they get around to it) the SC programmer(s) will have the parser skip that header for an "internal, non routable" IP address.

Best regards, Tony.

Link to comment
Share on other sites

11 hours ago, jnelken said:

What can be done to help Spamcop in this case?

The first genuine line is

ARC-Authentication-Results: i=1; mx.google.com;

 

Everything above that is spoofed by Gmail authentication (spam from ham). I just cut then past into notes headed "cut authentication headers below" past them in notes after parse!

 
Link to comment
Share on other sites

Hello, as of lately, every single spam message I get contains the line:

Received: by 2002:ab0:848:0:0:0:0:0 with SMTP id some-id-code;

This, as mentioned before in this and other forum threads is the IPv6 2002:a00/24 equivalent of a IPv4 10.0.0.0/8 network (private network)
A non-spam email contains the line:

Received: by 2002:ab0:848:0:0:0:0:0 with SMTP id some-other-id-code;

These are the Google (gmail) internal IPv6 mail servers.
Spamcop logically and understandably responds by saying "I refuse to bother IANA"

The problem is, that if the header contained the non-IPv6 google internal mail server line:

Received: by 10.236.180.19 with SMTP id some-id-code

the spam message is parsed correctly and the spammer IP received line pulled and reported and the spoofed received lines also detected correctly as spoofed lines.

Today, it seems that no spammer has to worry to get their proxies pulled since SpamCop cannot parse the IPv6 private addresses like it does with the IPv4 Private addresses.

It would be really nice if someone at the Cisco SpamCop division could look into this and fix it. I'm sure at Cisco they have knowledgeable developers who understand the IPv6 address space and email headers, and can fix the current SpamCop code to work with IPv6 to work along IPv4. Otherwise: Hello, Julian, sorry for bothering you, but could you add a line or two of code to fix this for us please?

IPv6 example:

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

Received:  by 2002:ab0:848:0:0:0:0:0 with SMTP id b8-v6csp616397uaf; Sun, 13 May 2018 06:31:21 -0700 (PDT)
no from
host 2002:ab0:848:0:0:0:0:0 (getting name) no name
Possible spammer: 2002:ab0:848:0:0:0:0:0
Received line accepted

Received:  from cy105.mta.exacttarget.com (cy105.mta.exacttarget.com. [136.147.181.105]) by mx.google.com with ESMTPS id r185-v6si4924627ita.0.2018.05.13.06.31.21 for <x> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 May 2018 06:31:21 -0700 (PDT)
host 136.147.181.105 (getting name) = cy105.mta.exacttarget.com.
cy105.mta.exacttarget.com is 136.147.181.105
2002:ab0:848:0:0:0:0:0 not listed in cbl.abuseat.org
2002:ab0:848:0:0:0:0:0 not listed in dnsbl.sorbs.net
2002:ab0:848:0:0:0:0:0 is not an MX for mx.google.com
Possible spammer: 136.147.181.105
136.147.181.105 is not an MX for cy105.mta.exacttarget.com.
Host cy105.mta.exacttarget.com. (checking ip) = 136.147.181.105
Host mx.google.com (checking ip) IP not found ; mx.google.com discarded as fake.
Display data:
"whois 10.176.8.72@whois.arin.net" (Getting contact from whois.arin.net )

Where does SpamCop even find that 10.176.8.72 address in the header?

SpamCop needs to update their code to work properly with IPv6. There is no way around it.

 

Link to comment
Share on other sites

20 hours ago, RobiBue said:

SpamCop needs to update their code to work properly with IPv6. There is no way around it.

Gmail are getting too smart for their own good! They are stamping their version of ARC rubbish above the real headers! which start at

ARC-Authentication-Results: i=1; mx.google.com;

Just copy and past into submission include that line SpamCop parses fine . Put what you cut out in notes
https://www.spamcop.net/sc?id=z6465051289zf879ca5b6e1b837b8e57756639b0bdc2z

Link to comment
Share on other sites

4 hours ago, petzl said:

Gmail are getting too smart for their own good! They are stamping their version of ARC rubbish above the real headers! which start at


ARC-Authentication-Results: i=1; mx.google.com;

Just copy and past into submission include that line SpamCop parses fine . Put what you cut out in notes
https://www.spamcop.net/sc?id=z6465051289zf879ca5b6e1b837b8e57756639b0bdc2z

Therein lies the problem :(

I get about 20-30 spam/hour depending on the weather (well, not really on the weather, but it sure seems like it) so I wrote a little apps-scri_pt that pulls all my spam every hour and submits them as attachments to SC for reporting.

To manually cut out the topmost Received: line (the SC parser works fine for me if I leave the rest of the ARC lines in the header) takes too much time, and to then re-insert it in the notes section, even more... I am absolutely sure, that if someone in the  development division pays attention to these latest IPv6 developments, and appends some corrective lines to the parser, SpamCop would again outshine the spammers with its glory.

As you can see, it's not really an option for me. I could remove the topmost Received: line in the scri_pt, but that would again defeat the purpose as now I would be "spoofing" the headers of my submissions..

Google is not spoofing anything. ARC is, in my humble opinion, a pretty nice development, albeit not foolproof if there is a fake mail server in the chain... ?

the topmost Received: line (not spoofed, but since google seems to have moved their mail servers into IPv6 spaces, filled with the IPv6 address of the local server) is the only one that SC seems to choke on since it's a private IPv6 network and SC does not seem to parse private IPv6 addresses the same way as private IPv4 addresses.

As I have already mentioned before, it would be nice if SpamCop would or could update their codebase to cover these "new" developments in the IPv6 addressing space.

Link to comment
Share on other sites

6 hours ago, RobiBue said:

Google is not spoofing anything. ARC is, in my humble opinion, a pretty nice development, albeit not foolproof if there is a fake mail server in the chain... ?

the topmost Received: line (not spoofed, but since google seems to have moved their mail servers into IPv6 spaces, filled with the IPv6 address of the local server) is the only one that SC seems to choke on since it's a private IPv6 network and SC does not seem to parse private IPv6 addresses the same way as private IPv4 addresses.

As I have already mentioned before, it would be nice if SpamCop would or could update their codebase to cover these "new" developments in the IPv6 addressing space.

SpamCop has no trouble with IPv6 It is having trouble Gmails spam sorting ARC "headers" which contain a non-routable IPV6 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...