Jump to content

ewv

Members
  • Posts

    96
  • Joined

  • Last visited

Posts posted by ewv

  1. spam hosting mechanisms are just as illegal as the rest of the spam and didn't use to be a low priority.  But clicking on spamvertized links to analyze them is always a risk, even for images, and even if done through tor.  You never know if an encoded url is a web bug for tracking or malware.

    Spamcop does a good job of reporting the spam source, and often spamvertized urls, but can't recognize redirects (which is probably safer unless there is a way to trace it without activating it).

    But big operations like amazon and google ignore spamcop reports, and comprehensive direct reports to their reporting webpages can be ignored for weeks or forever.  Amazon has often notoriously refused to remove spammers, assuming that their customers (even commercial mass email and tracking companies!) must be exempt from the anti-spam laws as "legitimate" whatever they do to illegally harvest and track target addresses.  Abuse desks at big operations like amazon and wix should know better than to recommend "unsubscribing" from a spam operation, and know better than to call obvious crude spam a "newsletter".

    Amazon now has a new website for abuse reporting, which they say may get faster responses than the email reporting address (that spamcop can't use), but it requires opening a hosting account advertised as "free" for now, and giving them a credit card number.  Abuse reporting of illegal spamming is not supposed to require paying the host responsible in a shakedown racket.

    Twitter is at the bottom with apparently no publicized way to contact them at all.  Does anyone know of a channel that won't be ignored?

  2. How is spam abuse reported to twitter?  Spammers are using t.co spamvertized urls to redirect.

    Spamcop has no abuse reporting address: twitterdoesntcareaboutspammers@devnull.spamcop.net

    Twitter has no reporting web pages or instructions, only links to canned articles,  none of which address the problem, in the name of "contact us".

     

  3. On 1/20/2021 at 12:16 AM, MarkA said:

    Well, nobody gives a hoot about this.  I've spent several hours on it but can't do any more.  SpamCop admin won't state which RFCs are not compliant in the sending configuration headers, if any, and DreamHost doesn't think it's an issue after working with them.  So here we are. It's broken some place but nobody wants to take ownership, see it through and fix it.  SpamCop doesn't work any more with DreamHost.  Glad I didn't renew my paid account here. 

    Done.

    I discovered that Dreamhost had without telling me changed my email settings to activate incoming spam filtering.  Once I turned that off again the MailChannels problem disrupting spamcop parsing went away because they were no longer interfering with incoming mail.

    But MailChannels/Dreamhost causes other problems, including false flagging on outgoing mail leading to false positive spam scores, and it's very difficult to get a response from a competent support person from either finger-pointing company.

    A long time ago Dreamhost was very good for flexible email configuration with a shell account.  Over the years they have steadily reduced email service to an inflexible "lowest common denominator" approach, along with recurring devastating failures in service and poor to awful support in response.  Inserting MailChannels disruptions into the mail flow is part of that.  At first, a vps could get around most of it, but even that has been disrupted as Dreamhost VPS has become a restricted VVPS (virtual virtual private server).

    It all seems to be part of the trend to replace personal computing with corporate-controlled appliances where you do what you're told as they invade your privacy.

     

     

  4. There are a lot of articles denouncing cloudflare for this.  Cloudflare deliberately ignores abuse reports, with the sophistry that it is a "content delivery network" (CDN) that does not "host" the spam.  Cloudflare's CDN is a "reverse proxy" that hides hosts, including spamvertized hosts and other malware, behind its own IP addresses in the name of security.  It publicly identifies itself as the host then denies that it is the host to avoid accountability.  Spamcop should be blacklisting Cloudflare IP addresses that are claimed to both host and not host spam.

    Cloudflare also has a record of passing complaints directly to the source, exposing personal information that has resulted in harassment and threats.  And so we have a "security" company that fronts for and protects spammers and worse.

    Clourflare bought Captcha, which has become progressively more of a nuisance and an obstacle to legitimate connections.  It claims this is "security" protecting websites, while protecting the very same spammers who know how to get past Captcha to attack web formmail and forums.  Cloudflare's security business model, a.k.a. racket, is to play both sides at the same time.

    The CEO is some kind of ideological anarchist who repeatedly insists publicly that he is protecting and passing through spam and more as "free speech" -- threats, harassment, and invasion of private property (your computer) are now "free speech".   That sophistry defending spammers was rejected a long time ago for good reason, but Cloudflare gets away with it because it is big and has contracts with other large companies.  It has become "too big to fail" as the excuse for not reining it in.

     

  5. 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?

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

  7. 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 0.0.0.0:2500 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 [100.96.24.78]) 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: 100.96.24.78 

    Meanwhile, after four days, dreamhost support is not responding.

    What does it take to get this fixed?

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

  9. 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'.

  10. 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 [100.101.84.158]) 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: 100.101.84.158
    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 [100.101.84.158])
        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 [100.96.26.96])
        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
     [153.246.145.238])
        by 0.0.0.0:2500 (trex/5.18.10);
        Thu, 12 Nov 2020 10:19:00 +0000

    p110239-ipoefx.ipoe.ocn.ne.jp escapes being reported.

     

     

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