I’ve tried to do this on my own, but can’t really make headway…
I’d like to document this for the wiki, so others can start from a better place than I am. So, I’m trying to figure out the “right” way to do this…rather than just hack something together that only kinda works, but is fragile and prone to break easily…

—
Let me explain what I’m trying to do, and you can suggest ways to do this most efficiently.
I’ve also posted on the telegram group, but really didn’t get anything useful there either.

I’ve got a hosted MC from you, and I’m also wanting to do this for an internal MC server at a client. (I’m pointing this out, since if I’m documenting this, I’d like to allow hosted MC users to do similar stuff using non SSH tools, if possible - since hosted MC doesn’t have access to SSH - even though I do.)

Here’s what I’m trying to do.
I want to essentially block all attachments that could potentially be hostile. (I’m trying to fine-tune that list currently, but it’s still something of a moving target…)

But obviously we’ll have some senders and recipients that we do want to allow attachments through.

So, we’ll then we’ll identify some sources we trust for attachments.
(I currently do this with Amavis in a non MC install, by identifying a triad of conditions -

1) The source server (or source email address - yeah, I know this is forge-able, but works for us where something that isn’t forge-able isn’t available.)
2) The destination address.
3) The attachment type. (say zip file, or word doc, or…)

If all three elements line up. (here’s an example)
From: gregs@schmoo.net
To: gregs@schmoodle.com
Type: zip file.

Then allow the attachment.

So, I want to do something similar in MC.

—
Several potential issues come up.
(Lets only worry about redefining bad_extensions here - not matching and allowing any through. If I can figure out how to best apply the block for the extensions I want, I’ll tackle the “allow” portion next, independent from this problem.)

Since MC is running in docker, we can’t just edit rspam config files in any context we want (at least I think so), since a MC update in docker will likely overwrite some files, and our customization will be lost. (This is different than if rspam was running on a bare-metal install. So, the interaction between MC/Docker/rspam matters.)

If I understand rspam correctly, we can’t use .local files to redefine things like “bad_extensions” where they are previously defined. We have to remove the definitions in the base config, and define them the way we want them defined in the .local config.

I haven’t tried setting up the triad of elements in the “allow” portion of the system yet, but lets not sweat that now. Lets just try to get the bad_extensions working the way I need first, then I’ll continue to work the problem to conclusion. (Plus I think we’ll avoid config over-writes doing the multi-maps for sender/recipient/file-type - since these aren’t previously defined items - so it will be less complicated, trying to mash two configurations together.)