Alter postfix config to use public IPv6 address for outbound mails

[nugget]

This change alters the Postfix configuration to use the public IPv6 address instead of the private IPv6 address when sending outbound mails over IPv6.

I'm not sure what the reasoning was for the current method. If there are use cases which require the private IPv6 to be used for outbound emails over IPv6 then this PR will need to be extended to allow this to be a configurable choice.

This PR will fix #1738 which is the exact scenario which led to me discovering the problem.

I'm happy to make this PR more involved/optionally configured if some users need to be able to retain the original behavior. I have a suspicion, though, that this is the desired behavior in all cases. What would the use-case be where the user wants Postfix to use the private IPv6 address which will not be covered by "spf -mx" and which (in the case of a hosted VPS provider like Linode) is much more likely to be un-avoidably listed in smtp blackholes like spamhaus XBL/CSS or equivalent which apply to the entire /64 which might be shared among multiple customers at the hosting provider.

I'm not aware of any hosting provider that does address translation with IPv6 the way NAT is employed with IPv4 and such a configuration would be at best strongly discouraged. The private/public distinction doesn't make sense with IPv6 to me at all.

[JoshData]

The purpose of the PRIVATE_IPV6 variable is to be the address of the ethernet interface that local services should bind to. This might differ from how the service is seen on the public Internet, which is why there are two variables, although my working knowledge of IPv6 is limited so I'm just assuming this aspect is similar to IPv4.

To get postfix (and other local services) to bind on a particular address, the right thing to do would be to set that address to the PRIVATE_IPV6 variable. (It can be the same as PUBLIC_IPV6.)

Would that solve the issue?

[nugget]

I understand completely the utility and necessity for PRIVATE_IPV4 and PUBLIC_IPv4. Mandatory NAT -- even in 1-to-1 configurations -- is certainly a common setup in the IPv4 world.

"Address independence" via translation like we see in IPv4 is strongly discouraged and extremely uncommon in IPv6. I've certainly never encountered it in the real world, although I'd be reluctant to say that it's not in use anywhere. It's technically possible, but it's discouraged by the IETF. They have this to say on the subject:

There are significant technical impacts associated with the deployment of any address translation mechanism, including NAT66, and we strongly encourage anyone who is considering the implementation or deployment of NAT66 to read RFC 4864 [RFC4864], and to carefully consider the alternatives described in that document, some of which may cause fewer problems than NAT66.

You're right that forcing my correct public IPv6 address to into the confusingly named "PRIVATE_IPv6" configuration setting would also "fix the glitch". That feels like an anti-pattern to me because it requires placing the user's correct public IPv6 address address into a PRIVATE_IPV6 variable in the configuration which is not accurate or intuitive.

I didn't pursue a solution along those lines because I also found that re-running setup sudo mailinabox does not allow me to do what you're suggesting. it will over-write any attempt to place my public IPv6 address into the PRIVATE_IPv6 variable in /etc/mailinabox.conf. Re-running setup always sets PRIVATE_IPv6 to one of my other public IPv6 addresses which is not the correct outbound SMTP address.

If we go that direction I think we'll need to amend the setup process (questions.py?) to allow greater flexibility. I'm happy give that a shot if you prefer and I'll try to come up with a setup path that is more aligned with IPv6 best practices, but I worry about scope creep with that approach. I also suspect the vast majority of users who face this issue will end up with PRIVATE_IPv6 containing their true public IP, and PUBLIC_IPv6 being an undesired public address. Feels weird, but it'll work. It might make sense to avoid using "public/private" terminology in the UI, though, since that's likely to be inaccurate and lead to user confusion.

Just to add some clarity and a real world situation, here's what Linode shared-hosting Mail-in-a-Box users encounter. My boxes all provision with a public IPv6 address which is inside a shared subnet (::/64). I can't reliably use this address for outbound emails because anti-spam blocklists may be correctly blocking this entire subnet due to the behavior of other customers. There's no remedy for that. To avoid this, I provision an entire subnet I control completely and then route that public subnet to the box as well. Then I bind to an address within that subnet for outbound SMTP. This allows a bind address that's within a subnet completely under the user's control and therefore safe for outbound SMTP. Both addresses are public and routable.

Again, I'm happy to head off in whatever direction you'd prefer. I'm mostly just interested in getting to a place where I can safely upgrade and re-run setup on my machines without having to make code changes each time.

[nugget]

Breaking this off for clarity, I propose expanding the setup questions.sh behavior to do this:

• If the "Public IPv6 address" chosen by the user in setup/questions.sh exists as an address on the machine, it will be placed in both the PUBLIC_IPv6 and PRIVATE_IPv6 variables in mailinabox.conf.
• If the "Public IPv6 address" is not detected as a local address on the machine, the current setup behavior will remain unchanged.

I think this is the cleanest approach for now, although it would be great to re-visit how all this is handled in the future if/when ongoing development naturally leads to work on this code in a broader scope.

How does that sound?

[JoshData]

confusingly named "PRIVATE_IPv6" configuration setting

Yeah think of it as the traditional "bind" setting with a name that was intended to make it more friendly for users who aren't familiar with socket terminology.

[nugget]

Probably SOURCE_IPv6 makes more sense but that feels like a change for another day.