I just did a cursory review of your log, but it looks to me that it
simply cannot connect to your endpoint. So the culprit is probably not
smtpd, after all.
Can you actually reach that endpoint? Like maybe try manually from the
source server with e.g.: telnet -6 blackblock.22decembre.eu 10027
Does it even connect?
On Sun, Dec 14, 2025 at 11:29:51AM +0100, Stéphane Guedon wrote:
Hi.
I take on debugging again on that. Thanks for previous participants.
For reminders : I cannot connect to my main mail server from the
backup. The main mail server (blackblock) is listening on on ipv6 on a
dedicated port and I can see that a connection is possible (no
blockage from firewalls).
And yet, I got this :
debug: mta-routing: skipping host 89.150.157.50: AF mismatch
debug: mta-routing: skipping route [2603:c026:306:9211::300] <->
[2a05:f6c7:de1::2] (blackblock): not validated yet
debug: mta: hit route limit
debug: mta-routing: no route available for [connector:[2603:c026:306:9211::300]->[relay:blackblock.22decembre.eu,port=10027,smtps,pki_name=dina,mx,sourcetable=<dynamic:2>],0x0]:
limits reached
debug: mta: retrying to connect on [connector:[2603:c026:306:9211::300]->[relay:blackblock.22decembre.eu,port=10027,smtps,pki_name=dina,mx,sourcetable=<dynamic:2>],0x0]
in 5s...
debug: mta: draining [relay:blackblock.22decembre.eu,port=10027,smtps,pki_name=dina,mx,sourcetable=<dynamic:2>]
refcount=2, ntask=17, nconnector=1, nconn=1
debug: mta: scheduling relay [relay:blackblock.22decembre.eu,port=10027,smtps,pki_name=dina,mx,sourcetable=<dynamic:2>]
in 10s...
debug: mta: ... timeout for [connector:[2603:c026:306:9211::300]->[relay:blackblock.22decembre.eu,port=10027,smtps,pki_name=dina,mx,sourcetable=<dynamic:2>],0x20000]
debug: mta: connecting with [connector:[2603:c026:306:9211::300]->[relay:blackblock.22decembre.eu,port=10027,smtps,pki_name=dina,mx,sourcetable=<dynamic:2>],0x0]
This was when trying to send mail from dina (backup server) to blackblock.
I tried to do this in smtps, smtp+tls (eg starttls) or even smtp
(without tls security) and it still fails.
Any more suggestions ?
On 10.12.2025 23.45, Crystal Kolipe wrote:
On Wed, Dec 10, 2025 at 10:51:00PM +0100, Stphane Guedon wrote:
16373541939144:error:1404C45C:SSL routines:ST_OK:tlsv13 alert certificate
required:/usr/src/lib/libssl/tls13_lib.c:167:SSL alert number 116
dina$
I don't know if the last line is normal though.
Presumably this was after you added 'verify' to the listener, because this
error is caused by the client not providing a client cert when the server
expects one.
I guessed so, so I was not so worried
You can provide it using the -cert and -key options to openssl s_client, if
you want to test further.
However, you are using the IP address directly in the action directive instead
of using a hostname:
action "relay" relay host smtp+tls://[2a05:f6c7:de1::2]:10027 pki dina tls
protocols secure src 2603:c026:306:9211:f:10d:c:9f55
... but the server certificate doesn't have this IP address in it's SAN field.
Have you tried using the hostname here?
I.E.
action "relay" relay host smtp+tls://blackblock.22decembre.eu:10027 pki dina tls
protocols secure src 2603:c026:306:9211:f:10d:c:9f55
Yes