Thanks for taking the time to think this through and write up a concrete proposal, it’s appreciated.
When I refer to “upstream configuration”, I mean what is provided by Alpine’s Rspamd packages. In NS8 Mail the intent is to keep modules.d/ as shipped by Alpine, use local.d/ inside the image for the module’s own configuration, and expose override.d/ as the persistent hook for administrator customizations.
While we technically control local.d/ and could introduce additional layers (such as a nethserver.d/), doing so would diverge from Alpine’s layout and effectively create a Mail-specific configuration model. That adds complexity and makes it harder to reason about behavior using upstream Rspamd documentation.
Mapping local.d/ as a writable volume would also blur the distinction between vendor configuration and admin intent, which we explicitly try to keep separate in a containerized module to ensure predictable upgrades.
For the specific case you mentioned (excluding a sender or host from a policy like once_received), using override.d/ is the supported and expected approach today. There are already examples of admin-side customization following this model, such as the Howto for blocking TLDs and email addresses in NS8 Mail: NS8: How to Block Top-Level Domains (TLD) and Email Addresses
Dynamic configuration tables under /var/lib/rspamd can also be an option in some scenarios, especially when UI integration is useful, but I haven’t fully evaluated that path yet.