Jump to content

Richard W

Forum Admin
  • Posts

    82
  • Joined

  • Last visited

About Richard W

Contact Methods

  • Website URL
    http://
  • ICQ
    0

Profile Information

  • Gender
    Male
  • Location
    Canada

Recent Profile Visitors

5,984 profile views

Richard W's Achievements

Member

Member (2/6)

0

Reputation

  1. The account was deleted at the user's request May 28. There is an easier way. Under Preferences, "Unsubscribe Me" sets it in motion. Richard
  2. I learned this week a scri_pt had to be manually run to pick up and propagate changes to the cesfwd table. I don't know if they ran it on a schedule or when somebody noticed or on complaint or what. It has now been automated.
  3. The last of our changes to our SpamCop mail servers is scheduled to take place Monday, March 27, 2023 beginning at 10:00a.m. EDT and take up to four hours. This should not affect the SpamCop website. Submissions will still be accepted, but processing may be delayed. As there will be some DNS changes, there may be some propagation delays. Thank you for your patience. Hopefully this will end the pain of the last month
  4. Our apologies. This should all be fixed now, save some propagation. Last week Ops moved our servers around to new IP addresses. A mistake was made in the SPF record for our main nat IP, 184.94.240.88, listing .89 instead. This resulted in gmail and many other services rejecting mail due to spf fail. On top of this, the IP ended up on the Spamhaus XBL, resulting in many many more systems rejecting mail from that nat. The IP has been removed from XBL so any ongoing issues with that are likely cache related. The SPF record was fixed overnight and I'm seeing system mail into my Gmail account so gmail has opened the gates. Any other systems with ongoing issues could be propagation or cache related. Also, my apologies to those that wrote directly over the weekend and did not receive a reply. I was working with various Talos teams behind the scenes all weekend. But, because the mail answers were coming from the same nat IP, the same systems not accepting system mail or mail forwards also reject my mail.
  5. I've put this in our developers' queue to have a look at. The key is here: Reports regarding this spam have already been sent: Re: 194.150.215.174 (Bounce) Reportid: 7097982956 To: noc@galaxydata.ru The spam with the blank RP is treated as a bounce by the system Richard
  6. Thanks. I've added this to another ticket that is similar. It is on the list for the next patch rollout. RicharD
  7. I think your ISP changes and your not receiving replies are related, but not really. Just because your smtp settings change in your mail client, doesn't mean the path of your incoming mail changes. I'm not sure what you are expecting to see as a new mailhost. The address you are submitting for mailhost setup is a rr.com address and that mailhost already exists in your account. I see the November 18 mailhost config email was sent to a different LHS address than your SC account is under, but the host is the same. As far as not getting responses to submitted spam, it comes down to 'did the submission reach us?'. It could be a problem of your ISP blocking the submissions with their outgoing spam filters, so the submissions don't reach us, or your submissions reach us but your ISP blocks our replies. I do see some submissions in your account from today, so at least those submissions are reaching us. If you didn't get replies then you know the problem is your ISP blocking the replies. If the submissions are reaching us, as they are and you saw at least the one in your report history, there will be an "Unreported spam" link on the main SpamCop page. Clicking that will take you to the first submission, where you can complete the reporting process. If the unreported spam link is not there, your submissions did not reach us. Richard
  8. Just to follow up, it ended up the time was out on one of the servers. SpamCop runs on many servers with load balancing. Every page you see may be served up by a different server (look at the source code of the page and it will tell you what server it came from (www01 to www03, app01 to app08, and others, 24 in all)). Making sure the time was synced across the servers fixed the issue. BTW Outernaut, just clicking refresh often brought up a shorter time, or even no nag screen if the second was a time in the future.
  9. Just to clear one thing up, we do not sell the database. The SpamCop Blocking List is free to anyone who wants to use it. Since the community contributes greatly in the compilation of the service, it is only fair the community should be free to benefit from it. I only became aware this morning that the nag time had climbed. It is a bug, not anything sinister or intentional. The setting is for a maximum of seven seconds, so I have filed a ticket to have this investigated and fixed since I have been able to duplicate the extended nag screens. Incidentally, the history of the nag screen was a revenue generation put in place by Julian. The nag screen was to be an advertisement display, but there was ever only one taker. When Ironport bought SpamCop the decision was made to not be advertising dependent, but we've never written the nag screen out. We've talked about it many times but have been told it is too integrated to just easily drop and we should wait until the new GUI is in place. After many years, we're still told it's coming, it's coming
  10. Please send me details at service@ spamcop.net. I see your account and there has been no credits. However, we have not used Paypal for a couple of years and no longer have a Paypal account. All payments are now through Stripe. I have a couple of failed payments in Stripe for 9/16 and 9/18, but they don't look they are connected to you.
  11. There seems to be two topics under discussion here. The original question was "user defined recipients", the second is referring to third party checkbox/settings. I just changed my preferences to third party off by default and the box is unchecked when I parse spam. Changing the preference back to default on, the box is checked. The third party report preference setting seems to be working as designed. I added a user defined address into my preferences and the box is in fact checked by default, which IIRC is opposite of what used to be done. Changes to the user-defined report handling went live today after about a week of testing on the beta system. Obviously the changes (which I think Don posted about earlier) did change the default behaviour. I'll put through a bug report on that. Richard
×
×
  • Create New...