¿Cómo puedo usar comodines para sendmail TLS_Rcpt?

sendmail le permite a uno colocar restricciones en las conversaciones de TLS. Quiero verificar que los mensajes enviados a example.com se envíen a un servidor que tenga un certificado * .messagelabs.com. Quiero proteger contra la falsificación de DNS y MitM. Si messagelabs solo tuviera un servidor, eso sería fácil:

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

Sin embargo, messagelabs tiene muchos servidores y clústeres de diferentes servidores con IP y certificados únicos para el mismo nombre. Todo eso está bien, solo quiero verificar que el servidor al que le estoy enviando el correo está certificado para pertenecer a messagelabs.

Yo he tratado

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

pero obtengo errores como

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

¿Cómo puedo hacer esto? Esta es una solicitud recurrente para nosotros (principalmente para configuraciones como TLS_Rcpt: example.com VERIFY: 256 + CN: *. Example.com), por lo que estaría listo para modificar sendmail.cf, pero no puedo entender

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 (actualización a 8.15.2 pronto).

Haga que sendmail.cf almacene ${cn_subject}con la parte del host despojada ${cn1_subject}.
Hace que terminar la implementación sea casi trivial.

ADVERTENCIA: Pida opiniones news:comp.mail.sendmailantes de implementarlo en un entorno que no sea de prueba. PUEDE funcionar, pero sendmail hace que evitar "efectos secundarios inesperados" sea MUCHO MÁS laborioso de lo que estoy dispuesto a "invertir". Lo "probé en seco" con sendmail-8.15.2.

entrada de acceso:

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

sendmail.mc corregido para admitir la entrada anterior

ADVERTENCIA: recuerde acerca de TAB (\ t) entre RHS y LHS en Rlíneas.
Es una implementación más sucia a través de sendmail.mc solo .

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

Explicación:

1. Hacer Local_tls_rcptuna tienda de conjunto de reglas ${cn_subject}con la parte "antes del primer punto" despojado${cn1_subject}
2. Agregue verificaciones ${cn1_subject}activadas por el prefijo CN1 en la "parte adicional" del TLS_reqconjunto de reglas

Script de muestra para probarlo

#!/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 user1@example.com
END

Esta no es exactamente una respuesta a la pregunta planteada, pero me parece que estás haciendo las cosas de la manera difícil.

La configuración de Sendmail fue escrita de una manera que prioriza la facilidad y la eficiencia para el software que analiza esa configuración, no para una fácil configuración y mantenimiento por parte de los humanos. Simplemente no ha habido una buena razón para hacerlo en las últimas décadas.

Sendmail era una reliquia horriblemente arcana hace 15 años. Algunas distribuciones de Linux todavía lo proporcionan de manera predeterminada, y eso está bien si la configuración predeterminada funciona para usted, pero tan pronto como se encuentre haciendo algo que tome más de unos minutos, es mejor tirar sendmail e instalar un MTA moderno .

Hace unos 15 años, qmail aún podría haber sido un reemplazo razonable, pero durante casi ese tiempo he considerado que postfix es una mejor opción. La documentación del sitio postfix.org es buena una vez que encuentre el bit que necesita. En su caso, querrá http://www.postfix.org/TLS_README.html para este problema.

Me doy cuenta de que es probable que ya haya pasado algún tiempo resolviendo algunos problemas en sendmail, pero en lugar de perder más tiempo en ese agujero, cambie lo antes posible. Si alguna vez miras hacia atrás, te encogerás.