Internal spamcop handling: (bondedsender)

[ninth]

2 hours ago, petzl said:

Microsoft 365 I suspect (my conspiracy theory?) were blocked deliberately/unintentionally not knowing it was Microsoft bombing the world with spam.
Microsoft appear using it's own massive range of IP's in hoping/swapping IP to stop IP's being identified and blocked. They are now using worldwide Cloud storage which used to be spam free

Or with the demise of sorbs 12mil spammy host servers are let loose on the world #RIP #caveatnuntias 

[cwg]

So it's only affecting IPv4 space?

https://www.spamcop.net/sc?id=z6905267212z7c38e9fd05fed6cba39a89a74dd2707ez

[ninth]

Well spotted.

[Richard W]

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.

[S-J]

On 7/28/2024 at 3:28 PM, petzl said:

Been one as soon as Bonded Sender started not sending reports?

Reports count towards SpamCop Block List and count a lot higher than it's poisoned spamtrap email addresses
So pays to keep reporting
You might put in comments as you use SpamCop for reporting
"IP sending to poisoned spamtrap email addresses"

Bonded sender (owned by CISCO SpamCop's owners) are "whitelisted". providers mainly "Cloud" providers who have or had zero tolerance for spammers.

Now comes Microsoft 365 "free offer" which get many spambots signing up a deluging the world with spam;

https://abcnews.go.com/Business/wireStory/internet-outage-latest-airlines-businesses-hit-global-technology-112097254
Microsoft 365 I suspect (my conspiracy theory?) were blocked deliberately/unintentionally not knowing it was Microsoft bombing the world with spam.
Microsoft appear using it's own massive range of IP's in hoping/swapping IP to stop IP's being identified and blocked. They are now using worldwide Cloud storage which used to be spam free

My views and could be erroneous are my own not SpamCop's. I'm a member with no affiliation than that

CISCO/SpamCop are aware of the problem and are trying to get a solution

G'day Petzl, I was hoping for spamcop support to provide something useful. I think at this point I'll give up, I cant waste time waiting for spamcop - they should have some info by now regarding if/when this can be resolved. I'm not surprised that this happened, I hope it's a "whitelist" issue but the hackers have been trying to find a way to end spamcopy for a long time.

 

[S-J]

2 hours ago, Richard W said:

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.

You "forgot to mention what a solution is" ?! Great stuff.

[petzl]

1 hour ago, S-J said:

 

The white-listing was approved by SpamCop members before going bust then sold/saved to/by IronPort/CISCO years ago.
This has worked well with no problems till recently.
Seems those being reported are various worldwide cloud storage servers relaying email spam.
I would say it's definitely a concern for CISCO who would be selling many of these Cloud servers.
Where I once worked these servers proved second to none in not giving false positives or stopping genuine mail. 
The fix has to be methodically worked out.
I report my spam from my email account including rouge URL's which gets you blacklisted by spammers as poison. SpamCop for me is a good source of information in identifying blackhat providers! 
QuickReporting removes the issue

Edited July 31 by petzl

[captkirk]

7 hours ago, Richard W said:

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.

Thanks for the update!

[ninth]

Thanks RW...none of us are perfect. We all witnessed the result of the cloudstrike falcon update transition into production without enough testing. I was lining up for ages at the local supermarket on the friday evening at the only working checkout. A good lesson to have a little cash on hand and to keep up to date with updates despite this error because most of the biggest outages in history were due to cyberattacks.

[SCRE]

Thanks RW and SC, reporting is working again 👍

Edit: Was only working for a short time, at the moment the problem still exists😢

Edited August 1 by SCRE

[EkriirkE]

Everything is still bonded here

[Jese]

Only difference that I see, is that reports for
'Internal spamcop handling: (bondedsender)'
are no longer disabled.

No reports are being made to the senders abuse address.
Most definitely still broken, broken broken.

[ninth]

11 hours ago, Jese said:

Only difference that I see, is that reports for
'Internal spamcop handling: (bondedsender)'
are no longer disabled.

No reports are being made to the senders abuse address.
Most definitely still broken, broken broken.

Tracking URL please:

 

[xebeche]

21 hours ago, ninth said:

Tracking URL please

Here are 2 from just now. HTH.

https://www.spamcop.net/sc?id=z6905618147z333236aab724d8d5c7dfa499e63dd51cz

https://www.spamcop.net/sc?id=z6905616153z496009feeecd4b9bf82c2ab5e9aea0d4z

 

[A.J.Mechelynck]

FWIW, here are four that I got:

https://www.spamcop.net/sc?id=z6905624890z2fade407c8a944292eb9daad38456ec3z
https://www.spamcop.net/sc?id=z6905624958zd9c7541c758febc0085c57b9b324be1ez
https://www.spamcop.net/sc?id=z6905625050zf20b7184b970ad5de3deac2f8b2c42d5z
https://www.spamcop.net/sc?id=z6905625186za782fd6f8471e19db4c39840b4c4b766z

All my spam reports go only to bondedsender@admin.spamcop.net nowadays. Once (just once), shortly after reports to bondedsender stopped being disabled, I saw a report to a Google abuse address together with bondedsender... let me try to find it back... ah, there, but now "too old to file a spam report (received 2024-07-29)":
https://www.spamcop.net/sc?id=z6905248111z1fe753f926cf4d18c2a57c6a2de18d88z
Is it useful to shower SpamCop with all those "Internal SpamCop handling (bondedsender)" reports ? Or could they just be canceled ?

[ninth]

42 minutes ago, A.J.Mechelynck said:

FWIW, here are four that I got:

https://www.spamcop.net/sc?id=z6905624890z2fade407c8a944292eb9daad38456ec3z
https://www.spamcop.net/sc?id=z6905624958zd9c7541c758febc0085c57b9b324be1ez
https://www.spamcop.net/sc?id=z6905625050zf20b7184b970ad5de3deac2f8b2c42d5z
https://www.spamcop.net/sc?id=z6905625186za782fd6f8471e19db4c39840b4c4b766z

All my spam reports go only to bondedsender@admin.spamcop.net nowadays. Once (just once), shortly after reports to bondedsender stopped being disabled, I saw a report to a Google abuse address together with bondedsender... let me try to find it back... ah, there, but now "too old to file a spam report (received 2024-07-29)":
https://www.spamcop.net/sc?id=z6905248111z1fe753f926cf4d18c2a57c6a2de18d88z
Is it useful to shower SpamCop with all those "Internal SpamCop handling (bondedsender)" reports ? Or could they just be canceled ?

On the first link the IP has already been reported or the receiver is not accepting reports? - either way the sending IP has been recorded for stats and more importantly blocked for at least 24 hours. There is no showering going on, the problem has been identified as a limit placed on queries of a third party blocklist and the development team is working on a resolution.

Edited August 4 by ninth

[Spamnophobic]

From my side of the screen, SpamCop now seems to be accepting reports about "bondedsender". To me, this is fine because I report everything reportable, not so much out of pity for poor exploited mailserver admins (they ceased to exist as such long ago), but in the hope that the reports helped to keep the spamsending addresses on the blacklist. Glad to see something seems to have changed at SpamCop and thank you Deputies.

The reports to the sender's abuse address are unlikely to be important, he is the spammer. The important thing is to get his IP address on the SpamCop blacklist.

[fliptop]

On 8/5/2024 at 10:33 AM, Spamnophobic said:

The reports to the sender's abuse address are unlikely to be important, he is the spammer. The important thing is to get his IP address on the SpamCop blacklist.

Are you saying this is a good thing?  That companies like Google, Microsoft, OVH, Digital Ocean, Comcast, etc. shouldn't receive spam reports when their users are abusing their systems?  Or when one of their customer's accounts has been hacked and is being used to pump out spam?

[Spamnophobic]

Unfortunately if they don't want to receive spam reports, there is precious little we can do about it. Of course they receive umpteen zillion reports so they logically don't accept new ones.

Please note that the customer's account hasn't been "hacked". Sending a mail to the victim "from themselves" is a very basic trick these spammers/extortionists use to try to convince the victims to send them money.

[Spamnophobic]

Bondedsender now seems to be accepting reports without any more strange looping behaviour, and seems to all intents and purposes to be acting like the former devnull address. Spams submitted there were not acted on, except that they were recorded to fuel the "statistics", which meant, as I understood it, that the reports would feed the SpamCop blacklist which was circulated to any mail admin (and that were many) who subscribed to it. Ie. to help all the mail users who liked "their" spam to be "cleaned for them" by their mail admin.

As usual for SpamCop, there has been no communication from admins or deputies or whatever to this site about all this, so we just have to guess and hope.

[Spamnophobic]

Actually the reports to "legit" sites like Microsoft are almost invariably because spammers put links to their sites into their spams to make them look "legit" and the reporting process traces these back to their source, which QED is of course legit. Logical that Microsoft cs. just ignore this.

[A.J.Mechelynck]

2 hours ago, Spamnophobic said:

Actually the reports to "legit" sites like Microsoft are almost invariably because spammers put links to their sites into their spams to make them look "legit" and the reporting process traces these back to their source, which QED is of course legit. Logical that Microsoft cs. just ignore this.

The problem is that at present, spam whose "Received" lines, which, unlike the "From" lines, cannot be faked, indicate that they were actually sent from an Outlook user, or from a Comcast user, or from a user of any ISP for that matter, now generate a report to bondedsender@admin.spamcop.net, which is treated like an "omnibus" reporting address for spam originating anywhere. The only other reports that I see (and that rarely) are reports to the abuse addresses of sites found from links within the spam text and which haven't disabled this kind of report. Wikipedia has but AFAICT Google is one of the few ones who hasn't.

[ninth]

16 hours ago, A.J.Mechelynck said:

The problem is that at present, spam whose "Received" lines, which, unlike the "From" lines, cannot be faked, indicate that they were actually sent from an Outlook user, or from a Comcast user, or from a user of any ISP for that matter, now generate a report to bondedsender@admin.spamcop.net, which is treated like an "omnibus" reporting address for spam originating anywhere. The only other reports that I see (and that rarely) are reports to the abuse addresses of sites found from links within the spam text and which haven't disabled this kind of report. Wikipedia has but AFAICT Google is one of the few ones who hasn't.

This is not the case...the app works out the email/IP that really sent the spam which can be faked and reports to the responsible network admins indicated by the whois are sent out. The spammers use VPNs IP/email forgery and hack servers and email account passwords not using 2nd authentication or use an alias to hide the sender in the inbox. Every possible scenario when there is an exception to the rule cannot reasonably be predicted by the programmers and the changes to fix it cannot be made on the fly when 50,000 plus spam abuse reports are processed every 24 hours.

Edited August 10 by ninth

[grifferz]

I'm a little confused as to the status of this now.

The current situation from my perspective is that (almost?) all "source of email" reports go only to bondedsender. The only other reports I see are for URLs in the body text.

Is it the case that SpamCop considers this new behaviour as intentional, correct behaviour of the reporting system, or is this acknowledged as a problem that is still being worked on?

Thanks!

[fliptop]

On 8/9/2024 at 10:43 AM, Spamnophobic said:

Please note that the customer's account hasn't been "hacked". Sending a mail to the victim "from themselves" is a very basic trick these spammers/extortionists use to try to convince the victims to send them money.

One of my clients just had his Office365 account hacked and it was immediately used to pump out spam to his whole contact list and a bunch of other recipients.  It happens all the time.