Does disabling IPv6 create a form of open relay?

cjwalsh

My VPS provider (Ionos) recently changed to no longer support IPv6 Reverse DNS, and this causes problems with sending mails to services like Gmail. I set about disabling IPv6 in my Mailcow setup per the instructions here, and all seemed fine.

However today I found a bunch of emails had been routed through my server somehow, sending spam using one of my domains which doesn’t have any mailboxes, just a couple of aliases, and the From address being used in the spam messages didn’t correspond to any of those addresses.

Digging through my logs, it appeared that these messages were being submitted from 172.22.1.1 which is the default gateway on the docker network for mailcow, using a high numbered port on the client end. This had me stumped for a while on how this could happen, but I think this is probably because the external IPv6 address is still available for my server, and Docker is routing IPv6 traffic to the internal IPv4 mailcow network via the default gateway. Since it looks like Mailcow automatically whitelists traffic from the gateway address, it looks like this effectively creates an open relay, or at least a relay for messages appearing to come from any of the hosted domains.

Does this analysis seem reasonable, or am I misinterpreting what’s happening here?

For now I have changed my configuration and re-enabled IPv6 support, and I think I have found the “proper” way to limit postfix to send mails out only via IPv4.

As per the postfix documentation here:

The setting “smtp_address_preference = ipv4” is not a solution for remote servers that flag email received over IPv6 as more ‘spammy’ (the client IPv6 address has a bad or missing PTR or AAAA record, bad network neighbors, etc.). Instead, configure Postfix to receive mail over both IPv4 and IPv6, and to deliver mail over only IPv4.

/etc/postfix/main.cf:
inet_protocols = all
/etc/postfix/master.cf
smtp …other fields… smtp -o inet_protocols=ipv4

Mailcow already uses inet_protocols = all so I amended data/conf/postfix/master.cf to add the relevant option to sections which use the smtp service, specifically:

smtp_enforced_tls
smtp_via_transport_maps
smtp
relay

Snippets from master.cf:

# enforced smtp connector
smtp_enforced_tls      unix  -       -       n       -       -       smtp
  -o smtp_tls_security_level=encrypt
  -o syslog_name=enforced-tls-smtp
  -o smtp_delivery_status_filter=pcre:/opt/postfix/conf/smtp_dsn_filter
  -o inet_protocols=ipv4
# Send over IPv4 only since Ionos no longer supports reverse DNS for IPv6

# smtp connector used, when a transport map matched
# this helps to have different sasl maps than we have with sender dependent transport maps
smtp_via_transport_maps      unix  -       -       n       -       -       smtp
  -o smtp_sasl_password_maps=proxy:mysql:/opt/postfix/conf/sql/mysql_sasl_passwd_maps_transport_maps.cf
  -o inet_protocols=ipv4
# Send over IPv4 only since Ionos no longer supports reverse DNS for IPv6

smtp       unix  -       -       n       -       -       smtp
  -o inet_protocols=ipv4
# Send over IPv4 only since Ionos no longer supports reverse DNS for IPv6

relay      unix  -       -       n       -       -       smtp
  -o inet_protocols=ipv4
# Send over IPv4 only since Ionos no longer supports reverse DNS for IPv6

I believe I’ll need to re-apply these changes manually after each upgrade of mailcow since master.cf will be replaced during the upgrade, and I can’t set this configuration via extra.cf.

So far this configuration to send only via IPv4 seems to be working.

cjwalsh

Looking into it a bit more, postfix is configured to relay mail coming from machines on the local subnet, due to the mynetworks_style = subnet setting combined with permit_mynetworks being set for smtpd_relay_restrictions, postscreen_access_list, smtpd_recipient_restrictions, and smtpd_sender_restrictions (all in main.cf), so I think this will actually create a full open relay if the incoming connection appears to come from the internal network.

I think my diagnosis is correct about the IPv6 external client address being mapped to the mailcow network’s IPv4 default gateway address, based on this page on IPv6 support for docker-mailserver.

If your host system supports IPv6 and an AAAA DNS record exists to direct IPv6 traffic to DMS, you may experience issues when an IPv6 connection is made:

The original client IP is replaced with the gateway IP of a docker network.
…

It looks like docker-mailserver does not have IPv6 enabled by default in its container(s), so this would be analogous to the scenario for Mailcow with IPv6 disabled.

So I think this is a scenario to watch out for when disabling IPv6 in the mailcow setup, but continuing to have an external IPv6 address on your host, since this will create an open relay for IPv6 external clients!

I think my diagnosis is correct about the IPv6 external client address being mapped to the mailcow network’s IPv4 default gateway address, based on this page on IPv6 support for docker-mailserver.

If your host system supports IPv6 and an AAAA DNS record exists to direct IPv6 traffic to DMS, you may experience issues when an IPv6 connection is made:

The original client IP is replaced with the gateway IP of a docker network.
…

It looks like docker-mailserver does not have IPv6 enabled by default in its container(s), so this would be analogous to the scenario for Mailcow with IPv6 disabled.

cjwalsh

Looks like my changes to master.cf to only use IPv4 for smtp services were preserved during the latest mailcow update process, but definitely something I’ll keep an eye on with each update.