sendmail snapshot 8.19.0.2 is available for testing. It has two new
FFRs: _FFR_EKU_NOCLIENTAUTH: override cert restrictions and _FFR_KEX:
log key-exchange algorithm (TLS) and also a new option: TLSEC.
sendmail snapshot 8.19.0.2 is available for testing. It has two new
FFRs: _FFR_EKU_NOCLIENTAUTH: override cert restrictions and _FFR_KEX:
log key-exchange algorithm (TLS) and also a new option: TLSEC.
sendmail snapshot 8.19.0.2 is available for testing. It has two new
FFRs: _FFR_EKU_NOCLIENTAUTH: override cert restrictions and _FFR_KEX:
log key-exchange algorithm (TLS) and also a new option: TLSEC.
fbsd15:~/c/sendmail-8.19.0.2 $ cc --versionFreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git llvmorg-19.1.7-0-gcd708029e0b2)
Claus A|fmann <INVALID_NO_CC_REMOVE_IF_YOU_DO_NOT_POST_ml+sendmail(-no-copies-please)@esmtp.org> wrote:
sendmail snapshot 8.19.0.2 is available for testing. It has two new
FFRs: _FFR_EKU_NOCLIENTAUTH: override cert restrictions and _FFR_KEX:
log key-exchange algorithm (TLS) and also a new option: TLSEC.
It builds on OmniOS latest stable (Open Solaris descendant based on
illumos kernel):
In function rCysm_strlcpyrCO,
inlined from rCysm_errstringrCO at err.c:1238:9:
../libsm/strl.c:70:28: warning: rCystrlenrCO reading 1 or more bytes from
a region of size 0 [-Wstringop-overread]
70 | return i + strlen(src + i);
Kalevi Kolttonen wrote:
In function |o??sm_strlcpy|o??,
inlined from |o??sm_errstring|o?? at err.c:1238:9:
../libsm/strl.c:70:28: warning: |o??strlen|o?? reading 1 or more bytes from >> a region of size 0 [-Wstringop-overread]
70 | return i + strlen(src + i);
Seems like a bogus warning.
if (src[i] == '\0')
return i;
else
return i + strlen(src + i);
In the "else" case src[i] is not '\0',
hence there is at least one non-NUL char in src+i.
It has been running flawlessly since I installed it and
Kalevi Kolttonen wrote:
It has been running flawlessly since I installed it and
Thanks for the info!
Do you see any PQC key_exchange algorithm in your logs
(e.g., X25519MLKEM768)?
Have you enabled overriding EKU restrictions?
Does it work as expected?
Do you see any PQC key_exchange algorithm in your logs
(e.g., X25519MLKEM768)?
Does it work as expected?
Have you enabled overriding EKU restrictions?
Claus A|fmann <INVALID_NO_CC_REMOVE_IF_YOU_DO_NOT_POST_ml+sendmail(-no-copies-please)@esmtp.org> wrote:
Have you enabled overriding EKU restrictions?
How do I do it? I have compiled with the required _FFR.
EHLO fedora.local<~ 250-omnios.local Hello fedora.local [192.168.1.154], pleased to meet you
MAIL FROM:<kalevi@fedora.local><~ 250 2.1.0 <kalevi@fedora.local>... Sender ok
RCPT TO:<kalevi@kolttonen.fi><~* 550 5.7.1 <kalevi@kolttonen.fi>... Relaying denied
QUIT<~ 221 2.0.0 omnios.local closing connection
Again, If I understood correctly, using 'O' should make exceptions
for clients that offer server EKU cert. This is what I have in my
access.db:
root@omnios:/etc/mail# cat access
TLS_Srv_Features:192.168.1.154 O
TLS_Srv_Features:fedora.local O
Srv_Features:192.168.1.154 v CertIssuer:/C=FI/ST=Uusimaa/L=Helsinki/O=Home/CN=fedora.local RELAY
Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
Again, If I understood correctly, using 'O' should make exceptions
for clients that offer server EKU cert. This is what I have in my
access.db:
root@omnios:/etc/mail# cat access
TLS_Srv_Features:192.168.1.154 O
TLS_Srv_Features:fedora.local O
Srv_Features:192.168.1.154 v
CertIssuer:/C=FI/ST=Uusimaa/L=Helsinki/O=Home/CN=fedora.local RELAY
Well, I guess the sendmail.cf expects 'TLS_Srv' and
not 'TLS_Srv_Features':
root@omnios:/etc/mail# grep -i tls_s sendmail.cf
### tls_server: is connection with server "good" enough?
Stls_server
R$* $: $1 $| $>D <$&{server_name}> <?> <! "TLS_Srv"> <>
R$* $| <?>$* $: $1 $| $>A <$&{server_addr}> <?> <! "TLS_Srv"> <>
R$* $| <?>$* $: $1 $| <$(access "TLS_Srv": $: ? $)>
So I modified my access.db:
root@omnios:/etc/mail# cat access
TLS_Srv:192.168.1.154 O
TLS_Srv:fedora.local O
Srv_Features:192.168.1.154 v CertIssuer:/C=FI/ST=Uusimaa/L=Helsinki/O=Home/CN=fedora.local RELAY
and rebuilt the DB. But still relaying denied...
No! I was missing FEATURE(`tls_session_features'), now I can
see the ruleset Stls_srv_features and as far as I can tell, it
queries access.db using 'TLS_Srv_Features'. So I am back where
I started:
root@omnios:/etc/mail# cat access
TLS_Srv_Features:192.168.1.154 O
TLS_Srv_Features:fedora.local O
Srv_Features:192.168.1.154 v CertIssuer:/C=FI/ST=Uusimaa/L=Helsinki/O=Home/CN=fedora.local RELAY
Still, relaying denied. I am giving up for tonight.
STARTTLS=server, relay=fedora.local [192.168.1.154], version=TLSv1.3, verify=OK, cipher=TLS_AES_256_GCM_SHA384, bits=256/256,
key_exchange=ECDHE, eku=overrode_no_client_auth
Kalevi Kolttonen wrote:
STARTTLS=server, relay=fedora.local [192.168.1.154], version=TLSv1.3,
verify=OK, cipher=TLS_AES_256_GCM_SHA384, bits=256/256,
key_exchange=ECDHE, eku=overrode_no_client_auth
Thanks for giving this a try, sorry for not providing (better)
documentation (yet).
Which OpenSSL version do you use?
With 3.5ff you should get something like
key_exchange=X25519MLKEM768
(PQC)
root@omnios:~# openssl list -tls-groups secp256r1:secp384r1:secp521r1:x25519:x448:brainpoolP256r1tls13:brainpoolP384r1tls13:brainpoolP512r1tls13:ffdhe2048:ffdhe3072:ffdhe4096:ffdhe6144:ffdhe8192:MLKEM512:MLKEM768:MLKEM1024:SecP256r1MLKEM768:X25519MLKEM768:SecP384r1MLKEM1024
root@fedora:~# openssl list -tls-groups secp256r1:secp384r1:secp521r1:x25519:x448:brainpoolP256r1tls13:brainpoolP384r1tls13:brainpoolP512r1tls13:ffdhe2048:ffdhe3072:ffdhe4096:ffdhe6144:ffdhe8192:MLKEM512:MLKEM768:MLKEM1024:SecP256r1MLKEM768:X25519MLKEM768:SecP384r1MLKEM1024
I ran OpenSSL server on OmniOS:
root@omnios:/etc/mail/certs# cat f
openssl s_server -accept 8443 -key omnios.local.key -cert omnios.local.crt
Connected to it with:
openssl s_client -connect omnios.local:8443 -groups X25519MLKEM768
Connection worked, so maybe this has something to do with Sendmail configuration or code.
I tested a small patch:
===============================================================================
diff -urN sendmail-8.19.0.2/sendmail/tls.c sendmail-8.19.0.2-patch/sendmail/tls.c
--- sendmail-8.19.0.2/sendmail/tls.c 2026-07-09 20:47:18.544514740 +0300 +++ sendmail-8.19.0.2-patch/sendmail/tls.c 2026-07-09 20:47:26.068638009 +0300
@@ -1692,6 +1692,11 @@
if (kf2 != NULL)
*--kf2 = ',';
+ if (!SSL_CTX_set1_groups_list(*tls_ctx, "X25519MLKEM768:X25519")) {
+ abort();
+ }
+ sm_syslog(LOG_INFO, NOQID, "SSL_CTX_set1_groups_list() success");
+
return ok;
}
===============================================================================
Having TLS_EC=0 in conf_sendmail_ENVDEF in devtools/Site/site.config.m4
fixes the problem and enables Sendmail to use OpenSSL defaults. Then PQC
key exchange works:
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 74 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 02:28:22 |
| Calls: | 1,194 |
| Files: | 1,353 |
| D/L today: |
2 files (1,590K bytes) |
| Messages: | 291,157 |