So, on the BALUG VM (hosting balug.org, sf-lug.org & berkelug.com. (except list on those latter two), many additional domains, DNS primaries for all those, additional secondaries, etc.

So, IP addresses: $ (for IP in 10.1.10.109 96.86.170.229 2001:470:1f04:19e::2 2001:470:1f05:19e::2 2001:470:1f05:19e::3 2001:470:1f05:19e::4 2001:470:1f05:19e::5 2001:470:1f05:19e::6 2001:470:1f05:19e::7 2001:470:1f05:19e::8 2001:470:1f05:19e::9 2001:470:1f05:19e::a 2603:3024:1b29:0:5054:ff:fe13:5199; do echo "$IP" $(dig @ns1.google.com. -b "$IP" +short o-o.myaddr.l.google.com. TXT | tr -d '"'); done) 10.1.10.109 96.86.170.230 96.86.170.229 96.86.170.229 2001:470:1f04:19e::2 2001:470:1f04:19e::2 2001:470:1f05:19e::2 2001:470:1f05:19e::2 2001:470:1f05:19e::3 2001:470:1f05:19e::3 2001:470:1f05:19e::4 2001:470:1f05:19e::4 2001:470:1f05:19e::5 2001:470:1f05:19e::5 2001:470:1f05:19e::6 2001:470:1f05:19e::6 2001:470:1f05:19e::7 2001:470:1f05:19e::7 2001:470:1f05:19e::8 2001:470:1f05:19e::8 2001:470:1f05:19e::9 2001:470:1f05:19e::9 2001:470:1f05:19e::a 2001:470:1f05:19e::a 2603:3024:1b29:0:5054:ff:fe13:5199 2603:3024:1b29:0:5054:ff:fe13:5199 $ dig -4 @ns1.google.com. +short o-o.myaddr.l.google.com. TXT | tr -d '"' 96.86.170.229 $ dig -6 @ns1.google.com. +short o-o.myaddr.l.google.com. TXT | tr -d '"' 2603:3024:1b29:0:5054:ff:fe13:5199 $ Recently started adding more. Some of the motivations: Had some recent minor glitches between Hurricane Electric (HE.net, tunnelbroker.net) IPv6 IPs and AT&T (att.com) IPv6 IPs. I've also got Comcast Business IPv6 IPs potentially available to me (my current ISP), but for the most part hadn't been using those. Longer term will likely move to AT&T, but in the meantime. So, started adding those, not yet all that significantly pressed into service, but mostly set. Just add relevant statics, DNS entries, etc., and good to go. And checking side-by-side, the HE.net/tunnelbroker.net IPs perform very surprisingly well - even with their tunneling, latency and number of hops, almost indistinguishable. And the up-front prep work will make later transitioning to AT&T IPs that much simpler.

Also, changed the Mail Transport Agent (MTA) from exim4 to Postfix. There were multiple motivations on that, including: exim4 just wasn't cutting it anymore. Most notably, though exim4 has configuration for source IP(s) for SMTP send, it just doesn't work. I'd mostly kludged around that, by it / the routing generally using by default, source of the last (IPv4 or IPv6) IP address added, but that was no longer sufficient and had bitten me multiple times before. Though it's documented - it just plain doesn't work - and all the research basically pointed to same, and I certainly wasn't the only one to switch from exim4 to Postix to get a proper working solution. Additionally, exim4 has still no capabilities for per-domain aliasing. Very annoying, as that means if there's rsvp@balug.org, then the alias for that also applies to rsvp@lists.balug.org, and any other mail domains too - not at all what's desired. So, with Postfix, can well separate those out. Furthermore, part of the anti-spam configuration I'd been using with exim4 was highly outdated and not being maintained, and a bit fragile and crusty, so, also good to get away from that, and dropping exim4 was also a cleaner simpler way to do that. And, yet another advantage, mailman3 well supports two MTAs, Postfix and exim, but it better supports and default configurations support Postix, so, even simpler to deal with mailman3 on Postfix than exim4. So, all those reasons, quite overdue to switch to Postfix, and have now done so. And well tested on the BALUG-Test list too. Most all changes were also first tested on a test VM (balug13) too, before being implemented on the production VM (balug).

In the bit of example testing further above, can see for each of many source IPs, that for all of them we can see that they not only route properly, but the server in fact sees the expected source IP address, (same IP, excepting the one v4 behind NAT/SNAT) and likewise also with default source for v4 and v6 - though on the latter I may or may not want to change what that default is. But with MTA and DNS using their proper source IP addresses for their services, in those case, doesn't much matter what the defaults are when the sources are set properly when used for the services, most notably source IP on MTA when it sends or attempts to send email.

So, fair bit of cleanup and improvements on that infrastructure, and helps well clear the way for more.