Come posso usare i caratteri jolly per sendmail TLS_Rcpt?

sendmail consente restrizioni di un posto per le conversazioni TLS. Voglio verificare che i messaggi inviati a example.com vengano inviati a un server che ha un certificato * .messagelabs.com. Voglio proteggere dallo spoofing DNS e MitM. Se messagelabs avesse un solo server sarebbe facile:

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

Tuttavia messagelabs ha molti server e cluster di server diversi con IP e certificati univoci con lo stesso nome. Va bene, voglio solo controllare che il server a cui sto inviando la posta sia certificato per appartenere a messagelabs.

Ho provato

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

ma ricevo errori come

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

Come posso fare questo? Questa è una richiesta ricorrente per noi (principalmente per configurazioni come TLS_Rcpt: example.com VERIFY: 256 + CN: *. Example.com), quindi sarei pronto a modificare sendmail.cf, ma non riesco a capire

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 (l'aggiornamento a 8.15.2 presto).

Crea store sendmail.cf ${cn_subject}con la parte host rimossa ${cn1_subject}.
Rende quasi banale il completamento dell'implementazione.

AVVERTENZA: chiedere un parere news:comp.mail.sendmailprima di distribuirlo in un ambiente non di prova. Può funzionare ma sendmail evita "effetti collaterali inaspettati" MOLTO PIÙ scrupolosamente di quanto io sia pronto a "investire". L'ho "testato a secco" con sendmail-8.15.2.

voce di accesso:

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

correzione sendmail.mc per supportare la voce sopra

ATTENZIONE: ricordare TAB (\ t) tra RHS e LHS in Rlinea.
È sendmail.mc solo un'implementazione più sporca .

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

Spiegazione:

1. Crea Local_tls_rcptun archivio di regole ${cn_subject}con la parte "prima del primo punto" rimossa${cn1_subject}
2. Aggiungi i controlli ${cn1_subject}attivati ​​dal prefisso CN1 nella "parte aggiuntiva" del TLS_reqset di regole

Script di esempio per testarlo

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

Questa non è esattamente una risposta alla domanda come posta, ma mi sembra che tu stia facendo le cose nel modo più duro.

La configurazione di Sendmail è stata scritta in modo da dare priorità alla facilità e all'efficienza del software che analizza tale configurazione, non per una facile configurazione e manutenzione da parte dell'uomo. Non c'è stato semplicemente un buon motivo per farlo negli ultimi decenni.

Sendmail era una reliquia orribilmente arcana 15 anni fa. Alcune distribuzioni Linux lo forniscono ancora per impostazione predefinita, e va bene se la configurazione predefinita funziona per te, ma non appena ti ritrovi a fare qualcosa che richiede più di qualche minuto, è meglio buttare fuori sendmail e installare un moderno MTA .

Circa 15 anni fa, qmail avrebbe potuto essere ancora una valida sostituzione, ma per quasi così tanto tempo ho considerato postfix una scelta migliore. La documentazione dal sito postfix.org è buona quando trovi il bit di cui hai bisogno. Nel tuo caso, ti consigliamo http://www.postfix.org/TLS_README.html per questo problema.

Mi rendo conto che probabilmente avrai speso un po 'di tempo a risolvere alcuni problemi in sendmail, ma piuttosto che perdere più tempo in quel buco, passa alla prima occasione. Se ti guardi indietro, ti farai rabbrividire.