Currently I need to add this option to the dovecot local config manually after creating the volume, but I would prefer if this was something that can be setup using the environment variables like the rest of the settings.

We'd prefer not to add ENV that map a value to a single line setting. This has happened in the past when maintainers were not as strict but it is a bit of an anti-pattern IMO, so I'm against accepting such contributions without sufficient justification to reason the benefit over our existing config override support.

Would I be mistaken if this is just about simplifying your config by using ENV instead of one more file? If so you can avoid a separate file by using a Docker Compose feature configs to inline/embed a file in compose.yaml instead.

services:
  dms:
    configs:
      - source: dovecot-override
        target: /tmp/docker-mailserver/dovecot.cf

configs:
  dovecot-override:
    content: |
      login_trusted_networks = 10.0.0.0/8 192.168.0.0/16

If you actually have a need for this to rely on being configured via ENV, you can use Docker Compose variable interpolation:

configs:
  dovecot-override:
    content: |
      login_trusted_networks = ${LOGIN_TRUSTED_NETWORKS:?Trusted networks must bet set}

Now the ENV LOGIN_TRUSTED_NETWORKS must be set for this compose.yaml to run. You can have this ENV already set in the environment of the docker compose command, or via an .env file.

Given the above I really don't see the need for this PR (as much as I appreciate the effort, this would have been pointed out if feature requested prior to save you the time 😅)

Does the above approach I suggested instead work for you?

Personally I use it to display the correct client IP when requests come from Roundcube.

I believe that's been an issue raised in the past. It might be good to document it via a FAQ entry if you'd like to help others be aware of the setting.

Another alternative that I think we could consider is integration of this setting with PERMIT_DOCKER. That's a bit broader in scope though, trusting the subnets it covers (which presently isn't implemented well or that configurable..).

Maybe if the feature got reworked, or we just make a docs page for manual configuration of the various service settings that could be manually configured, and like shown in my previous comment an ENV (not a DMS one, unless handled via user-patches.sh instead of Compose configs) could make it easy to set a subnet(s) across the settings.

Well it wasn't an absolute waste of time because at least I am now aware of the configs option. I have not tested it yet but it looks like that should solve my problem.
It just seemed like the right thing to do at the time since I saw there were some other options which were controlled this way.

I'll close this for now; it seems the concern is addressed. We recommend opening an issue before directly opening a PR to avoid this.