The Setup Guide suggests disabling IPv6 on the new cloud instance; I don’t use IPv6 day-to-day, and don’t understand it well enough to be responsible for it.
I removed the IPv6 address on my cloud instance, configured the grub command line to disable support, making the cloud firewall rules all IPv4 only, etc., then ran mailinabox setup.
Setup stopped at the systemctl restart of dovecot, unable to listen on IPv6.
Reading in discourse, it seems that IPv6 is supported. So I re-added an IPv6 /64 in my cloud, reran mailinabox.
Now postfix says Incoming/Outgoing mail on 25/465/587 are accessible over ipv4 but not ipv6. main.cf says postfix is bound against the “SLAAC” address, which is not in the /64.
I’d love to learn more about this, but not in the middle of migrating my key domain. Anyone recognize this situation? Thanks, K.
It sounds like the install might have got confused. You could try updating the MIAB install config and rerunning the install.
In /etc/mailinabox.conf the line PUBLIC_IPV6 should show your static, externally accessible IPv6 address. The line PRIVATE_IPV6 would normally be the same address as PUBIC_IPV6 (seeing as NAT/etc is not normally used on IPv6).
I’d reboot the box and check you have the desired v4 and v6 addresses (I use ip a), check/update /etc/mailinabox.conf, and then do sudo mailinabox.
Thanks for the assistance. I think it’s working now, no more errors on status check.
One issue was, even after enabling IPv6 and rerunning mailinabox (a few times), Postfix’s main.cf had inet_protocols set to “ipv4” rather than “all”. A manual fix & restart, and the Postfix errors went away.
The /etc/mailinabox.conf file lists the correct IPv4 and (?)IPv6 addresses as PUBLIC and PRIVATE addresses, so, I think it’s okay now? Does anyone have a trustworthy test site for mail intentionally across IPv6?
In any event, the suggested improvement is to amend the setup guide to encourage/require IPv6, or alter the setup script to disable IPv6 in the subsystems’ configurations as an option.
For IPv6 tests, I use https://en.internet.nl/ - it does reasonable checks of your IPv6 function.
It does complain about some depreciated security settings, which MIAB allows, but as we’re receiving emails (some of which might have zero security) I’m happy with MIABs config and ignore those warnings.
For anyone using DigitalOcean hosting services to run MiaB, the following quotation from DO Support will be helpful:
We currently block all IPv6 SMTP traffic so setting reverse DNS won’t allow you to use the IPv6 address to send an email. We suggest using an IPv4 Droplet for hosting a mail server. Alternatively, you can edit the /etc/gai.conf file to prioritize IPv4. You will want to remove the comment (#) from the following line: #precedence ::ffff:0:0/96 100
We prioritize IPv4, which has worked very well. This might be useful on other hosting platforms also.
If you want to use ipv6 make sure you don’t share the /64 subnet with somebody else, in my case (OVH vps) they gave me a single ipv6 address, and my mails weren’t going through because another address in the range was blacklisted, see this report by Spamhaus:
According to current agreed upon standards, any given /64 is intended to be one single entity.
The industry standard for the smallest IPv6 allocation to individual customers, even for home-uses like cable, DSL or wireless is a /64.
Some providers choose to not follow the industry standard, and allocate smaller subnets. As a result, you are sharing the same network segment as other customers, which can include problematic ones.
This non-standard allocation practice can result in IPv6 IPs being listed in CSS because of neighboring IPs that share the same /64 - contrary to industry standard.
NOTE: If your allocation is smaller than /64, we cannot remove it from CSS, and the situation needs to be corrected with the provider prior to requesting removal. For more information about IPv6, IP allocation, and industry standards, please see our FAQ.