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

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