Rocksolid Light

News from da outaworlds

mail  files  register  groups  login

Message-ID:  

The time is right to make new friends.

comp / comp.mail.sendmail / Re: Problem with FEATURE(`sts'): bogus "not listed in SANs" rejects

SubjectAuthor
* Problem with FEATURE(`sts'): bogus "not listed in SANs" rejectsBjørn Mork
+* Re: Problem with FEATURE(`sts'): bogus "not listed in SANs" rejectsBjørn Mork
|+* Re: Problem with FEATURE('sts'): bogus "not listed in SANs" rejectsHQuest
||`* Re: Problem with FEATURE('sts'): bogus "not listed in SANs" rejectsBjørn Mork
|| `* Re: Problem with FEATURE('sts'): bogus "not listed in SANs" rejectsClaus Aßmann
||  `* Re: Problem with FEATURE('sts'): bogus "not listed in SANs" rejectsMarco Moock
||   `* Re: Problem with FEATURE('sts'): bogus "not listed in SANs" rejectsClaus Aßmann
||    `* Re: Problem with FEATURE('sts'): bogus "not listed in SANs" rejectsHQuest
||     `* Re: Problem with FEATURE('sts'): bogus "not listed in SANs" rejectsClaus Aßmann
||      `- Re: Problem with FEATURE('sts'): bogus "not listed in SANs" rejectsBjørn Mork
|`- Re: Problem with FEATURE(`sts'): bogus "not listed in SANs" rejectsBjørn Mork
`* Re: Problem with FEATURE(`sts'): bogus "not listed in SANs" rejectsMarco Moock
 `* Re: Problem with FEATURE(`sts'): bogus "not listed in SANs" rejectsBjørn Mork
  `- Re: Problem with FEATURE(`sts'): bogus "not listed in SANs" rejectsMarco Moock

1
Subject: Problem with FEATURE(`sts'): bogus "not listed in SANs" rejects
From: Bjørn Mork
Newsgroups: comp.mail.sendmail
Organization: m
Date: Tue, 29 Oct 2024 08:16 UTC
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bjorn@mork.no (Bjørn Mork)
Newsgroups: comp.mail.sendmail
Subject: Problem with FEATURE(`sts'): bogus "not listed in SANs" rejects
Date: Tue, 29 Oct 2024 09:16:37 +0100
Organization: m
Lines: 97
Message-ID: <87a5enl3x6.fsf@miraculix.mork.no>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 29 Oct 2024 09:16:40 +0100 (CET)
Injection-Info: dont-email.me; posting-host="e26d762b05cd42ed41f661d42a7e7041";
logging-data="1570103"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+u7tjVynArGGvLsHs0uXaf"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Cancel-Lock: sha1:l/RHfXQm6Y1uf4Sg9vfmmAeh17I=
sha1:nl2AlqOX4jhiRP7QXNIhuNEkB7o=
View all headers

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=redacted@hotmail.com, relay=hotmail-com.olc.protection.outlook.com., reject=450 4.7.0 <redacted@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=redacted.redacted@outlook.com, relay=outlook-com.olc.protection.outlook.com., reject=450 4.7.0 <redacted.redacted@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=redacted@01-mail.org, relay=mx.01-mail.net., reject=450 4.7.0 <redacted@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

Subject: Re: Problem with FEATURE(`sts'): bogus "not listed in SANs" rejects
From: Bjørn Mork
Newsgroups: comp.mail.sendmail
Organization: m
Date: Tue, 29 Oct 2024 09:45 UTC
References: 1
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bjorn@mork.no (Bjørn Mork)
Newsgroups: comp.mail.sendmail
Subject: Re: Problem with FEATURE(`sts'): bogus "not listed in SANs" rejects
Date: Tue, 29 Oct 2024 10:45:15 +0100
Organization: m
Lines: 120
Message-ID: <87v7xbi6ok.fsf@miraculix.mork.no>
References: <87a5enl3x6.fsf@miraculix.mork.no>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 29 Oct 2024 10:45:16 +0100 (CET)
Injection-Info: dont-email.me; posting-host="e26d762b05cd42ed41f661d42a7e7041";
logging-data="1591704"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX199UJhWlo/LOarlX5ZvzGVH"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Cancel-Lock: sha1:uXUuFSktP+/ezGAKj4of08O9c7c=
sha1:812eFnSss2Kv92TstfO4vwssVPM=
View all headers

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 <du1874@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=du1874@outlook.com, relay=outlook-com.olc.protection.outlook.com., reject=450 4.7.0 <du1874@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 <du1874@outlook.com>... Deferred
2024-10-29T09:29:31.350545+00:00 dilbert sm-mta[1697002]: 49T9TSAv1697000: to=<du1874@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 <du1874@gmail.com>... Sent (OK 1730194198 38308e7fff4ca-2fcb45e2a01si27180301fa.310 - gsmtp)
2024-10-29T09:29:58.366769+00:00 dilbert sm-mta[1697008]: 49T9Tu0F1697006: to=<du1874@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


Click here to read the complete article
Subject: Re: Problem with FEATURE('sts'): bogus "not listed in SANs" rejects
From: HQuest
Newsgroups: comp.mail.sendmail
Organization: novaBBS
Date: Tue, 29 Oct 2024 11:00 UTC
References: 1 2
Path: eternal-september.org!news.eternal-september.org!feeder2.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: hquest@hquest.pro.br (HQuest)
Newsgroups: comp.mail.sendmail
Subject: Re: Problem with FEATURE('sts'): bogus "not listed in SANs" rejects
Date: Tue, 29 Oct 2024 11:00:03 +0000
Organization: novaBBS
Message-ID: <5b9c98ce0f90db6169017005e7ede7d5@www.novabbs.com>
References: <87a5enl3x6.fsf@miraculix.mork.no> <87v7xbi6ok.fsf@miraculix.mork.no>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="4184151"; mail-complaints-to="usenet@i2pn2.org";
posting-account="gSdnz2tQQMpN18WMM4rt2FtJBW7lWv7DL3bXcApLdlA";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: 1932cd5cdfc4939182d2446462275a239b9d79e0
X-Rslight-Site: $2y$10$/QKk2G.uA7lU1xhw5t2vdelNMTf3LN.EuG8egbFXzKO31ODdmpede
View all headers

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.

Subject: Re: Problem with FEATURE(`sts'): bogus "not listed in SANs" rejects
From: Bjørn Mork
Newsgroups: comp.mail.sendmail
Organization: m
Date: Tue, 29 Oct 2024 11:11 UTC
References: 1 2
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bjorn@mork.no (Bjørn Mork)
Newsgroups: comp.mail.sendmail
Subject: Re: Problem with FEATURE(`sts'): bogus "not listed in SANs" rejects
Date: Tue, 29 Oct 2024 12:11:35 +0100
Organization: m
Lines: 67
Message-ID: <87r07zi2oo.fsf@miraculix.mork.no>
References: <87a5enl3x6.fsf@miraculix.mork.no>
<87v7xbi6ok.fsf@miraculix.mork.no>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 29 Oct 2024 12:11:35 +0100 (CET)
Injection-Info: dont-email.me; posting-host="e26d762b05cd42ed41f661d42a7e7041";
logging-data="1615147"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/QE12b3BpKYJEcM0L3jRL6"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Cancel-Lock: sha1:tEtouAY/t+fRQ09aNPwughDjPGg=
sha1:JD9TFtwTp594Qw1z6DmTcj9uG0M=
View all headers

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
R *.$={cert_altnames} $@ ok
R$* $#error $@ 4.7.0 $: 450 $&{server_name} not listed in SANs

and running that through sendmail -bt -Ctest.cf will reproduce the problem:

> 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
R$={cert_altnames} $@ ok
R$* $#error $@ 4.7.0 $: 450 $&{server_name} not listed in SANs

Running that I get:

> 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

And it still seems to work as it should with non-matching names:

> .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
and run again:

> .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

Subject: Re: Problem with FEATURE('sts'): bogus "not listed in SANs" rejects
From: Bjørn Mork
Newsgroups: comp.mail.sendmail
Organization: m
Date: Tue, 29 Oct 2024 11:54 UTC
References: 1 2 3
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bjorn@mork.no (Bjørn Mork)
Newsgroups: comp.mail.sendmail
Subject: Re: Problem with FEATURE('sts'): bogus "not listed in SANs" rejects
Date: Tue, 29 Oct 2024 12:54:59 +0100
Organization: m
Lines: 55
Message-ID: <87iktbi0oc.fsf@miraculix.mork.no>
References: <87a5enl3x6.fsf@miraculix.mork.no>
<87v7xbi6ok.fsf@miraculix.mork.no>
<5b9c98ce0f90db6169017005e7ede7d5@www.novabbs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 29 Oct 2024 12:55:00 +0100 (CET)
Injection-Info: dont-email.me; posting-host="e26d762b05cd42ed41f661d42a7e7041";
logging-data="1615147"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19ZYCRAZtyyPRj/ZLGOKykz"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Cancel-Lock: sha1:QJeuUNpbm7/qJeNwuImIKfCLW24=
sha1:9GNQIjXVdMlRtHo6xFtI5AEOHfE=
View all headers

hquest@hquest.pro.br (HQuest) writes:

> 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?= <bjorn@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 <bjorn@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')
--
2.39.5

Subject: Re: Problem with FEATURE('sts'): bogus "not listed in SANs" rejects
From: Claus Aßmann
Newsgroups: comp.mail.sendmail
Organization: MGT Consulting
Date: Tue, 29 Oct 2024 16:17 UTC
References: 1 2 3 4
Path: eternal-september.org!news.eternal-september.org!feeder2.eternal-september.org!news.quux.org!weretis.net!feeder9.news.weretis.net!news.misty.com!.POSTED.veps.esmtp.org!not-for-mail
From: INVALID_NO_CC_REMOVE_IF_YOU_DO_NOT_POST_ml+sendmail(-no-copies-please)@esmtp.org (Claus Aßmann)
Newsgroups: comp.mail.sendmail
Subject: Re: Problem with FEATURE('sts'): bogus "not listed in SANs" rejects
Date: Tue, 29 Oct 2024 12:17:24 -0400 (EDT)
Organization: MGT Consulting
Sender: <ml+sendmail(-no-copies-please)@esmtp.org>
Message-ID: <vfr1qk$vd4$1@news.misty.com>
References: <87a5enl3x6.fsf@miraculix.mork.no> <87v7xbi6ok.fsf@miraculix.mork.no> <5b9c98ce0f90db6169017005e7ede7d5@www.novabbs.com> <87iktbi0oc.fsf@miraculix.mork.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 29 Oct 2024 16:17:24 -0000 (UTC)
Injection-Info: news.misty.com; posting-host="veps.esmtp.org:155.138.203.148";
logging-data="32164"; mail-complaints-to="abuse@misty.com"
Mail-Copies-To: never
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: ca@x2.esmtp.org (Claus Assmann)
View all headers

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')

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

Subject: Re: Problem with FEATURE('sts'): bogus "not listed in SANs" rejects
From: Marco Moock
Newsgroups: comp.mail.sendmail
Organization: A noiseless patient Spider
Date: Tue, 29 Oct 2024 19:36 UTC
References: 1 2 3 4 5
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: mm+usenet-es@dorfdsl.de (Marco Moock)
Newsgroups: comp.mail.sendmail
Subject: Re: Problem with FEATURE('sts'): bogus "not listed in SANs" rejects
Date: Tue, 29 Oct 2024 20:36:23 +0100
Organization: A noiseless patient Spider
Lines: 17
Message-ID: <vfrdfo$1mfaa$3@dont-email.me>
References: <87a5enl3x6.fsf@miraculix.mork.no>
<87v7xbi6ok.fsf@miraculix.mork.no>
<5b9c98ce0f90db6169017005e7ede7d5@www.novabbs.com>
<87iktbi0oc.fsf@miraculix.mork.no>
<vfr1qk$vd4$1@news.misty.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Tue, 29 Oct 2024 20:36:24 +0100 (CET)
Injection-Info: dont-email.me; posting-host="c3c6730c6b960483f3aecdd810a8187b";
logging-data="1785162"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18wL3vWDyK3w5d19U2bNvIF"
Cancel-Lock: sha1:xpywm9WMBxaJ6huutv4l6qn7So4=
View all headers

On 29.10.2024 um 12:17 Uhr Claus Aßmann wrote:

> 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.

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

--
kind regards
Marco

Send spam to 1730200644muell@cartoonies.org

Subject: Re: Problem with FEATURE('sts'): bogus "not listed in SANs" rejects
From: Claus Aßmann
Newsgroups: comp.mail.sendmail
Organization: MGT Consulting
Date: Wed, 30 Oct 2024 05:30 UTC
References: 1 2 3 4
Path: eternal-september.org!news.eternal-september.org!feeder2.eternal-september.org!border-3.nntp.ord.giganews.com!border-2.nntp.ord.giganews.com!nntp.giganews.com!news.misty.com!.POSTED.veps.esmtp.org!not-for-mail
From: INVALID_NO_CC_REMOVE_IF_YOU_DO_NOT_POST_ml+sendmail(-no-copies-please)@esmtp.org (Claus Aßmann)
Newsgroups: comp.mail.sendmail
Subject: Re: Problem with FEATURE('sts'): bogus "not listed in SANs" rejects
Date: Wed, 30 Oct 2024 01:30:08 -0400 (EDT)
Organization: MGT Consulting
Sender: <ml+sendmail(-no-copies-please)@esmtp.org>
Message-ID: <vfsg90$odd$1@news.misty.com>
References: <87a5enl3x6.fsf@miraculix.mork.no> <87iktbi0oc.fsf@miraculix.mork.no> <vfr1qk$vd4$1@news.misty.com> <vfrdfo$1mfaa$3@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 30 Oct 2024 05:30:08 -0000 (UTC)
Injection-Info: news.misty.com; posting-host="veps.esmtp.org:155.138.203.148";
logging-data="25005"; mail-complaints-to="abuse@misty.com"
Mail-Copies-To: never
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: ca@x2.esmtp.org (Claus Assmann)
Lines: 17
View all headers

Marco Moock wrote:
> On 29.10.2024 um 12:17 Uhr Claus Aßmann wrote:

> > Unfortunately this has not yet been released:

> 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).

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

Subject: Re: Problem with FEATURE('sts'): bogus "not listed in SANs" rejects
From: HQuest
Newsgroups: comp.mail.sendmail
Organization: novaBBS
Date: Wed, 30 Oct 2024 12:55 UTC
References: 1 2 3 4 5
Path: eternal-september.org!news.eternal-september.org!feeder2.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: hquest@hquest.pro.br (HQuest)
Newsgroups: comp.mail.sendmail
Subject: Re: Problem with FEATURE('sts'): bogus "not listed in SANs" rejects
Date: Wed, 30 Oct 2024 12:55:13 +0000
Organization: novaBBS
Message-ID: <47f875facd6badf3579f93f3be2ee26c@www.novabbs.com>
References: <87a5enl3x6.fsf@miraculix.mork.no> <87iktbi0oc.fsf@miraculix.mork.no> <vfr1qk$vd4$1@news.misty.com> <vfrdfo$1mfaa$3@dont-email.me> <vfsg90$odd$1@news.misty.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
logging-data="147031"; mail-complaints-to="usenet@i2pn2.org";
posting-account="gSdnz2tQQMpN18WMM4rt2FtJBW7lWv7DL3bXcApLdlA";
User-Agent: Rocksolid Light
X-Rslight-Posting-User: 1932cd5cdfc4939182d2446462275a239b9d79e0
X-Rslight-Site: $2y$10$xai6wNZ6QMjzx00GOu4TG.leIrp7uz/mi5ALNoln8gGYQmbLIT6H2
X-Spam-Checker-Version: SpamAssassin 4.0.0
View all headers

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.

Subject: Re: Problem with FEATURE('sts'): bogus "not listed in SANs" rejects
From: Claus Aßmann
Newsgroups: comp.mail.sendmail
Organization: MGT Consulting
Date: Thu, 31 Oct 2024 04:51 UTC
References: 1 2 3 4
Path: eternal-september.org!news.eternal-september.org!feeder2.eternal-september.org!panix!weretis.net!feeder9.news.weretis.net!news.misty.com!.POSTED.veps.esmtp.org!not-for-mail
From: INVALID_NO_CC_REMOVE_IF_YOU_DO_NOT_POST_ml+sendmail(-no-copies-please)@esmtp.org (Claus Aßmann)
Newsgroups: comp.mail.sendmail
Subject: Re: Problem with FEATURE('sts'): bogus "not listed in SANs" rejects
Date: Thu, 31 Oct 2024 00:51:08 -0400 (EDT)
Organization: MGT Consulting
Sender: <ml+sendmail(-no-copies-please)@esmtp.org>
Message-ID: <vfv2bs$sd0$1@news.misty.com>
References: <87a5enl3x6.fsf@miraculix.mork.no> <vfrdfo$1mfaa$3@dont-email.me> <vfsg90$odd$1@news.misty.com> <47f875facd6badf3579f93f3be2ee26c@www.novabbs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 31 Oct 2024 04:51:08 -0000 (UTC)
Injection-Info: news.misty.com; posting-host="veps.esmtp.org:155.138.203.148";
logging-data="29088"; mail-complaints-to="abuse@misty.com"
Mail-Copies-To: never
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: ca@x2.esmtp.org (Claus Assmann)
View all headers

HQuest wrote:
> 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:).

Subject: Re: Problem with FEATURE('sts'): bogus "not listed in SANs" rejects
From: Bjørn Mork
Newsgroups: comp.mail.sendmail
Organization: m
Date: Mon, 11 Nov 2024 16:09 UTC
References: 1 2 3 4 5
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bjorn@mork.no (Bjørn Mork)
Newsgroups: comp.mail.sendmail
Subject: Re: Problem with FEATURE('sts'): bogus "not listed in SANs" rejects
Date: Mon, 11 Nov 2024 17:09:13 +0100
Organization: m
Lines: 40
Message-ID: <87wmh9u506.fsf@miraculix.mork.no>
References: <87a5enl3x6.fsf@miraculix.mork.no> <vfrdfo$1mfaa$3@dont-email.me>
<vfsg90$odd$1@news.misty.com>
<47f875facd6badf3579f93f3be2ee26c@www.novabbs.com>
<vfv2bs$sd0$1@news.misty.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 11 Nov 2024 17:09:13 +0100 (CET)
Injection-Info: dont-email.me; posting-host="3b01bd0aa1bc195254c03061af55912c";
logging-data="1121815"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19CtMCB9kvfxaGLJGtyjZaT"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Cancel-Lock: sha1:Oa4q8YU7kMplUarWQ9DoKiG9iWE=
sha1:taAG+fBUUM8paij4aAhnXQwH6A4=
View all headers

Claus Aßmann
<INVALID_NO_CC_REMOVE_IF_YOU_DO_NOT_POST_ml+sendmail(-no-copies-please)@esmtp.org>
writes:

> 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

Subject: Re: Problem with FEATURE(`sts'): bogus "not listed in SANs" rejects
From: Marco Moock
Newsgroups: comp.mail.sendmail
Organization: A noiseless patient Spider
Date: Fri, 27 Dec 2024 10:53 UTC
References: 1
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: mm+usenet-es@dorfdsl.de (Marco Moock)
Newsgroups: comp.mail.sendmail
Subject: Re: Problem with FEATURE(`sts'): bogus "not listed in SANs" rejects
Date: Fri, 27 Dec 2024 11:53:15 +0100
Organization: A noiseless patient Spider
Lines: 20
Message-ID: <20241227115315.2551e8d0@ryz.dorfdsl.de>
References: <87a5enl3x6.fsf@miraculix.mork.no>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Fri, 27 Dec 2024 11:53:16 +0100 (CET)
Injection-Info: dont-email.me; posting-host="9021a6446f65d334fbd9b603263f1bf0";
logging-data="3746195"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19HcLDAzO05KKurMisnySZL"
Cancel-Lock: sha1:A9Bn6RIE4yXTZTIJRnnUTvKllTc=
View all headers

On 29.10.2024 09:16 Uhr Bjørn Mork wrote:

> 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.

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-rua@microsoft.com>... Deferred: 403 4.7.0 authentication failed

--
kind regards
Marco

Send spam to 1730189797muell@stinkedores.dorfdsl.de

Subject: Re: Problem with FEATURE(`sts'): bogus "not listed in SANs" rejects
From: Bjørn Mork
Newsgroups: comp.mail.sendmail
Organization: m
Date: Fri, 27 Dec 2024 12:35 UTC
References: 1 2
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bjorn@mork.no (Bjørn Mork)
Newsgroups: comp.mail.sendmail
Subject: Re: Problem with FEATURE(`sts'): bogus "not listed in SANs" rejects
Date: Fri, 27 Dec 2024 13:35:29 +0100
Organization: m
Lines: 25
Message-ID: <87frm9xq0e.fsf@miraculix.mork.no>
References: <87a5enl3x6.fsf@miraculix.mork.no>
<20241227115315.2551e8d0@ryz.dorfdsl.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 27 Dec 2024 13:35:30 +0100 (CET)
Injection-Info: dont-email.me; posting-host="e5a07465724fc40512fd165f47eef442";
logging-data="3791752"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+rEju/IXfEb3kMnShA71F2"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Cancel-Lock: sha1:u1jRXYHJzv9de0i64tRPfcRSeYg=
sha1:RzvX3mkli1JX3WLgYDPUsgOnILQ=
View all headers

Marco Moock <mm+usenet-es@dorfdsl.de> writes:
> On 29.10.2024 09:16 Uhr Bjørn Mork wrote:
>
>> 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.
>
> 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-rua@microsoft.com>... Deferred: 403 4.7.0 authentication failed

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

Subject: Re: Problem with FEATURE(`sts'): bogus "not listed in SANs" rejects
From: Marco Moock
Newsgroups: comp.mail.sendmail
Organization: A noiseless patient Spider
Date: Fri, 27 Dec 2024 16:14 UTC
References: 1 2 3
Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: mm+usenet-es@dorfdsl.de (Marco Moock)
Newsgroups: comp.mail.sendmail
Subject: Re: Problem with FEATURE(`sts'): bogus "not listed in SANs" rejects
Date: Fri, 27 Dec 2024 17:14:34 +0100
Organization: A noiseless patient Spider
Lines: 13
Message-ID: <20241227171434.55965755@ryz.dorfdsl.de>
References: <87a5enl3x6.fsf@miraculix.mork.no>
<20241227115315.2551e8d0@ryz.dorfdsl.de>
<87frm9xq0e.fsf@miraculix.mork.no>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Fri, 27 Dec 2024 17:14:35 +0100 (CET)
Injection-Info: dont-email.me; posting-host="9021a6446f65d334fbd9b603263f1bf0";
logging-data="3864512"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18f3dypJXOOm6mwGLKySMlb"
Cancel-Lock: sha1:5zDyLxtz8rizIr2mpqZntTOeaeE=
View all headers

On 27.12.2024 13:35 Uhr Bjørn Mork wrote:

> 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.

--
kind regards
Marco

Send spam to 1735302929muell@stinkedores.dorfdsl.de

1

rocksolid light 0.9.8
clearnet tor