Conflict with default DROP policy on filter:OUTPUT chain

While working with hosts that are set to explicitly filter outbound traffic (a requirement in some regulatory scenarios), I've run into some challenges communicating from the host to published ports originating on a container network. With a bit of tracing, I narrowed the issue down to a default DROP policy on the OUTPUT chain of the iptables filter table.

Given that Docker is dynamically injecting rules into the FORWARD chain as well as the nat table, it seems it'd be in a pretty good position to detect and resolve conflicts on the OUTPUT chain of filter. The rules need to match traffic OUTPUT through a bridge interface (default or custom) and jump to the DOCKER chain (which will accept if the traffic is being sent to a published port).

The scenario I'm testing against is as follows:

• iptables -t filter -P OUTPUT DROP
• Network mail-net is a custom, bridged network
• Container imap is attached to mail-net and publishes 127.0.0.1:143:143
• Local processes cannot reach the published service, e.g., nc localhost 143

Start by reproducing the scenario with iptables -t filter -P OUTPUT DROP, the custom mail-net bridge, the imap container, and nc localhost 143. Trace the rules Docker injects into the FORWARD chain and nat table, then determine the required OUTPUT handling for traffic through the bridge; done means local processes can reach the published service without weakening the default DROP policy.