Just FYI, you should be certain you can trust these subnets.

In Docker, at least historically due to the userland-proxy process, if the host could be reached by IPv6 but the container only had a private range IPv4 network, what would happen is Docker rerouted the IPv6 connection to IPv4 through the IPv4 subnet gateway IP (eg: 172.16.0.0), so all IPv6 clients appeared to be internal traffic as that gateway IP was trusted.

If the container had an IPv6 network as well, then it would retain the original client IPv6 IP and that wouldn't happen. Likewise if the userland-proxy feature was disabled, it would not try to route it like described and the connection would just fail.

When it comes to PROXY protocol trust, the risk would have been any IPv6 client could provide their own PROXY protocol header and that would be trusted. However, since there should be a proxy service inbetween the client and DMS/Dovecot here, that should be enforcing that any untrusted connection has PROXY protocol stripped away before the connection is forwarded to DMS, where PROXY protocol headers are added from your proxy service.

Just thought I'd mention this for context, as I think our official docs caution about such (such as only setting to an IP of your proxy service, if you have the control to pin that in a deterministic manner).

Any container compromised in the network could likewise fake PROXY protocol otherwise, which unlike the non-PROXY protocol ports, could allow for bypassing some security restraints if manipulating the client IP to Dovecot/Postfix provides more access/trust.