Comment puis-je utiliser des caractères génériques pour sendmail TLS_Rcpt?

sendmail permet de placer des restrictions sur les conversations TLS. Je souhaite vérifier que les messages envoyés à example.com sont envoyés à un serveur disposant d'un certificat * .messagelabs.com. Je veux me protéger contre l'usurpation DNS et MitM. Si messagelabs n'avait qu'un seul serveur, ce serait facile:

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

Cependant, messagelabs a beaucoup de serveurs et de clusters de serveurs différents avec des adresses IP et des certificats uniques pour le même nom. Tout cela va bien, je veux juste vérifier que le serveur auquel je donne le courrier est certifié pour appartenir à messagelabs.

j'ai essayé

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

mais je reçois des erreurs comme

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

Comment puis-je faire ceci? Il s'agit d'une demande récurrente pour nous (principalement pour des configurations comme TLS_Rcpt: example.com VERIFY: 256 + CN: *. Example.com), donc je serais prêt à modifier sendmail.cf, mais je ne peux pas comprendre

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 (mise à niveau vers 8.15.2 bientôt).

Créez un magasin sendmail.cf ${cn_subject}avec la partie hôte supprimée ${cn1_subject}.
Cela rend la mise en œuvre presque triviale.

AVERTISSEMENT: demandez des avis à news:comp.mail.sendmailavant de le déployer dans un environnement non test. Cela PEUT fonctionner, mais sendmail évite les "effets secondaires inattendus" BEAUCOUP PLUS de détails que je ne suis prêt à "investir". Je l'ai "testé à sec" avec sendmail-8.15.2.

entrée d'accès:

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

correctif sendmail.mc pour prendre en charge l'entrée ci-dessus

AVERTISSEMENT: n'oubliez pas TAB (\ t) entre RHS et LHS dans les Rlignes.
C'est une implémentation plus sale via sendmail.mc seulement .

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

Explication:

1. Créer un Local_tls_rcptmagasin de règles ${cn_subject}avec la partie "avant le premier point" supprimée${cn1_subject}
2. Ajouter des contrôles de ${cn1_subject}déclenchés par le préfixe CN1 dans la "partie supplémentaire" de l' TLS_reqensemble de règles

Exemple de script pour le tester

#!/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

Ce n'est pas exactement une réponse à la question posée, mais il me semble que vous faites les choses à la dure.

La configuration de Sendmail a été écrite d'une manière qui donne la priorité à la facilité et à l'efficacité du logiciel analysant cette configuration, et non à une configuration et une maintenance faciles par les humains. Il n'y a tout simplement aucune bonne raison de le faire au cours des dernières décennies.

Sendmail était une relique horriblement mystérieuse il y a 15 ans. Certaines distributions Linux le fournissent toujours par défaut, et c'est bien si la configuration par défaut fonctionne pour vous, mais dès que vous vous retrouvez à faire quelque chose qui prend plus de quelques minutes, il est préférable de jeter sendmail et d'installer un MTA moderne .

Il y a environ 15 ans, qmail était peut-être toujours un remplacement judicieux, mais pendant presque aussi longtemps, j'ai considéré postfix comme un meilleur choix. La documentation du site postfix.org est bonne une fois que vous avez trouvé le bit dont vous avez besoin. Dans votre cas, vous aurez besoin de http://www.postfix.org/TLS_README.html pour ce problème.

Je sais que vous aurez probablement déjà passé du temps à résoudre quelques problèmes dans sendmail, mais plutôt que de perdre plus de temps dans ce trou, changez de place à la première occasion. Si jamais vous regardez en arrière, vous grincerez des dents.