We've been having significant problems with the CBL's ill-thought-out policies
I am not sure what is ill-thought-out about their policies. In both scenarios, IP address is sending SPAM. IP address gets blocked.
The ill-thought-out bit is that the CBL is an *spam email* blocklist, but their heuristics cause networks that aren't sending spam email to get listed and therefore blocked. Whilst there is no arguement that the networks were infected with malware, listing them on the CBL serves no useful purpose since they were of no threat to the systems that would be using the CBL (mail servers).
Previously, sharing an IP address between multiple services was a reasonable idea - there was never a reason not to do this and it conserves IP addresses. However, with the advent of the CBL using an HTTP honeypot to populate an SMTP blocklist, there simply isn't any sensible way to run a network in this configuration - it just takes one person to connect an infected laptop to the network for a short period of time, and all the email starts getting blocked.
Because of this, we are now having to standardise on running mail servers on a separate IP address - this does nothing to decrease the incidence of malware, it simply stops an infected network being listed on the CBL.
The author (you?) ask for a list of honeypot addresses, but you could be a spammer, who could use that list to delay blocking of the SPAM.
I could be a spammer, but I'm not.
The idea was that as the malware was always connecting through the transparent proxy servers, having a list of honeypot addresses or some other way of fingerprinting the request we could (1) automatically isolate the affected system, and (2) automatically inform the sysadmin so (s)he could clean up the mess. This would be a Good Thing for everyone.
As it turns out, the CBL maintainers were not cooperative (for whatever reason), so we're stuck with the aforementioned interrim measure of separating services onto different IPs rather than actually resolving the root problem.
People in the business of securing networks really do need to trust each other to some extent - if they refuse to cooperate out of paranoia then the spammers have basically won already since there's no way anyone can effectively defend against spam and malware in isolation.
Also, I have not seen a SPAM bot that uses the smarthost. This doesn't mean that they don't exist, but I think that they are rare.
Indeed. That was the point I was making: the only way to send email out of the affected networks was via authenticated smarthosts. Yes its posible that some malware could extract the authentication credentials out of a user's mail client (if they have one configured) and use those to send spam, but that's a lot of effort to go to and I've never seen any malware do that (and if malware does do that then *everyone*'s screwed because it'll start sending spam through corporate email servers, gmail, etc.). So the networks in question were essentially immune to sending spam email, yet were still being blocked by the CBL from sending email because they had a client making spammy web requests - this makes no sense.
Hence blocking direct access to port 25 through the firewall stops most spambots from actually sending spam.
And this is exactly how the networks in question are set up, yet this does nothing to prevent the network from being listed on the CBL since the CBL's honeypot is checking for suspicious HTTP connections rather than SMTP traffic.
If the spams are relayed through your own smarthosts, then how about some kind of rate-limiting mechanism with alerts to the administrator? Quick action by the admin would prevent listing.
To reiterate, in case it wasn't clear from the blog article, there was no spam email leaving the network - port 25 is blocked, the only way out of the network for mail is via an authenticated SMTP smarthost. The issue is purely that the smarthost shares the same IP address as the web proxy and the CBL honeypot looks for *HTTP* traffic (which was leaving the network) rather than *SMTP* traffic.