Jump to content

RobiBue

Membera
  • Content Count

    252
  • Joined

  • Last visited

Everything posted by RobiBue

  1. I want to expand on my theory about the mis-configured server... Ok, the topmost (last) Received header Received: from st11p00im-smtpin002.mac.com ([17.172.80.20]) by ms55025.mac.com (Oracle Communications Messaging Server 8.0.1.3.20170906 64bit (built Sep 6 2017)) with ESMTP id <0PD000KG3DK8YJD0@ms55025.mac.com> for x; Sun, 05 Aug 2018 22:09:44 +0000 (GMT) The mail server "ms55025.mac.com" receives the message from server "st11p00im-smtpin002.mac.com" and identifies the IP address [17.172.80.20] which in turn was received in the previous Received header (below) by server "st11p00im-smtpin002.me.com" (notice the coincidental same name, but me.com instead of mac.com domain -- both apple domains nonetheless) from the Russian server "kknd1.ru" and identified to be IP address [84.22.137.8] (rDNS identifies the address as kknd1.ru) Received: from kknd1.ru (kknd1.ru [84.22.137.8]) by st11p00im-smtpin002.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) with ESMTP id <0PD0005G5DK5U970@st11p00im-smtpin002.me.com> for x (ORCPT x); Sun, 05 Aug 2018 Of course, sadly enough, at the moment, if I ping either me or mac servers, I get nil... but the Russian server is there...
  2. I actually believe, Apple should look into the configuration of their SMTP server named st11p00im-smtpin002. When it receives the email, it places the host name st11p00im-smtpin002.me.com into the Received: header as "received by", then, when it sends the message on its merry way, the same server is now known as st11p00im-smtpin002.mac.com. me.com is an apple domain, just like the mac.com is. My take is, that some admin forgot to change the domain name on the server... If I were you, I'd get in touch with Apple. They'd more than likely be willing to fix their server mis-configuration...
  3. Ok, that's not it, but then again, it is... apparently Google's internal mailing is creating havoc. As you can see, the bottom-most (aka first) Received: header is Received: by 2002:a17:90a:3aac:0:0:0:0 with HTTP; Thu, 2 Aug 2018 07:36:54 -0700 (PDT) There is no from in the received line. The by is one of those private networks from IPv4 in 6to4 format, which SpamCop correctly identifies as 10.23.9.10 but, as I mentioned earlier, since it's a 6to4 address, it can't cope. and no, you won't be able to send a report for this one via SpamCop. This one needs "manual" intervention... https://www.google.com/contact/ Sorry.
  4. Well, I guess it wouldn't (or couldn't) hurt if SpamCop users/reporters with gmail accounts send their feedback... I found the feedback link in gmail by clicking on the settings gear in the "new" gmail (or classic/standard view). Can't find it in the basic HTML view though.
  5. With Gmail, SpamCop has been having problems lately, because their mail system adds their internal IP addresses for their mail hosts as so called "6to4" addresses in IPv6 form, and that breaks SpamCop. SpamCop has no wish to check if the IPv6 address would be a private address (10/8) and handle it as a private address. Google is misusing the 6to4 format not conforming to RFC 3056 section 2 and reporting their private mail host as IPv6 in the 6to4 format. Google needs to fix that, but regardless, SpamCop needs to be able to cope with it and sadly it doesn't. If the topmost Received: header starts with 2002:axx:xxxx:0:0:0:0:0:0 then manually parenthesize that address and place mx.google.com in front: Received: by mx.google.com (2002:axx:xxxx:0:0:0:0:0:0) ............ and it should work... that is, if that is your problem, but without the TRACKING URL it's hard to diagnose the problem ...
  6. I received this from SpamCop: <quote> Google has promised to fix the issue but have not provided an ETA of a fix. We [SpamCop] 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>
  7. Ok, just reread the thread and found the following Yeah, Gmail adds their Received: header with a 6to4 IPv6 address from a private 10.0.0.0/8 network which according to RFC 3056 §2 is not allowed, but them being google, do it anyway regardless of the consequences. This, in my opinion, is something that google shouldn’t have implemented and should fix. SpamCop should be able to cope with the 6to4 address and see it as an internal private address just as it would be if it was given the original 10.nnn.nnn.nnn address. Currently it seems that neither SC nor google is about to budge. All we can do, is either delete the 2nd line Received: header with its faulty IPv6 address and paste it as a comment for the receiving abuse recipients for completeness, or put the IPv6 address in parentheses and place its equivalent IPv4 address in front. an example of that 2nd line: Received: by 10.176.75.22 (2002:ab0:4b16:0:0:0:0:0) with SMTP id h22-v6csp5358367uaf; Tue, 31 Jul 2018 11:25:32 -0700 (PDT)
  8. does your spam by any chance arrive to a gmail account? (or is delivered by gmail)
  9. RobiBue

    Reporting Issue's reason Fake Headers

    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:
  10. RobiBue

    Reporting Issue's reason Fake Headers

    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?
  11. As is the to: header... I believe the “munging” of the List-Unsubscribe: header is a side effect of a regex command which is misinterpreting the missing space after the colon as part of hiding a “valid” email address... I believe Cisco/talos need to look into that, as it breaks the parser.
  12. I see the problem that you're having. It isn't what I thought, but nonetheless bad. The problem is, that the sender's mailing program does not add a space right after the colon (:) ending the header type. All the messages I have seen have that extra space after the colon. It is not required by RFC standards, but it seems to hurt SC. I tried your message, and if you insert that space after the colon, it works. https://www.spamcop.net/sc?id=z6475844094zd9d6160d20740d76a1fb1f9ae1dbcbb8z (I added a space after every one that didn't have one, but I believe that if you only do it with the List-Unsubscribe: header, it should work too.
  13. I have those too, but it works for me. do you have a tracking URL from one of your reports? it looks like this: https://www.spamcop.net/sc?id=z6475791625zff16eb81c4a6964305d62abdc7cd4f40z and is located at the top of the page before you send the report (btw: the link above also has an example with your list-unsubscribe which here works without problems)
  14. Hello Goodnerd, the problem you're having is unfortunately known to spamcop, and is a problem for us "reporting spam". Gmail is one of the biggest causes of this problem, although I have heard that Yahoo! is doing the same. The reason is, that theses email providers have been inserting a 6to4 IPv6 address for their Received: headers. These 6to4 addresses begin with "2002:a". you can submit the spam by changing the following in the topmost Received: line: if you have Received: by 2002:aa7:d9c9:0:0:0:0:0 with SMTP id h22-v6csp6451088uaf; Tue, 24 Jul 2018 05:25:31 -0700 (PDT) ^^^^^^^^^^^^^^^^^^^^^^^ 6to4 IPv6 address is a problem place the IPv6 address in parentheses and add the equivalent 10.167.217.201 in front like this: Received: by 10.167.217.201 (2002:aa7:d9c9:0:0:0:0:0) with SMTP id h22-v6csp6451088uaf; Tue, 24 Jul 2018 05:25:31 -0700 (PDT) ^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^ add parenthesized That should enable you to report your spam
  15. RobiBue

    PARCO Innovation compagny blacklist

    Ouch! shoot your own foot
  16. RobiBue

    PARCO Innovation compagny blacklist

    it is possible that bouyguestelecom.com "maintains" their own block/black-list... I would ask their admin how it is maintained, and why they claim that your address is listed in SpamCop if it clearly is not.
  17. RobiBue

    Spamcop server

    Here, a SpamCop admin should be able to help you. Since you do not report spam via “super sekret email” that SpamCop created for you when you signed up, someone else is sending spam reports to that email address. It’s the address that you find where you submit spam after you login. Forward your spam to: submit.A-long-funny-looking-address@spam.spamcop.net Or maybe some spammer is sending spam to that address and SpamCop thinks it’s a report but doesn’t find the spam inside...
  18. https://www.spamcop.net/sc?action=rcache;ip=162.252.58.155 netrouting.com claims that it works. Please reset.
  19. RobiBue

    Spamcop server

    You say you haven’t reported spam in a long time, yet you receive those messages every 2nd day... Did you change jobs and left your reporting email saved at your last place? Someone who works there now might be reporting the spam to that address. The email address that was in the original message might give a clue who received and submitted the spam. There might be a link with the reporting ID. It is possible as well, that the reporting entity is receiving the spam through a google account and SpamCop is choking on the 6to4 IPv6 address in the Received: line.
  20. RobiBue

    Reporting to Spammer?

    Yeah, that would be them themselves. IOW you'd be sending the report straight to the spammer.... unfortunately, they get their addresses straight from IANA/ARIN At least that's what I see, unless someone has more insight...
  21. RobiBue

    Reporting to Spammer?

    It seems to me that superlative.com has a large IP address space (https://whois.arin.net/rest/net/NET-74-118-120-0-1/pft?s=74.118.120.0.) That shows a /22 range with 1024 addresses (well, minus 2) they could be the spammer host (or not). there doesn't seem to be an upstream they are subletting from... at least I couldn't find one... This link (https://ipinfo.io/74.118.123.4) tells me a bit of a different story, but the data could be old...
  22. RobiBue

    Outlook "Beta"

    I see what you mean. The only way I can see it done involves some extra work manually, and I believe that is out of the question. it is for me anyway. In the message, click on the down arrow and select "view message source". here's where the manual work starts: copy headers and message source (in the same window) by selecting everything in the new text-box and paste it into an editor. The whole thing is one line, so you'll have to insert a CR or CR/NL after every header part. Then you'll be able to submit it to spamcop. unless you have some programming experience and create an add-in for outlook with visual Studio... https://docs.microsoft.com/en-us/visualstudio/vsto/walkthrough-creating-your-first-vsto-add-in-for-outlook
  23. RobiBue

    Outlook "Beta"

    could this link help? https://www.lifewire.com/view-complete-message-source-outlook-1173713
  24. see below and that's why I like to use the clue by four through the abuse desks and Spamcop is a very helpful tool (if they eventually would get through their heads that they need to fix the IPv6 part where it pertains to 6to4 addresses...)
  25. I don't even go to those pages. 3 main reasons: I don't care, it's spam. The links could contain viruses. The links are most likely coded so that the spammer knows that I received the spam, and by visiting it, he can prove to the spamvertised "client" that he should get paid for his efforts. And a last, but not least reason: I didn't sign up for it, why should I unsubscribe anyway. That's what the clue by four is for... if the provider's abuse desk gets flooded with abuse reports, eventually he'll get put in place. I believe that my email address ended up in his/their list due to one or more of the data breaches of late... IOW just another list where they can send their junk... I have also been getting lots of unsubscribe confirmation requests which I handle just like spam, as I didn't unsubscribe, and if I did, why should I confirm that i am unsubscribing... take another clue by four, spammer, I don't want your junk... abuse desk will hopefully clue you in
×