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







Reply via email to