Connection to ipv6

get-help
1

Hi guys, I’m having some error logs in journalctl where kumo tries to bind an ipv4 adress to ipv6
kumod::egress_source: bind 10.133.68.104 for source:COG74.68 failed: Invalid argument (os error 22) while attempting to connect to [2a0a:fc80::1:11]:25
The transient message has the ipv4 address but it’s trying the ipv6
400 .. KumoMTA internal: failed to connect to any candidate hosts: ResolvedAddress { name: 'mx1.hrnet.fr.', addr: 212.94.223.189 }:25: EHLO after OpportunisticInsecure STARTTLS handshake status: failed: received fatal alert: HandshakeFailure: Not connected, connect to ResolvedAddress { name: 'mx1.hrnet.fr.', addr: 2a0a:fc80::1:10 } port 25 and read initial banner: bind 10.133.68.104 for source:COG74.68 failed: Invalid argument (os error 22) while attempting to connect to [2a0a:fc80::1:10]:25, ResolvedAddress { name: 'mx2.hrnet.fr.', addr: 212.94.223.190 }:25: EHLO after OpportunisticInsecure STARTTLS handshake status: failed: received fatal alert: HandshakeFailure: Not connected, connect to ResolvedAddress { name: 'mx2.hrnet.fr.', addr: 2a0a:fc80::1:11 } port 25 and read initial banner: bind 10.133.68.104 for source:COG74.68 failed: Invalid argument (os error 22) while attempting to connect to [2a0a:fc80::1:11]:25

2

I’m not sure that this is really an error, but rather a hard to read error message because a lot is packed into it.

If you split it around the ResolvedAddress portions it is a little clearer what is happening:

The overall status:

400 .. KumoMTA internal: failed to connect to any candidate hosts:

First we tried the preference=5 mx:

We try the A record first, which fails because there is some kind of issue with their TLS configuration:

ResolvedAddress { name: 'mx1.hrnet.fr.', addr: 212.94.223.189 }:25: EHLO after OpportunisticInsecure STARTTLS handshake status: failed: received fatal alert: HandshakeFailure: Not connected,

Then we try the AAAA record, which doesn’t work with the configured IPv4 source address; this outcome is OK and expected and isn’t a problem on its own:

connect to ResolvedAddress { name: 'mx1.hrnet.fr.', addr: 2a0a:fc80::1:10 } port 25 and read initial banner: bind 10.133.68.104 for source:COG74.68 failed: Invalid argument (os error 22) while attempting to connect to [2a0a:fc80::1:10]:25,

Now the preference=10 mx, which has the same issues

ResolvedAddress { name: 'mx2.hrnet.fr.', addr: 212.94.223.190 }:25: EHLO after OpportunisticInsecure STARTTLS handshake status: failed: received fatal alert: HandshakeFailure: Not connected,

connect to ResolvedAddress { name: 'mx2.hrnet.fr.', addr: 2a0a:fc80::1:11 } port 25 and read initial banner: bind 10.133.68.104 for source:COG74.68 failed: Invalid argument (os error 22) while attempting to connect to [2a0a:fc80::1:11]:25
3

The real problem is the TLS config on the destination. I tried to connect to it manually:

$ openssl s_client -starttls smtp -crlf -4 -connect mx1.hrnet.fr:25

CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = mx1.hrnet.fr
verify return:1
40375500D57F0000:error:0A00018A:SSL routines:tls_process_ske_dhe:dh key too small:../ssl/statem/statem_clnt.c:2086:
---
...
---
New, (NONE), Cipher is (NONE)
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1705496028
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---
4

interestingly, that dropped me right back to my shell prompt afterwards, even though the output doesn’t look too bad. I think that host may have a configuration problem; perhaps they have mismatched public/private keys or something like that?

5

We treat a STARTTLS failure as a connection failure, and we won’t continue to connect to a host in clear text if there is an issue with its TLS config, even though we are in opportunistic mode.

Opportunistic mode for kumomta means:

  • If they advertise TLS, try to use it.
  • Proceed with clear text only if TLS is not advertised.

OppotunisticInsecure is similar except that we tolerate insecure configurations of TLS (eg: self signed certs, name mismatches, outdated certs).

However, in this case, it seems like the TLS setup is too broken to proceed, so we can’t use that host.

6

What can you do about this? I would suggest configuring that domain as enable_tls = "Disabled" and try to reach their postmaster to mention that there is some issue with the TLS setup there

7

I thought OppotunisticInsecure could help bypass this, I’ll disable tls for this domain for now, thanks a lot for the explanation !

8

you’re welcome! I think we could try to do something to make a log entry like this a bit easier to understand at first glance.