Thanks for kicking off this thread, and the other one on postgrey efficacy. 
Building a decentralized, federated spam protection service sounds interesting. However, attackers might also setup MiaB servers and trying to pollute the spam data. Bad actors aside, there’s also the challenge of debugging decentralized systems when they inevitably fail. I would like for MiaB to last many years more, so I’m wary about changes that could make it harder to develop and maintain.
This issue could also be addressed upstream. Could we help improve the Spamassassin project itself? Maybe they have some research we could learn from?
There was recently an email devroom at Fosdem with lots of presentations on state-of-the-art email handling. Might be some inspiration to get there?
Also, maybe the solution isn’t technical, but rather some community recommendations we maintain for handling spam, besides MiaB’s defaults.
For example, I noticed I received spam from a domain which was unused by the company owning it, but it did not specify a restrictive SPF record. As a wildshot, I tried emailing the company to make them fix it. Just now I checked the email records using mxtoolbox and I see they’ve fixed the issue with proper DMARC and SPF records.
I’m not sure how to handle spam coming from gmail.com. Gmail itself recommends marking mail as spam within gmail, but I’m not a gmail user. I’ve tried forwarding gmail-spam back to abuse@gmail.com, though I haven’t found any Gmail documentation saying they act on emails received that way.