Richard W

Yes, the final fix was pushed out about 5 hours ago. It was tested to death in sandbox late last week before final approval to go hot this morning. We did have an alternative fix earlier but opted to wait out for this fix as permanent. The quick fix obviously would have lowered the priority on the permanent fix, which could them become forgotten. I've tested heavily this morning and have seen no glitches. Richard

Hi Jure, Because of situations like this where mirrors would sit borked or not updating for long periods of time we stopped offering/accepting public mirrors in 2021. It provides us with better control. Thanks, Richard

This is due to Apple changing how they receive mail, using .localdomain to boot. I've been building out a mail host record for it but the naming convention is very wide and distributed. I've done a lot of guessing based on patterns, but its still a pita job

This hasn't been an easy two weeks for me either. But, I can assure you a fix is coming as the root cause has been determined, along with a fix. At this point our dev ops are looking at inter-dependencies before seeking final approvals on the fix. Nothing SpamCop is easy. Most of the code is 25 years old. Its all in PERL. There are many interdependencies not only within SpamCop but other products tied to Ironport. A quick fix here can break a hundred things elsewhere. Part of the issue comes down to a programming error that we should have known better, but obviously didn't. Those that have been around since the beginning of spam recognize some of the history that happened here. BondedSender was part of the Ironport offerings, along with the better known WBRS and SBRS when they bought SpamCop. A mailer could put up a bond, swearing all the mail they send from a particular IP is confirmed-optin, wanted, etc. They got preferential delivery with many mail providers. If someone reported spam from one of these bonded IP addresses, we would send the report to the bonding team for investigation. There was a similar setup with Habeas, who would file lawsuits and injunctions against spammers that used their copyrighted scri_pt in their spam. Both companies were eventually acquired by ReturnPath, who is now Validity. It basically became forgotten code. Recently Validity decided to implement rate limiting on look ups. We were never informed. We started hitting those limits and started getting false positive. The code dutifully kicked in the BS scri_pt, where we are now. Another mistake is we should have taken the answer 127.255.255.255 as 'listed'. That is knowledge we pushed out on users five years ago when we went through our own domain expiry debacle. But, forgotten code. There hadn't been a hit since 2007. Part of the remediation includes making sure we are looking only for correct answers on any look up we do, along with removing Habeas, BondedSender and SORBS (before they become a problem). As for rumours, we did seek an outside utility analysis on SpamCop and its continued value to the company. The answer was a resounding yes. I forgot to mention, quick reporting bypasses the issue.

We started getting false positives on accredit.habeas.com and plus.bondedsender.org last week. This seems to have jumped to 100% fail now. I have a ticket open and trying to figure this out with Validity.

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

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.

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

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.

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

Thanks. I've added this to another ticket that is similar. It is on the list for the next patch rollout. RicharD

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

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.

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

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