Problem with FEATURE(`sts'): bogus "not listed in SANs" rejects

[Bjørn Mork]

I have been testing out the MTA-STS support for a while, using the
Debian sendmail package 8.17.1.9-2+deb12u2 with postfix-mta-sts-resolver
to look up policies.

This seemed to work pretty well, but yesterday I noticed a problem: Some
emails were temporarily rejected with an unexpected "not listed in SANs"
message. This was unexpexted because most of the affected emails were
for MXes hosted by Microsoft and their "protection.outlook.com" service.

Anonymzed example log lines:

Oct 27 19:49:47 dilbert sm-mta[1589041]: 49N8ZWuJ1287620: ruleset=tls_rcpt, arg1=***@hotmail.com, relay=hotmail-com.olc.protection.outlook.com., reject=450 4.7.0 <***@hotmail.com>... hotmail-com.olc.protection.outlook.com not listed in SANs
Oct 27 19:54:49 dilbert sm-mta[1589264]: 493ISGKc649896: ruleset=tls_rcpt, arg1=***@outlook.com, relay=outlook-com.olc.protection.outlook.com., reject=450 4.7.0 <***@outlook.com>... outlook-com.olc.protection.outlook.com not listed in SANs


The smarthost handles only a very low volume, and most MXes don't have a
MTA-STS policy obviously. But amond those few, there was also a similar
reject for a non-Microsoft hosted MX:


Oct 27 19:24:48 dilbert sm-mta[1587923]: 49JAD2Eb1019895: ruleset=tls_rcpt, arg1=***@01-mail.org, relay=mx.01-mail.net., reject=450 4.7.0 <***@01-mail.org>... mx.01-mail.net not listed in SANs


There were also a few examples of MXes publishing a policy and still
working fine. This included my own MX as well as Googles:

alt1.gmail-smtp-in.l.google.com
alt2.gmail-smtp-in.l.google.com
alt3.gmail-smtp-in.l.google.com
alt4.gmail-smtp-in.l.google.com
gmail-smtp-in.l.google.com


Looking at the certificates I see that the most obvious difference is
the use of wildcard SANs. Both the certficate of my MX and Googles
explicitly list all their names, using no wildcards at all:

X509v3 Subject Alternative Name:
DNS:canardo.dyn.mork.no, DNS:canardo.mork.no, DNS:imap.mork.no, DNS:mail.mork.no, DNS:smtp.mork.no


X509v3 Subject Alternative Name:
DNS:mx.google.com, DNS:smtp.google.com, DNS:aspmx.l.google.com, DNS:alt1.aspmx.l.google.com, DNS:alt2.aspmx.l.google.com, DNS:alt3.aspmx.l.google.com, DNS:alt4.aspmx.l.google.com, DNS:gmail-smtp-in.l.google.com, DNS:alt1.gmail-smtp-in.l.google.com, DNS:alt2.gmail-smtp-in.l.google.com, DNS:alt3.gmail-smtp-in.l.google.com, DNS:alt4.gmail-smtp-in.l.google.com, DNS:gmr-smtp-in.l.google.com, DNS:alt1.gmr-smtp-in.l.google.com, DNS:alt2.gmr-smtp-in.l.google.com, DNS:alt3.gmr-smtp-in.l.google.com, DNS:alt4.gmr-smtp-in.l.google.com, DNS:mx1.smtp.goog, DNS:mx2.smtp.goog, DNS:mx3.smtp.goog, DNS:mx4.smtp.goog, DNS:aspmx2.googlemail.com, DNS:aspmx3.googlemail.com, DNS:aspmx4.googlemail.com, DNS:aspmx5.googlemail.com, DNS:gmr-mx.google.com


While both the failing MXes use certificates with multiple wildcard
SANs:

X509v3 Subject Alternative Name:
DNS:mail.protection.outlook.com, DNS:*.mail.eo.outlook.com, DNS:*.mail.protection.outlook.com, DNS:mail.messaging.microsoft.com, DNS:outlook.com, DNS:*.olc.protection.outlook.com, DNS:*.pamx1.hotmail.com, DNS:*.mail.protection.outlook.de, DNS:*.mx.microsoft, DNS:*.k-v1.mx.microsoft, DNS:*.n-v1.mx.microsoft, DNS:*.q-v1.mx.microsoft, DNS:*.y-v1.mx.microsoft, DNS:*.d-v1.mx.microsoft, DNS:*.e-v1.mx.microsoft, DNS:*.a-v1.mx.microsoft, DNS:*.r-v1.mx.microsoft, DNS:*.w-v1.mx.microsoft, DNS:*.p-v1.mx.microsoft, DNS:*.x-v1.mx.microsoft, DNS:*.j-v1.mx.microsoft, DNS:*.s-v1.mx.microsoft, DNS:*.c-v1.mx.microsoft, DNS:*.b-v1.mx.microsoft, DNS:*.f-v1.mx.microsoft, DNS:*.i-v1.mx.microsoft, DNS:*.t-v1.mx.microsoft, DNS:*.m-v1.mx.microsoft, DNS:*.o-v1.mx.microsoft, DNS:*.g-v1.mx.microsoft, DNS:*.v-v1.mx.microsoft, DNS:*.h-v1.mx.microsoft, DNS:*.l-v1.mx.microsoft, DNS:*.u-v1.mx.microsoft

X509v3 Subject Alternative Name:
DNS:*.01-mail.com, DNS:*.01-mail.net, DNS:*.01-mail.org, DNS:01-mail.com, DNS:01-mail.net, DNS:01-mail.org


It's dangerous to draw conclusions based on so few samples, but this is
all I've got. Could there be a problem with FEATURE(`sts') related to
wildcard SANs? Either wildcard SANs in general, or maybe just when
there is more than one?

I see that there is code in cf/m4/proto.m4 which is supposed to do
wildcard matching, but I must admit that I am too clueless wrt m4 to
understand if this should work with the certificate examples above:

dnl check SAN for STS
SSTS_SAN
ifdef(`_STS_SAN', `dnl
R$* $: $&{server_name}
dnl exact match
R$={cert_altnames} $@ ok
# strip only one level (no recursion!)
R$-.$+ $: $2
dnl wildcard: *. or just .?
R *.$={cert_altnames} $@ ok
dnl R .$={cert_altnames} $@ ok
dnl always temporary error? make it an option (of the feature)?
R$* $#error $@ 4.7.0 $: 450 $&{server_name} not listed in SANs', `dnl')



I have not yet verified this problem on 8.18, but AFAICS the code I am
quoting above was introduced in 8.17.1 and has not been changed since.

The getaltnames() function in sendmail/tls.c, populating the
cert_altnames class has not been changed since it was introduced in
8.16.0.48.

Disabling the SAN test by doing

FEATURE(`sts',,`NO_SAN_TST')

is verified to "solve" the problem as expected. But obviously with the
huge downside of not actually validating the MX name.



Bjørn

[Bjørn Mork]

Noticed that getaltnames() can log the SANs as they are parsed, so I
yanked up the log level and registered an outlook.com address to test
against:

2024-10-29T09:29:30.283537+00:00 dilbert sm-mta[1697002]: STARTTLS=client, init=1
2024-10-29T09:29:30.283681+00:00 dilbert sm-mta[1697002]: engine=(null), path=(null), ispre=0, pre=0, initialized=0
2024-10-29T09:29:30.356523+00:00 dilbert sm-mta[1697002]: tls_clt_features=sts=secure;servername=hostname, relay=outlook-com.olc.protection.outlook.com [52.101.40.30]
2024-10-29T09:29:30.356694+00:00 dilbert sm-mta[1697002]: tls_clt_features=parsed, sts=secure, relay=outlook-com.olc.protection.outlook.com [52.101.40.30]
2024-10-29T09:29:30.356941+00:00 dilbert sm-mta[1697002]: tls_clt_features=parsed, servername=hostname, relay=outlook-com.olc.protection.outlook.com [52.101.40.30]
2024-10-29T09:29:30.510779+00:00 dilbert sm-mta[1697002]: STARTTLS=client, start=ok
2024-10-29T09:29:30.511540+00:00 dilbert sm-mta[1697002]: STARTTLS=client, info: fds=9/4, err=2
2024-10-29T09:29:30.668666+00:00 dilbert sm-mta[1697002]: STARTTLS=client, info: fds=9/4, err=2
2024-10-29T09:29:30.836892+00:00 dilbert sm-mta[1697002]: STARTTLS: TLS cert verify: depth=0 /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=mail.protection.outlook.com, state=1, reason=ok
2024-10-29T09:29:30.841735+00:00 dilbert sm-mta[1697002]: STARTTLS=client, get_verify: 0 get_peer: 0x55e6b9c7f290
2024-10-29T09:29:30.842307+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=mail.protection.outlook.com
2024-10-29T09:29:30.842615+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.mail.eo.outlook.com
2024-10-29T09:29:30.842825+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.mail.protection.outlook.com
2024-10-29T09:29:30.843017+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=mail.messaging.microsoft.com
2024-10-29T09:29:30.843226+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=outlook.com
2024-10-29T09:29:30.843430+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.olc.protection.outlook.com
2024-10-29T09:29:30.843659+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.pamx1.hotmail.com
2024-10-29T09:29:30.843864+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.mail.protection.outlook.de
2024-10-29T09:29:30.844063+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.mx.microsoft
2024-10-29T09:29:30.844125+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.k-v1.mx.microsoft
2024-10-29T09:29:30.844325+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.n-v1.mx.microsoft
2024-10-29T09:29:30.844424+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.q-v1.mx.microsoft
2024-10-29T09:29:30.844669+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.y-v1.mx.microsoft
2024-10-29T09:29:30.844778+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.d-v1.mx.microsoft
2024-10-29T09:29:30.844949+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.e-v1.mx.microsoft
2024-10-29T09:29:30.845107+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.a-v1.mx.microsoft
2024-10-29T09:29:30.845309+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.r-v1.mx.microsoft
2024-10-29T09:29:30.845370+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.w-v1.mx.microsoft
2024-10-29T09:29:30.845555+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.p-v1.mx.microsoft
2024-10-29T09:29:30.845606+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.x-v1.mx.microsoft
2024-10-29T09:29:30.845794+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.j-v1.mx.microsoft
2024-10-29T09:29:30.845849+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.s-v1.mx.microsoft
2024-10-29T09:29:30.846090+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.c-v1.mx.microsoft
2024-10-29T09:29:30.846178+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.b-v1.mx.microsoft
2024-10-29T09:29:30.846382+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.f-v1.mx.microsoft
2024-10-29T09:29:30.846576+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.i-v1.mx.microsoft
2024-10-29T09:29:30.846664+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.t-v1.mx.microsoft
2024-10-29T09:29:30.846758+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.m-v1.mx.microsoft
2024-10-29T09:29:30.846853+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.o-v1.mx.microsoft
2024-10-29T09:29:30.846913+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.g-v1.mx.microsoft
2024-10-29T09:29:30.846973+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.v-v1.mx.microsoft
2024-10-29T09:29:30.847045+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.h-v1.mx.microsoft
2024-10-29T09:29:30.847123+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.l-v1.mx.microsoft
2024-10-29T09:29:30.847223+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.u-v1.mx.microsoft
2024-10-29T09:29:30.847297+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., version=TLSv1.3, verify=OK, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
2024-10-29T09:29:30.847368+00:00 dilbert sm-mta[1697002]: STARTTLS=client, cert-subject=/C=US/ST=Washington/L=Redmond/O=Microsoft+20Corporation/CN=mail.protection.outlook.com, cert-issuer=/C=US/O=DigiCert+20Inc/CN=DigiCert+20Cloud+20Services+20CA-1, verifymsg=ok
2024-10-29T09:29:30.847428+00:00 dilbert sm-mta[1697002]: STARTTLS=read, info: fds=9/4, err=2
2024-10-29T09:29:30.996568+00:00 dilbert sm-mta[1697002]: STARTTLS=read, info: fds=9/4, err=2
2024-10-29T09:29:31.193337+00:00 dilbert sm-mta[1697002]: STARTTLS=read, info: fds=9/4, err=2
2024-10-29T09:29:31.350226+00:00 dilbert sm-mta[1697002]: 49T9TSAv1697000: --- 450 4.7.0 <***@outlook.com>... outlook-com.olc.protection.outlook.com not listed in SANs (hold)
2024-10-29T09:29:31.350353+00:00 dilbert sm-mta[1697002]: 49T9TSAv1697000: ruleset=tls_rcpt, arg1=***@outlook.com, relay=outlook-com.olc.protection.outlook.com., reject=450 4.7.0 <***@outlook.com>... outlook-com.olc.protection.outlook.com not listed in SANs
2024-10-29T09:29:31.350462+00:00 dilbert sm-mta[1697002]: 49T9TSAv1697000: --- 050 <***@outlook.com>... Deferred
2024-10-29T09:29:31.350545+00:00 dilbert sm-mta[1697002]: 49T9TSAv1697000: to=<***@outlook.com>, delay=00:00:02, xdelay=00:00:02, mailer=esmtp, pri=31187, relay=outlook-com.olc.protection.outlook.com. [52.101.40.30], dsn=4.2.0, stat=Deferred
2024-10-29T09:29:31.350631+00:00 dilbert sm-mta[1697002]: STARTTLS=read, info: fds=9/4, err=2
2024-10-29T09:29:31.508147+00:00 dilbert sm-mta[1697002]: NOQUEUE: --- 050 Closing connection to outlook-com.olc.protection.outlook.com.
2024-10-29T09:29:31.508386+00:00 dilbert sm-mta[1697002]: STARTTLS=read, info: fds=9/4, err=2
2024-10-29T09:29:31.662726+00:00 dilbert sm-mta[1697002]: STARTTLS=client, SSL_shutdown failed: -1


The SAN parsing looks fine to me, so I believe this points to a bug in
the m4 matching.

For reference, this is a similar test log against google:

2024-10-29T09:29:57.965992+00:00 dilbert sm-mta[1697008]: STARTTLS=client, init=1
2024-10-29T09:29:57.966067+00:00 dilbert sm-mta[1697008]: engine=(null), path=(null), ispre=0, pre=0, initialized=0
2024-10-29T09:29:57.970146+00:00 dilbert sm-mta[1697008]: tls_clt_features=sts=secure;servername=hostname, relay=gmail-smtp-in.l.google.com [IPv6:2a00:1450:4010:c05:0:0:0:1b]
2024-10-29T09:29:57.970286+00:00 dilbert sm-mta[1697008]: tls_clt_features=parsed, sts=secure, relay=gmail-smtp-in.l.google.com [IPv6:2a00:1450:4010:c05:0:0:0:1b]
2024-10-29T09:29:57.970406+00:00 dilbert sm-mta[1697008]: tls_clt_features=parsed, servername=hostname, relay=gmail-smtp-in.l.google.com [IPv6:2a00:1450:4010:c05:0:0:0:1b]
2024-10-29T09:29:57.974133+00:00 dilbert sm-mta[1697008]: STARTTLS=client, start=ok
2024-10-29T09:29:57.974858+00:00 dilbert sm-mta[1697008]: STARTTLS=client, info: fds=9/4, err=2
2024-10-29T09:29:57.981578+00:00 dilbert sm-mta[1697008]: STARTTLS: TLS cert verify: depth=0 /CN=mx.google.com, state=1, reason=ok
2024-10-29T09:29:57.982254+00:00 dilbert sm-mta[1697008]: STARTTLS=client, get_verify: 0 get_peer: 0x55e6b9c7d3d0
2024-10-29T09:29:57.982433+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=mx.google.com
2024-10-29T09:29:57.982779+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=smtp.google.com
2024-10-29T09:29:57.983537+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=aspmx.l.google.com
2024-10-29T09:29:57.983614+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=alt1.aspmx.l.google.com
2024-10-29T09:29:57.983671+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=alt2.aspmx.l.google.com
2024-10-29T09:29:57.984115+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=alt3.aspmx.l.google.com
2024-10-29T09:29:57.984576+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=alt4.aspmx.l.google.com
2024-10-29T09:29:57.984677+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=gmail-smtp-in.l.google.com
2024-10-29T09:29:57.984879+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=alt1.gmail-smtp-in.l.google.com
2024-10-29T09:29:57.984970+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=alt2.gmail-smtp-in.l.google.com
2024-10-29T09:29:57.985155+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=alt3.gmail-smtp-in.l.google.com
2024-10-29T09:29:57.985310+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=alt4.gmail-smtp-in.l.google.com
2024-10-29T09:29:57.985400+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=gmr-smtp-in.l.google.com
2024-10-29T09:29:57.985608+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=alt1.gmr-smtp-in.l.google.com
2024-10-29T09:29:57.985780+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=alt2.gmr-smtp-in.l.google.com
2024-10-29T09:29:57.985842+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=alt3.gmr-smtp-in.l.google.com
2024-10-29T09:29:57.985890+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=alt4.gmr-smtp-in.l.google.com
2024-10-29T09:29:57.986130+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=mx1.smtp.goog
2024-10-29T09:29:57.986191+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=mx2.smtp.goog
2024-10-29T09:29:57.986379+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=mx3.smtp.goog
2024-10-29T09:29:57.986450+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=mx4.smtp.goog
2024-10-29T09:29:57.986644+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=aspmx2.googlemail.com
2024-10-29T09:29:57.986705+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=aspmx3.googlemail.com
2024-10-29T09:29:57.986917+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=aspmx4.googlemail.com
2024-10-29T09:29:57.986982+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=aspmx5.googlemail.com
2024-10-29T09:29:57.987174+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=gmr-mx.google.com
2024-10-29T09:29:57.987232+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., version=TLSv1.3, verify=OK, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
2024-10-29T09:29:57.987423+00:00 dilbert sm-mta[1697008]: STARTTLS=client, cert-subject=/CN=mx.google.com, cert-issuer=/C=US/O=Google+20Trust+20Services/CN=WR2, verifymsg=ok
2024-10-29T09:29:57.987482+00:00 dilbert sm-mta[1697008]: STARTTLS=read, info: fds=9/4, err=2
2024-10-29T09:29:57.994383+00:00 dilbert sm-mta[1697008]: STARTTLS=read, info: fds=9/4, err=2
2024-10-29T09:29:58.000405+00:00 dilbert sm-mta[1697008]: STARTTLS=read, info: fds=9/4, err=2
2024-10-29T09:29:58.162462+00:00 dilbert sm-mta[1697008]: STARTTLS=read, info: fds=9/4, err=2
2024-10-29T09:29:58.163402+00:00 dilbert sm-mta[1697008]: STARTTLS=read, info: fds=9/4, err=2
2024-10-29T09:29:58.366636+00:00 dilbert sm-mta[1697008]: 49T9Tu0F1697006: --- 050 <***@gmail.com>... Sent (OK 1730194198 38308e7fff4ca-2fcb45e2a01si27180301fa.310 - gsmtp)
2024-10-29T09:29:58.366769+00:00 dilbert sm-mta[1697008]: 49T9Tu0F1697006: to=<***@gmail.com>, delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=31200, relay=gmail-smtp-in.l.google.com. [IPv6:2a00:1450:4010:c05:0:0:0:1b], dsn=2.0.0, stat=Sent (OK 1730194198 38308e7fff4ca-2fcb45e2a01si27180301fa.310 - gsmtp)
2024-10-29T09:29:58.369046+00:00 dilbert sm-mta[1697008]: 49T9Tu0F1697006: done; delay=00:00:01, ntries=1
2024-10-29T09:29:58.369260+00:00 dilbert sm-mta[1697008]: NOQUEUE: --- 050 Closing connection to gmail-smtp-in.l.google.com.
2024-10-29T09:29:58.370012+00:00 dilbert sm-mta[1697008]: STARTTLS=read, info: fds=9/4, err=2
2024-10-29T09:29:58.373981+00:00 dilbert sm-mta[1697008]: STARTTLS=client, SSL_shutdown failed: -1



Bjørn

[HQuest]

I can confirm the problem exists with messages sent to outlook.com email
addresses. At first, I thought it would be a behavior change introduced
by openssl 3.4.0 (this was the last update I applied to this system),
however downgrading back to v3.3.2, and even going down to 3.0.15 gives
the same output. Unless this is a side effect of any possible patches
applied by upstream in their Sep 2024 releases.

[Bjørn Mork]

Post by HQuest
I can confirm the problem exists with messages sent to outlook.com email
addresses. At first, I thought it would be a behavior change introduced
by openssl 3.4.0 (this was the last update I applied to this system),
however downgrading back to v3.3.2, and even going down to 3.0.15 gives
the same output. Unless this is a side effect of any possible patches
applied by upstream in their Sep 2024 releases.

Thanks for confirming that I'm not crazy :-)

The patch below fixes the issue for me, but should probably go through
someone who knows what they are doing.


Bjørn
---
From a43bb19d2f26267f7098a114edc2c191f45e4286 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= <***@mork.no>
Date: Tue, 29 Oct 2024 12:17:04 +0100
Subject: [PATCH] cf: fix wildcard handling in STS_SAN rule
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

MXes with wildcard certificates would be rejected with a bogus
"not listed in SANs" error. Fix by rewriting the MX hostname
to its wildcard alternative, and then reattempt the SAN class
match.

Link: https://www.novabbs.com/computers/article-flat.php?id=1120&group=comp.mail.sendmail
Signed-off-by: Bjørn Mork <***@mork.no>
---
cf/m4/proto.m4 | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/cf/m4/proto.m4 b/cf/m4/proto.m4
index ff7eb0bedc2a..d143b42fbae9 100644
--- a/cf/m4/proto.m4
+++ b/cf/m4/proto.m4
@@ -2748,9 +2748,9 @@ R$* $: $&{server_name}
dnl exact match
R$={cert_altnames} $@ ok
# strip only one level (no recursion!)
-R$-.$+ $: $2
+R$-.$+ $: *.$2
dnl wildcard: *. or just .?
-R *.$={cert_altnames} $@ ok
+R$={cert_altnames} $@ ok
dnl R .$={cert_altnames} $@ ok
dnl always temporary error? make it an option (of the feature)?
R$* $#error $@ 4.7.0 $: 450 $&{server_name} not listed in SANs', `dnl')

[Claus Aßmann]

Unfortunately this has not yet been released:
8.18.2/8.18.2 202x/xx/xx
Fix matching of wildcard SANs in the experimental support
for SMTP MTA Strict Transport Security (MTA-STS).
Problem reported by Dilyan Palauzo.

Here's the current version of the ruleset:

dnl check SAN for STS
SSTS_SAN
ifdef(`_STS_SAN', `dnl
R$* $: $&{server_name}
# {server_name} does not have a trailing dot
# R$+. $1
dnl exact match
R$={cert_altnames} $@ ok
# strip one level up to first dot
R$~. . $+ .$2
dnl wildcard: *. not just .
R.$+ $: *.$1
R $={cert_altnames} $@ ok
dnl always temporary error? make it an option (of the feature)?
R$* $#error $@ 4.7.0 $: 450 $&{server_name} not listed in SANs', `dnl')

[Marco Moock]

Post by Claus Aßmann
8.18.2/8.18.2 202x/xx/xx
Fix matching of wildcard SANs in the experimental support
for SMTP MTA Strict Transport Security (MTA-STS).
Problem reported by Dilyan Palauzo.

It is also not in
ftp://ftp.sendmail.org/pub/sendmail/KNOWNBUGS

[Claus Aßmann]

Post by Marco Moock
It is also not in
ftp://ftp.sendmail.org/pub/sendmail/KNOWNBUGS

Of course not. KNOWNBUGS is part of the most recent release.
If the problem would have been detected during snapshot testing
then we would have fixed it before release (instead of adding
it to KNOWNBUGS).

[HQuest]

Claus preview of m4/proto.m4 changes does improve delivery of
Outlook.com emails to a functional status. Looking forward to the final
update/preview Sendmail code to test other fixes.

[Claus Aßmann]

Post by HQuest
Claus preview of m4/proto.m4 changes does improve delivery of
Outlook.com emails to a functional status. Looking forward to the final
update/preview Sendmail code to test other fixes.

There is only one other fix in the current code, hence we haven't
released a new version (yet).

Avoid adding a second To: header to DSNs, instead any
additional addresses are appended to an existing
To: header (this also applies to Cc: and Bcc:).

[Bjørn Mork]

Claus Aßmann

Post by Claus Aßmann
There is only one other fix in the current code, hence we haven't
released a new version (yet).

If you're looking for another quick fix to justify a new version, then
may I suggest making _FFR_TLS_USE_CERTIFICATE_CHAIN_FILE default?

The Debian sendmail package is still built without this (I will open a
bug now). Googling a bit I see that Redhat hit the problem a few years
ago: https://bugzilla.redhat.com/show_bug.cgi?id=1565341

There are probably many other distros, or end users building their own
binary, doing the same because they are unaware of the setting.

A binary built without that flag can only use server certificates
directly signed by a CA known to the client. A well known workaround is
to add intermediate CAs to the CACertFile. The simplest method is by
using the server certificate chain for both ServerCertFile and
CACertFile.

A side effect of this workaround is that intermediate CAs are also
trusted to sign client certificates. Which will cause policy conflicts.

If the server certificate is signed by a public CA using an intermediate
CA, which I will claim is an extremely common use case nowadays, then
client certificates are useless unless _FFR_TLS_USE_CERTIFICATE_CHAIN_FILE
is set.

Yes, I know I still can configure client trust by DN using the access
db. But AUTH EXTERNAL is not possible in a secure way AFAICS.

Even worse, users may be tempted to ignore the security implications and
trust client certificates even if they depend onq the CACertFile workaround.



Bjørn

[Bjørn Mork]

OK, I will not claim to understand any of the sendmail cf language, but
trying to reduce this problem to a test.cf file like this:

C{cert_altnames}*.olc.protection.outlook.com
D{server_name}outlook-com.olc.protection.outlook.com
SSTS_SAN
R$* $: $&{server_name}
R$={cert_altnames} $@ ok
# strip only one level (no recursion!)
R$-.$+ $: $2

STS_SAN foo

STS_SAN input: foo
STS_SAN returns: $# error $@ 4 . 7 . 0 $: 450 outlook-com . olc . protection . outlook . com not listed in SANs

What I do not understand is why the rule doesn't simply rewrite
"outlook-com.olc.protection.outlook.com" to
"*.olc.protection.outlook.com" and then repeat the class lookup with
that. Like this, which seems to work for me:

SSTS_SANFIX
R$* $: $&{server_name}
R$={cert_altnames} $@ ok
# strip only one level (no recursion!)
R$-.$+ $: *.$2

STS_SANFIX foo

STS_SANFIX input: foo
STS_SANFIX returns: ok

${server_name}

outlook-com.olc.protection.outlook.com

$={cert_altnames}

*.olc.protection.outlook.com

.D{server_name}example.com
STS_SANFIX foo

STS_SANFIX input: foo
STS_SANFIX returns: $# error $@ 4 . 7 . 0 $: 450 example . com not listed in SANs

Exact matches also continue to work. Adding example.com to the class

.C{cert_altnames}example.com
$={cert_altnames}

example.com
*.olc.protection.outlook.com

STS_SANFIX foo

STS_SANFIX input: foo
STS_SANFIX returns: ok


So, what do you think? Is that the correct fix or am I missing
something?



Bjørn

[Marco Moock]

Some emails were temporarily rejected with an unexpected "not listed
in SANs" message. This was unexpexted because most of the affected
emails were for MXes hosted by Microsoft and their
"protection.outlook.com" service.

Which logging options do you use?
I maybe have the same problem with gmail/MS and STS with their
certificates, but the logging just says and verify=FAIL
<itex-***@microsoft.com>... Deferred: 403 4.7.0 authentication failed

[Bjørn Mork]

Post by Marco Moock

Some emails were temporarily rejected with an unexpected "not listed
in SANs" message. This was unexpexted because most of the affected
emails were for MXes hosted by Microsoft and their
"protection.outlook.com" service.

Which logging options do you use?
I maybe have the same problem with gmail/MS and STS with their
certificates, but the logging just says and verify=FAIL

I'm usually running with

define(`confLOG_LEVEL', `10')dnl # - attempting to get useful AUTH logging (default is 9)
define(`confMILTER_LOG_LEVEL',`9')dnl # ...without creating unnecessary milter noise


But I don't think your error is related to the SAN wildcard problem.
Looks like you are trying to verify the peer certificate?


Bjørn

[Marco Moock]

Post by Bjørn Mork
But I don't think your error is related to the SAN wildcard problem.
Looks like you are trying to verify the peer certificate?

Yes, I will then open another thread here.