Jump to content

Reporting Issue's reason Fake Headers


albert2

Recommended Posts

Hello,

Since a while i have problems reporting spam while before i never had issue's. On my side nothing has changed so it's certainly not a mail host issue.

This are the exact errors spamcop gives me:

 

No unique hostname found for source: xxxxxxx

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.

Nothing to do.

I first ignored the spams & did no efforts to report them but now every spam i received get bounced for this reason & spams send to me grow in numbers. So i needed to take action and looked for above errors on this forum. I found a solution and with it i can report again but doing this for every spam is a time consuming workaround, besides that there is each time the risk i forget to mungle out my own email address & face retributions from the spammer if he receives a copy of the report.

This is the solution:

Seem a number of variants copy from including this line down

ARC-Authentication-Results: i=1; mx.google.com;
       spf=pass (google.com: domain of www.@vanilla.ocn.ne.jp designates 153.149.236.39 as permitted sender) 

Then copy and paste the above bit in notes' After SpamCop has parsed it.

 

I hope Spamcop could do an effort in including a process that automates this on their side so users can simply copy paste their mail source, in this case the mingling would also be automatically performed by spamcop as it was done before.

Thanks for looking into this & providing a permanent solution.

 

Albert

 

PS if you require samples please respond to me & i will provide a few

 

Link to comment
Share on other sites

presently gmail headers 2nd line needs deleting before submitting. Trouble is ISP's need FULL headers as evidence so past deleted line in comments

Delivered-To: x
Received: by 2002:a9d:21b7:0:0:0:0:0 with SMTP id s52-v6csp2028874otb; DELETE
Link to comment
Share on other sites

Thanks Petzl,

Seems you have pinpointed the problem to the second header line.

Do you or someone else knows what exactly is caused by this line & what this line tells ?

Again maybe Spamcop systems can be altered to remove or ignore this line automatically when present so users won't need to take care of it anymore for each mail.

If this line is specific to mailboxes from gmail, maybe spamcop could contact google and ask for a solution.

 

Albert

Link to comment
Share on other sites

1 hour ago, albert2 said:

Thanks Petzl,

Seems you have pinpointed the problem to the second header line.

Do you or someone else knows what exactly is caused by this line & what this line tells ?

Again maybe Spamcop systems can be altered to remove or ignore this line automatically when present so users won't need to take care of it anymore for each mail.

If this line is specific to mailboxes from gmail, maybe spamcop could contact google and ask for a solution.

 

Albert

The line tells that the message was received by the mail server at IPv6 address 2002:a9d:21b7:0:0:0:0:0 which is actually a 6to4 address translated from the IPv4 address 10.157.33.183.

In short, the mail server at google that received the message before displaying it to you in your gmail account has the IP address 10.157.33.183.

I received the following message from SpamCop:

<quote>
Gmail has broken their headers, not showing who received the mail and
using IP addresses that do not resolve.

Google has promised to fix the issue but have not provided an ETA of a
fix.  We looked at programming around it but that option was rejected by
our CERT board as it would have opened a security hole in our system.

We can just sit and wait for Gmail.
</quote>

 


 
Link to comment
Share on other sites

I really think this is annoying. I can't automate my spam reporting anymore because now i need to do everything manually now for each spam mail.

This process includes:

In my mail app:

Open each mail

In the menu select to view the source

Copy the source

In my browser:

Paste the source

Copy the line that breaks reporting

Delete the Line """""""""""

After Process spam

Paste above line in comments

 

This has to be done for every Mail, i think its best to create a work around the problem at Spamcops side until Google resolves this ( if they ever will)

Link to comment
Share on other sites

  • 4 weeks later...

I got this reply at the Gmail Forums ;

 

I suggest that you complain to Spamcop if they are not accepting legitimate email headers.  

 

So they are saying it's a legitimate header.

It would be best, like i suggested before, that the spamcop processing scri_pt looks for these lines which are always the second  (& third) line of the header & ignore them for processing but leave them otherwise untouched. 

 

Link to comment
Share on other sites

Yeah, and according to an email I received from SC they won’t do anything because they seem to think they might open a security hole if they do that...

 

btw, could you point me with a link to the gmail forum you mention?

Link to comment
Share on other sites

https://groups.google.com/a/googleproductforums.com/d/msgid/gmail/adfc2d75-34f4-47cd-8de5-2b47cbc97675%40googleproductforums.com?utm_medium=email&amp;utm_source=footer

 

This is the post i made at Google Gmail forum, as a user suggested i also send feedback to Google Directly. I hope they take it a bit more seriously.

However i think we need to hope Spamcop itself takes it seriously &  come with a solution for their users. If they think it might open a security hole if they do that... , they might consider i do it manually now for each spam mail i report & if it opens a security hole then i open it manually & uncontrolled now. While if they come with a solution they can mark each spam they let trough tile ignoring these lines & use this mark to enable  them to use different security rules for these spam reports or whatever they think is needed to close  a security hole.

Link to comment
Share on other sites

I doubt if Google are using legit email headers. Other email providers using ARC are parsed easily by SpamCop

Same for Google searches often you get  "this site can't be reached" caused by Google changing security certification. Thought morons were only in politics? 

Link to comment
Share on other sites

6 hours ago, petzl said:

I doubt if Google are using legit email headers. Other email providers using ARC are parsed easily by SpamCop

it's not the ARC headers, it's the Received: header containing the IPv6 address in 6to4 form which points to a private IPv4 address [rfc 1918]

and no, the Received header with that type of IPv6 address (private IPv4 in 6to4 form) is not allowed, therefore not legit. [rfc 3056] section 2:
 

Quote

 

2. IPv6 Prefix Allocation

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

 

 

Link to comment
Share on other sites

10 hours ago, RobiBue said:

it's not the ARC headers, it's the Received: header containing the IPv6 address in 6to4 form which points to a private IPv4 address [rfc 1918]

and no, the Received header with that type of IPv6 address (private IPv4 in 6to4 form) is not allowed, therefore not legit. [rfc 3056] section 2:
 

 

Yes were told by Google months ago they would fix them but??

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...