Jump to content

Richard W

Forum Admin
  • Content Count

    71
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Richard W

  • Rank
    Member

Contact Methods

  • Website URL
    http://
  • ICQ
    0

Profile Information

  • Gender
    Male
  • Location
    Canada

Recent Profile Visitors

1,510 profile views
  1. Handled through mail. Thanks.
  2. Richard W

    Planned SpamCop Outage

    A major upgrade to the SpamCop reporting system is scheduled to take place Sunday night. This is the long awaited move to SpamCop version 5.0. The upgrade is scheduled to start around 10:00 pm PST (-800) Sunday, January 13, 2019 and will take from eight to ten hours. The SpamCop website may not be available during some or all of this time. If you see "Maintenance Mode" you will know the changes are in progress. Thank you for your support and patience, Richard
  3. Richard W

    error: couldn't parse head

    If you write me at deputies@ with your account address and the addresses you are trying to add, I'll see what I can do. Can't do much with Hotmail or Gmail until they get they crap together and start following standards again, but if you have other hosts I may be able to dig them up.
  4. Richard W

    PARCO Innovation compagny blacklist

    Another possibility is, I notice bouyguestelecom.com has their own issue with IP addresses being listed. It is possible they are rejecting mail because their own IP is listed, but their error message shows the connecting IP. In this case they would be rejecting most of their incoming mail and would hopefully notice quickly.
  5. I'll file a bug report on the exact matches as those should be munged. I can't say whether the address is being munged in the delivered report or not. In the ones I check in the past, they were munged. This looks to be a different situation though. The only real way of checking is to send yourself a report and see what you get. I can't really make an argument on munging the from address where it is not an exact match with the recipient address though. sameLHS [at]gmail.com is not a match with the address the spam was sent to. If its any consolation, this does look to be gamut spam, so the reports are not going back to the spammer/bot operator. But it is a door we need to get closed again. Richard
  6. Richard W

    Planned Outage - SpamCop Forum

    There will be a planned outage of the SpamCop forum on Monday April 25 from 6:00 am to 10:00 am PDT. During this time the forum hosting provider will be upgrading the software to its new version. Richard
  7. Lou is correct. When we took over the MX from CESmail in 2014 our concern was we didn't want users losing email addresses they had come to rely on, but it was not feasible to take over the actual mail service. Therefore our promise was to forward received mail to an address provided by the user. No filtering is done. The mail shouldn't be coming to you as an attachment. The mail just passes through as a .fwd rule, adding a hop to the header. There is no actual server at mvx.spamcop.net to accept the mail, store it and forward it. Richard
  8. Richard W

    All spams lately get "no links found"

    Word is the bug should be fixed. A patch was pushed out Wednesday night after a couple of days of beta testing. The issue was created when some coding was changed/removed to correct css vulnerabilities. It took a while to get a secure workaround.
  9. Richard W

    Forum Status

    I just want to follow up a little bit with what Lou had to say. As many of you have noted, it has been a rough few weeks around SpamCop. Believe me though, it's been tougher on this side of the screen than on your side. With all the security breaches and break ins and data thefts, everyone is concentrating on security. There has been huge increases in spam in recent weeks from exploits in all the major CMS software, including Joomla, WordPress and others. This means anything scripting, such as php, cgi, or whatever is suspect. Our back end teams are pouring through code looking for anything that might be suspect and making changes. Of course with all the inter-dependencies in SpamCop those changes will sometimes unexpectedly break things. That's what is behind things like the not finding links issue, html display issues, etc. It's a time consuming process but it is all being done to maintain the integrity and security of SpamCop. Fixing some of the breaks will always be prioritized along with all projects underway, so sometimes they are going to take longer than normal. They are all being tracked and will be fixed. Cisco remains committed to SpamCop and SpamCop is a very important part of their security operations. This includes SpamCop being part of the Talos group at talosintel.com, where we are part of Cisco's overall security research, response and development team. Richard
  10. As I had stated and shown, reports are going out with the addresses munged. If I suspected there was an issue I would have been the first to make the call to flip the switch on SpamCop until the problem is resolved. There is an issue with the html rendering and display on the SpamCop pages, where mark up language is being shown instead of tag characters causing the display to not show the tags properly, outgoing reports are being interpreted properly and user addresses are munged. I'm working with our development team to get this resolved. Richard
  11. I can assure you reports are going out with the addresses munged. The same bug that is causing html tags to be converted to ascii is causing addresses to be displayed when you look at the message in your browser. However the report that goes out is sent correctly: User-targeted report, see notes, if any. https://www.spamcop.net/w3m?i=z6zzz004zfdd2e5bb2b90188260669f94dbxxx [ Offending message ] Return-Path: <wegwuag[at]pizda.ninka.net> Delivered-To: <x> Received: from vmx5.spamcop.net by prod-sc-queue2.sv4.ironport.com (Dovecot) with LMTP id OomQJealClfyYgAA97r88g for <x>; Sun, 10 Apr 2016 12:14:14 -0700 Received: from pizda.ninka.net (unknown [101.71.197.33]) by vmx5.spamcop.net (Postfix) with ESMTP id 0DBBBED2FE for <x>; Sun, 10 Apr 2016 12:14:06 -0700 (PDT) Received: from axu (unknown [140.165.46.118]) by pizda.ninka.net with SMTP id mwaAOpRAeo7IlIZv.1 for <x>; Mon, 11 Apr 2016 03:14:06 +0800 Message-ID: <2016____________5127[at]pizda.ninka.net> From: =?utf-8?B?54eV5oC7?= <wegwuag[at]pizda.ninka.net> To: <x> Subject: =?utf-8?B?5pyA5paw5Ye65Y+w55qE5paw5Yqz5Yqo5ZCI5ZCM5rOV?= Date: Mon, 11 Apr 2016 03:14:00 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0E7B_011A47D6.17D6E4E0" X-mailer: Rnnxeyfsyy 3 Richard
  12. Richard W

    Important SpamCop Announcement

    Announcement It is with extreme sadness that we announce the passing of long time SpamCop Deputy Don Bennett (aka Don D'minion). Don was the first deputy hired by SpamCop in about 2001 and has been busy in the fight against spam since then. Although Don may have been hard-nosed, he also had the thick skin needed in this job. Underneath, he held a true desire to just make sure things are done right. He was a colleague and a friend, who truly will be missed. Anyone that has been making contact through the service[at] alias can continue to do so as I'll be looking after that mailbox for the time being. If you've been using one of his personal aliases to contact SpamCop, please change to service[at] or deputies[at]. Thank you and may God bless Don and his soul. Richard
  13. Richard W

    SpamCop not signing in (paid service)

    Please be patient with us on this one. We have 24 shiny new servers coming online that are running a new version of SpamCop (v4.8.3.028) on CentOS versus FreeBSD and SpamCop v4.8.2.018. Obviously we're working through some bugs so you're seeing us switching back and forth between the servers. Hopefully everything will be worked out and we'll be on the new servers full time by mid-week. Richard
  14. Richard W

    wrongly parsed header?

    It's been a long time since I've hand parsed it took me a bit to get on top of this :-) The parsing engine does act differently for users that have mailhost records in their account versus those that don't (you don't). It does rely a little more on chain verification, time stamp matches, things like that when there is no mailhost record. Note in the parsing there is a couple of statements: mail.gavle.to and h-214-100.a322.corp.bahnhof.se have close IP addresses - chain verified Possible relay: 85.24.214.100 Received line accepted After that the received lines fail the chain test, so it falls back and takes the most recent accepted line, which is the handoff from 37.9.53.106, which does look like the correct target to me. I looked at a bit of your report history to see how your network handles mail. Some other samples from this same source convinces me the right source was selected. If you had mailhosts in your account the parsing would probably have stopped at 85.24.214.100, but here it went one step further. Certainly not a wrong choice. Richard
×