albert2 Posted June 22, 2018 Share Posted June 22, 2018 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 More sharing options...
petzl Posted June 23, 2018 Share Posted June 23, 2018 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 More sharing options...
albert2 Posted June 23, 2018 Author Share Posted June 23, 2018 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 More sharing options...
RobiBue Posted June 23, 2018 Share Posted June 23, 2018 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 More sharing options...
albert2 Posted June 24, 2018 Author Share Posted June 24, 2018 Lets hope they come with a solution quickly then ! Link to comment Share on other sites More sharing options...
albert2 Posted June 30, 2018 Author Share Posted June 30, 2018 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 More sharing options...
albert2 Posted July 29, 2018 Author Share Posted July 29, 2018 I got this reply at the Gmail Forums ; I suggest that you complain to Spamcop if they are not accepting legitimate email headers. SpamCop.net - SpamCop FAQ: How can I contact a SpamCop ... 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 More sharing options...
RobiBue Posted July 29, 2018 Share Posted July 29, 2018 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 More sharing options...
albert2 Posted July 29, 2018 Author Share Posted July 29, 2018 https://groups.google.com/a/googleproductforums.com/d/msgid/gmail/adfc2d75-34f4-47cd-8de5-2b47cbc97675%40googleproductforums.com?utm_medium=email&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 More sharing options...
petzl Posted July 30, 2018 Share Posted July 30, 2018 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 More sharing options...
RobiBue Posted July 30, 2018 Share Posted July 30, 2018 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 More sharing options...
petzl Posted July 30, 2018 Share Posted July 30, 2018 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 More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.