When using host networking

Out of curiosity, why are you using host networking with this image? Is there an issue with a bridge network at all?

@polarathene hi :-)

i encountered deliverability issues with providers like gmail, outlook, and icloud.
a large enough fraction of incoming email was bounced to cause their spam detection to flag/reject outgoing mail.
it appears the issue was related to ipv6.
because of the lower volume, it took me months to figure out that there were bounces, these bounces were causing outgoing mail to be flagged as spam, and the bounces were caused by the container not seeing ipv6 source addresses.

it has nothing to do with docker-mailserver, per se but with docker itself.
it's really stupid - imho - that the docker default bridge doesn't do ipv6.
yes, ipv6 private networking with NAT is frowned upon but how is it better than doing NAT from ipv6 to ipv4?!?!
in userland... (referring to the default behaviour of --publish)

if ipv6nat had been part of the configuration template, maybe i would've rolled with it.
but since - apart from an ssh server - nothing else uses the network on that machine, i'm reluctant to add the extra complexity.

Thanks for sharing 👍

it's really stupid - imho - that the docker default bridge doesn't do ipv6.
yes, ipv6 private networking with NAT is frowned upon but how is it better than doing NAT from ipv6 to ipv4?!?!

I am aware, and looked into this regarding a recent-ish IPv6 issue, but didn't get around to posting a response. The good news is support is improving (albeit rather slowly). While experimenting with Docker support, I did find a bug, which has since been fixed but I'm not sure if it's made it to a public release yet.

If you want to use container networking with IPv6, make sure you have the following in /etc/docker/daemon.json:

{
  "ip6tables": true,
  "experimental" : true,
  "userland-proxy": true
}

You'll need to restart the daemon if it's running, not just reload it. The above enables the ipv6 NAT which will avoid the routing to ipv4, so long as the container is on an ipv6 network that we'll configure next. experimental is required currently for ip6tables to work, pretty sure userland-proxy is too (but should be enabled by default, there is upstream talk to switch to disabled by default though).

Then you need to configure a network for your container, in docker-compose.yaml the default bridge network isn't the same as the default bridge config in /etc/docker/daemon.json, that only applies to docker CLI (eg docker run). Instead you can override the default network like I detailed here:

networks:
  # Overrides the `default` compose generated network, avoids needing to attach to each service:
  default:
    enable_ipv6: true
    # An IPv4 subnet is implicitly configured, IPv6 needs to be specified:
    ipam:
      config:
        - subnet: fd00:cafe:babe::/48

I don't see any issue for IPv6 NAT with ULA addresses for internal routing like that.

I might not know IPv6 well enough though, but unless I'd explicitly want an IPv6 address for a container to be publicly reachable, I prefer the NAT config above. Then my server with it's public IPv6 address can be reached, and be compatible with the containers without all those containers being reachable publicly 🤔

@polarathene nice, good info - thanks!

my previous attempts with the bridge failed - likely because i didn't know about the experimental flag..
maybe i'll give it another go!