Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by ewv

  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.
  13. Does that mean you don't think that spam should be reported? This isn't a game; they are criminals. The laws against them are inadequate, so for now all we can do is report their activities to black list their sources or get their ISP's to shut them down
  14. Treat the aliases invented by the spammers as spamtraps. Explicitly alias them into a new account explicitly set up for spam reporting. For the aliases you are sure would only be used by spammers, set up a procmail scri_pt on the server to automatically QuickReport them to spamcop. You can archive them on the server, but you don't have to even see them in your mail client. Then let them spam themselves into oblivion. You can elaborate on this in different ways with white lists, automatic forwarding of subcategories to spamcop for confirmed reporting, etc.
  15. I encountered the same problem this afternoon. One particular spam that had been forwarded to spamcop hung in the parser repeatedly, ending with the same sigalarm error message. When I pasted it into the spamcop window, however, the parser did not delay or hang, but gave the message that the spammer url could not be resolved. I pasted the domain name alone into spamcop and also did a traceroute on it, confirming that it was in fact unresolvable. I forwarded the spamcop id to Don.
  16. ewv: wazoo: spam is reported using the preferences parameters of the browser login, not the account under which it is forwarded to spamcop, so there is a conflation in the identify of the reporter.
  17. StevenUnderwood wrote at post #5: What defines a unique "reporter"? The spamcop account under which the spam is forwarded or the spamcop login under which the report is confirmed or something else?
  18. The reporting addresses of the type cited are working again. Whatever was meant by the phrase "your spam construction", I had long ago submitted at least one example of the link pattern in the example I cited, as well as other patterns, per http://forum.spamcop.net/forums/index.php?showtopic=1549. I routinely see a couple of recurring patterns (with variations?) for which the parser does not find the links. (The example I cited still doesn't work.) I don't know if the samples have been lost or how often to report them because there is never any acknowledgement or feedback, it's hard to tell if there is some subtle difference, and the instructions say not to submit examples using different instances of the same problem-spam. I assume that spammers not only read the forums but also (especially those using a bogus/multiple link strategy) try out their schemes on the parser in advance of spewing. This isn't exactly a secret operation. At least what they don't know is what else I am doing to track them down and report them. (Also, thanks for moving the post to the intended forum.)
  19. Why is reporting of this spammer's web sites being blocked? This spammer is repeatedly spewing out repetitive spam with ever changing URL's for its website. The spam web page links have the same .cn reporting addresses, but with some variation in IP addresses. (Its spam generates the "too many links" error because the parser does not weed out other URLs in a repeating pattern; they are easily found manually.) Recent example: http://www.spamcop.net/sc?id=z528258817z83...2b021a9f6b44afz Tracking for one of the two obvious spam domains: But: The domain iepurchase.com, from the same spammer and which generated reporting addresses earlier today, now results in the same failure. --------- [This post had been intended for the spamcop help forum.]
  20. The response from the big companies has been inconsistent, partially dependent on what email addresses (including non-US addresses) are used for reporting the spammer address. The response you mention is common.
  21. It is possible to get spammer domain registration email addresses removed: is a notorious spam host
  22. I got a response from Don saying that Julian thinks he's fixed it.
  • Create New...