Como posso usar curingas para o sendmail TLS_Rcpt?

Question

O sendmail permite restrições de um lugar nas conversas TLS. Quero verificar se as mensagens enviadas para example.com são enviadas para um servidor que tenha um certificado * .messagelabs.com. Eu quero proteger contra DNS spoofing e MitM. Se messagelabs tivesse apenas um servidor que seria fácil:

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

No entanto, o messagelabs tem muitos servidores e clusters de diferentes servidores com IPs e certificados exclusivos para o mesmo nome. Tudo bem, eu só quero verificar se o servidor para o qual eu estou enviando o e-mail está certificado para pertencer a messagelabs.

Eu tentei

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

mas recebo erros como

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

Como posso fazer isso? Esta é uma solicitação recorrente para nós (principalmente para configurações como TLS_Rcpt: example.com VERIFY: 256 + CN: *. Example.com), então eu estaria pronto para modificar o sendmail.cf, mas não consigo 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 (atualizando para 8.15.2 em breve).

    

Answer 1

Faça a loja sendmail.cf ${cn_subject} com parte do host removida em ${cn1_subject} .
Isso torna o acabamento da implementação quase 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.

entrada de acesso:

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

correção sendmail.mc para suportar a entrada acima

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

Explicação:

1. Torne Local_tls_rcpt conjunto de regras armazenar ${cn_subject} com a parte "antes do primeiro ponto" removida em ${cn1_subject}
2. Adicione verificações de ${cn1_subject} acionadas pelo prefixo CN1 em "parte extra" de TLS_req rule-set

Exemplo de script para testá-lo

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

Isso não é exatamente uma resposta para a pergunta, mas parece que você está fazendo as coisas da maneira mais difícil.

A configuração do Sendmail foi escrita de uma maneira que prioriza a facilidade e a eficiência para o software analisar essa configuração, não para facilitar a configuração e a manutenção por humanos. Simplesmente não há boas razões para fazer isso nas últimas décadas.

O Sendmail foi uma relíquia horrivelmente misteriosa 15 anos atrás. Algumas distribuições linux ainda a fornecem por padrão, e tudo bem se a configuração padrão funcionar para você, mas assim que você estiver fazendo algo que demore mais do que alguns minutos, é melhor jogar o sendmail e instalar um MTA moderno. .

Cerca de 15 anos atrás, o qmail ainda poderia ter sido um substituto sensato, mas por quase tanto tempo eu considerei o postfix uma escolha melhor. A documentação do site postfix.org é boa quando você encontra o bit que precisa. No seu caso, você precisará do link para esse problema.

Eu sei que você provavelmente já gastou algum tempo resolvendo alguns problemas no sendmail, mas ao invés de jogar mais tempo naquele buraco, mude na primeira oportunidade. Se você olhar para trás, vai se encolher.