Jump to content


  • Posts

  • Joined

  • Last visited

ewv's Achievements


Member (2/6)



  1. What is a practical reporting address for cloudflare.com? My reports to abuse@cloudflare.com, the standard spamcop address, are ignored. In particular the infamous "Eric Jones" talkwithlead.com web formmail spammer has been hosted by cloudflare for years despite systematic reports several times a month. The spam routinely breaks through captcha deterrents and is recently connecting with a blank IP address to prevent reporting to the hosts it has always cycled through to avoid blocking. This spam is also found on web forums internationally. It has rotated among several different spamvertized domain names, including talkwithwebvisitor.com, talkwithwebvisitorS.com, talkwithwebcustomer, talkwithcustomer.com, and talkwithwebtraffic.com. It is a big spam operation which I once traced to the Trade World Corporation in Canada, with an 'F' Better Business Bureau rating and numerous complaints of credit card fraud. Why would an organization like Cloudflare continue to ignore spam reports about hosting an operation like this?
  2. I will try the spamcop link but aside from the missing n's in the headers of the form x-inbound-n.inbound.mailchannels.net headers, the parser has also been hanging on other kinds of mailchannels headers. Also for one spamcop account the mailchannels entry in Mailhosts periodically disappears entirely, and for another spamcop account mailchannels cannot be added to Mailhosts at all.
  3. What do I have to do to get this fixed? For one spamcop account I can't add mailchannels to Mailhosts at all. "Mailchannels" as the standard name reverts to non-mailchannels servers at dreamhost. (Dreamhost is using mailchannels to intercept and scan mail.) For my other spamcop account mailchannels can be added to Mailhosts but periodically disappears and has to be added again. Even while mailchannels is registered with Mailhosts it still does not work because of additional servers with ambiguous headers inserted by mailchannels into incoming email that prevents further parsing to the spam source. Ken Simpson, from mailchannels, above says they are inserting internal servers with IPs like but the spamcop parser hangs at ambiguous IPs like https://www.spamcop.net/sc?id=z6691078615zd435ce8b004b579b41b019fa65a5d50ez 3: Received: from inbound-trex-2 (100-96-24-78.inbound-trex.inbound.svc.cluster.local []) by postfix-inbound-2.inbound.mailchannels.net (Postfix) with ESMTP id 0F77480112 for <x>; Mon, 16 Nov 2020 10:20:43 +0000 (UTC) No unique hostname found for source: Meanwhile, after four days, dreamhost support is not responding. What does it take to get this fixed?
  4. All of my incoming mail at dreamhost now has these mailchannels headers inserted, which blocks spamcop parsing to find the source. Submitting any incoming mail to the spamcop parser results in hanging on mailchannels Received headers, and the parser "finds" networking@carbon60.com (mailchannels) as the reporting address. I have tested this on random non-spam incoming mail (which is not reported). The mailchannels headers make finding and reporting spam impossible, except that mailchannels takes credit for the spam and its headers are in fact responsible for protecting spammers from being reported. Dreamhost also funnels all outgoing mail to mailchannels to intercept and scan. Aside from the privacy problem (echoing Google mail surveillance), this results in occasional, to an unknown degree, random outgoing mail being disparaged as "junk" in mailchannels headers, which in turn sometimes causes the perfectly valid mail to bounce or be diverted into a receiver's spam folder. But that is a different problem than the one with incoming mail and the disruption of spamcop parsing, which is a new problem. I don't know if this mess is caused by dreamhost, mailchannels, the spamcop mailhosts system, or some combination. I have reported it to dreamhost but am still waiting; they are very slow and the first rounds of their eventual 'responses' are usually oblivious to the problem reported.
  5. Another example: https://www.spamcop.net/sc?id=z6690587707z0afbb907bf385a3a5839c4d16a400f48z This has not been reported so as to not duplicate.
  6. Adding mailchannels to mailhosts was confirmed in mailhosts, with no change in parsing behavior. Parsing submissions have been only after Mailhosts was updated. Mailchannels later disappeared from mailhosts entirely and could not be added back: Selecting the "standard name" mailchannels resulted in the options to select only dreamhost servers (the base mail host already registered long ago). Hours later I could then add mailchannels servers again, but still with the same aberrant behavior blocking parsing for mail hosts preceding mailchannels in the Receive headers. For a second spamcop account, used only for quickreporting, I have not been able to add mailchannels to the mailhosts at all, with the only options being the dreamhost mail servers after specifying the standard name 'mailchannels'.
  7. mailhosts only allows adding mx1.mailchannels.net. (pri 0) and mx2.mailchannels.net resulting in: inbound.mailchannels.net postfix-inbound-0.inbound.mailchannels.net postfix-inbound-3.inbound.mailchannels.net postfix-inbound-4.inbound.mailchannels.net postfix-inbound-5.inbound.mailchannels.net postfix-inbound-6.inbound.mailchannels.net postfix-inbound-7.inbound.mailchannels.net postfix-inbound-11.inbound.mailchannels.net Missing from that list is (at least)#2: postfix-inbound-2.inbound.mailchannels.net and more fundamentally inbound-splitter.mailchannels.net resulting in spamcop hanging before getting to the spam source, for example: 2: Received: from inbound-trex-4 (100-101-84-158.inbound-trex.inbound.svc.cluster.local []) by postfix-inbound-4.inbound.mailchannels.net (Postfix) with ESMTP id AAE1520251 for <x>; Thu, 12 Nov 2020 10:19:05 +0000 (UTC) No unique hostname found for source: Possible forgery. Supposed receiving system not associated with any of your mailhosts Will not trust this Received line. for headers: ... Received: from inbound-trex-4 (100-101-84-158.inbound-trex.inbound.svc.cluster.local []) by postfix-inbound-4.inbound.mailchannels.net (Postfix) with ESMTP id AAE1520251 for <x>; Thu, 12 Nov 2020 10:19:05 +0000 (UTC) Received: from inbound-trex-0 (100-96-26-96.inbound-trex.inbound.svc.cluster.local []) by postfix-inbound-splitter-0.localdomain (Postfix) with ESMTP id EBBED20032; Thu, 12 Nov 2020 10:19:00 +0000 (UTC) Received: from p110239-ipoefx.ipoe.ocn.ne.jp (p110239-ipoefx.ipoe.ocn.ne.jp []) by (trex/5.18.10); Thu, 12 Nov 2020 10:19:00 +0000 p110239-ipoefx.ipoe.ocn.ne.jp escapes being reported.
  8. I hadn't subscribed in a long time, but this is what I just found posted at 9:22 EST::
  9. Don't they monitor the functioning of their own system? There has been no public recognition that they even know there has been a fatal problem for over 16 hours. Is there anything on the newsgroups?
  10. spam submissions have been failing for almost 10 hours now. Isn't anyone there monitoring what is happening?
  11. This is the Postfix error I reported to Don last night. No response yet. <quick.*********[at]spam.spamcop.net>: host vmx1.spamcop.net[] said: 554 #5.3.0 Server Error (in reply to end of DATA command) It started yesterday.
  12. This bug in the parser even with common domains like xx.geocities.com is still there and seems to be getting worse. Entering a geocities subdomain into a separate window results in an immediate response while a full spam submitted still results in inconsistent failures. I have seen the same spam, including geocities spam, on different refreshes result in: - no links found - links found and simply dropped with no error message - the first link properly identified with the rest dropped Normally, geocities links in spam are simply dropped, with even dozens of refreshes failing to resolve them. In the past, refreshes worked more often. At least one spammer is exploiting this with repeated use of geocities links. Some now include several such links. The inconsistent behavior and poor error messages detracts from the credibility of all url parsing -- one never knows if all the links have been found, if "no links found" is believable, or if the reporting addresses are complete. This bug has been well known for a very long time. It and the fact that it has evidently been ignored are extremely frustrating and annoying, it has caused much wasted time, and spam reporting is being delayed or dropped because of it.
  • Create New...