EAFNOSUPPORT errors when IPv6 is disabled on server

[lnedry]

Starting with Haraka 3.0.4, when an IPv4 only server tries to send an email to an MX listening on both IPv4 and IPv6, it gets an error:
[outbound] Failed to get socket: connect EAFNOSUPPORT 2607:f8b0:4023:1002::1b:25 - Local (undefined:undefined)

Also, if this IPv4 only server tries to start up with listen=[::0]:25 in config/smtp.ini then it will get these errors:

[server] Failed to setup listeners: bind EAFNOSUPPORT ::0:25
[server] Error: bind EAFNOSUPPORT ::0:25
    at listenOnPrimaryHandle (node:net:1970:18)
    at rr (node:internal/cluster/child:163:12)
    at Worker.<anonymous> (node:internal/cluster/child:113:7)
    at process.onInternalMessage (node:internal/cluster/utils:49:5)
    at process.emit (node:events:531:35)
    at emit (node:internal/child_process:951:14)
    at process.processTicksAndRejections (node:internal/process/task_queues:83:21) {
  errno: -97,
  code: 'EAFNOSUPPORT',
  syscall: 'bind',
  address: '::0',
  port: 25
}

I expect that Haraka, when starting, would throw an error if smtp.ini has it listening on an IPv6 address when IPv6 is not supported.
I also expect that Haraka would test if IPv6 is supported when trying to connect to remote MX that is listening on IPv6 and ignore that MX in favor of one listening on IPv4.

This is easy to reproduce. This server has IPv6 disabled and has Haraka listening on a single IPv4 address, e.g. 1.2.3.4:25.
Postfix is listening on 127.0.0.1:25.

Haraka	Haraka.js — Version: 3.0.4
Node	v20.15.0
OS	Linux daisy.bluestreak.net 6.1.0-20-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11) x86_64 GNU/Linux
openssl	OpenSSL 3.0.13 30 Jan 2024 (Library: OpenSSL 3.0.13 30 Jan 2024)

[msimerson]

Haraka's IPv6 has always worked poorly like that, but it rarely showed up because it always tried IPv4 first. When I updated get_mx, I switched that preference to be IPv6 first, an arguable choice, but I think good since IPv6 is at half adoption and everything new should be provisioned on IPv6.

One potential fix is to check for a bound IPv6 address at startup and set a property. If that property is false, we shouldn't try delivery to IPv6 addresses.

[msimerson]

I don't have time to follow up on this right now, but here's a little snippet we can/should run when starting up Haraka:

#!/usr/local/bin/node

const os = require('os')
let hasIP = {}

for (const [ifName, ifObj] of Object.entries(os.networkInterfaces())) {
  for (const addr of ifObj) {
    if (addr.family === 'IPv6') {
      if (!hasIP.v6) hasIP.v6=true;
    }
    else if (addr.family === 'IPv4') {
      if (!hasIP.v4) hasIP.v4=true;
    }
    else {
      console.error(addr)
    }
  }
}
console.log(hasIP)

 ➜ node has_ip.js
{ v4: true, v6: true }