How can I use wildcards for sendmail TLS_Rcpt?

Question

sendmail lets one place restrictions on TLS conversations. I want to check that messages sent to example.com are sent to a server that has a *.messagelabs.com certificate. I want to protect against DNS spoofing and MitM. If messagelabs only had one server that would be easy:

TLS_Rcpt:example.com VERIFY:256+CN:mx.messagelabs.com

However messagelabs has a lot of servers and clusters of different servers with unique IPs and certs for the same name. All that is fine, I just want to check that server I'm giving the mail to is certified to belong to messagelabs.

I have tried

TLS_Rcpt:example.com VERIFY:256+CN:messagelabs.com
TLS_Rcpt:example.com VERIFY:256+CN:*.messagelabs.com
TLS_Rcpt:example.com VERIFY:256+CN:.*.messagelabs.com

but I get errors like

CN mail31.messagelabs.com does not match .*.messagelabs.com

How can I do this? This is a recurrent request for us (mostly for configs like TLS_Rcpt:example.com VERIFY:256+CN:*.example.com), so I'd be ready to modify sendmail.cf, but I can't make sense of

STLS_req
R $| $+         $@ OK
R<CN> $* $| <$+>                $: <CN:$&{TLS_Name}> $1 $| <$2>
R<CN:$&{cn_subject}> $* $| <$+>         $@ $>"TLS_req" $1 $| <$2>
R<CN:$+> $* $| <$-:$+>  $#error $@ $4 $: $3 " CN " $&{cn_subject} " does not match " $1
R<CS:$&{cert_subject}> $* $| <$+>       $@ $>"TLS_req" $1 $| <$2>
R<CS:$+> $* $| <$-:$+>  $#error $@ $4 $: $3 " Cert Subject " $&{cert_subject} " does not match " $1
R<CI:$&{cert_issuer}> $* $| <$+>        $@ $>"TLS_req" $1 $| <$2>
R<CI:$+> $* $| <$-:$+>  $#error $@ $4 $: $3 " Cert Issuer " $&{cert_issuer} " does not match " $1
ROK                     $@ OK

Sendmail 8.14.7 (upgrading to 8.15.2 soon).

Answer 1

Make sendmail.cf store ${cn_subject} with host part stripped in ${cn1_subject}.
It makes finishing the implementation almost trivial.

WARNING: Ask for opinions at news:comp.mail.sendmail before deploying it in not test environment. It MAY work but sendmail makes avoiding "unexpected side effects" MUCH MORE painstaking than I am ready to "invest". I "dry tested" it with sendmail-8.15.2.

access entry:

TLS_Rcpt:example.com VERIFY:256+CN1:messagelabs.com

sendmail.mc fix to support above entry

WARNING: remember about TAB (\t) between RHS and LHS in R lines.
It is more dirty implementation via sendmail.mc only.

define(`_LOCAL_TLS_RCPT_')dnl
LOCAL_RULESETS
SLocal_tls_rcpt
R$*     $: $&{cn_subject}
R$-.$+  $@ $(macro {cn1_subject}  $@ $2 $)
R$*     $@ $(macro {cn1_subject}  $@ $)    

# Ruleset continued
STLS_req
R<CN1:$&{cn1_subject}> $* $| <$+>               $@ $>"TLS_req" $1 $| <$2>
R<CN1:$+> $* $| <$-:$+> $#error $@ $4 $: $3 " CN-1 " $&{cn_subject} " does not match " $1
ROK                     $@ OK
divert(0)dnl

---

Explanation:

1. Make Local_tls_rcpt rule-set store ${cn_subject} with "before first dot" part stripped in ${cn1_subject}
2. Add checks of ${cn1_subject} triggered by CN1 prefix in "extra part" of TLS_req rule-set

---

Sample script to test it

#!/bin/sh
# -C sendmail-test.cf -- use non standard cf file
# -d60.5 -- trace (access) map lookus
# -d21.12 -- trace R lines rewriting 
sendmail -C sendmail-test.cf -bt -d60.5 <<END
.D{verify}OK
.D{cn_subject}mail31.messagelabs.com
.D{server_name}mail31.messagelabs.com
tls_rcpt [email protected]
END

Answer 2

This isn't exactly an answer to the question as posed, but it looks to me like you are doing things the hard way.

The Sendmail configuration was written in a way that prioritises ease and efficiency for the software parsing that configuration, not for easy configuration and maintenance by humans. There's simply been no good reason to do that in recent decades.

Sendmail was a horribly arcane relic 15 years ago. Some linux distribbutions still provide it by default, and that's fine if the default config works for you, but as soon as you find yourself doing anything that takes more than a few minutes, you're best to throw sendmail out and install a modern MTA.

About 15 years ago, qmail might still have been a sensible replacement, but for almost that long I've considered postfix a better choice. The documentation from the postfix.org site is good once you find the bit you need. In your case you'll want http://www.postfix.org/TLS_README.html for this problem.

I realise you'll quite likely have spent some time solving a few problems in sendmail already, but rather than throwing more time down that hole, switch at the earliest opportunity. If you ever look back you'll cringe.