Existe uma maneira de desabilitar completamente o suporte TLS oportunista de saída no SendMail?

2

CentOS 5.x SendMail 8.14.4

Um recurso de segurança de rede com excesso de zelo está causando uma falha nas negociações de TLS quando meu servidor do Sendmail tenta falar com hosts externos. Isso está fazendo com que o sendmail re-enfileire constantemente algumas mensagens, porque não irá falhar na entrega não criptografada.

Existe uma maneira de desativar o TLS de saída completamente? Estou ciente de que posso adicionar entradas Try_TLS: broken.server NO para os registros mx individuais (ou domínios parciais), mas prefiro apenas desabilitar isso totalmente até que a causa raiz seja resolvida.

Até onde eu sei, parece não haver nenhuma maneira de dizer ao SendMail para não usar TLS.

Eu tentei Try_TLS: * mas isso não funcionou.

Eu entendo que a causa raiz não é o meu sistema específico, mas como não tenho controle das partes afetadas, gostaria de pelo menos receber o fluxo de mensagens. Alguma ideia?

    
por Mike B 05.01.2012 / 01:48

2 respostas

1

Não tenho certeza, mas uma pesquisa rápida apareceu esta que diz (ênfase minha):

To be able to send to (or receive from) those MTAs, the ruleset try_tls (srv_features) can be used that work together with the access map. Entries for the access map must be tagged with Try_TLS (Srv_Features) and refer to the hostname or IP address of the connecting system. A default case can be specified by using just the tag.

    
por 05.01.2012 / 06:55
1

Eu prefiro a resposta de Aaron, mas apenas no caso de alguém se deparar com isso, há um método alternativo de fazer isso.

Localize a parte CLIENT_OPTIONS de um arquivo sendmail.mc e adicione M = S.

Por exemplo, se você tivesse algo como:

CLIENT_OPTIONS('Family=inet, Addr=1.2.3.4’)dnl

Você pode alterá-lo para:

CLIENT_OPTIONS('Family=inet, M=S, Addr=1.2.3.4’)dnl

A diferença é que, com esse segundo método, o SendMail nem sequer se preocupará em procurar pelo TLS (o que pode ser pior, dependendo de como / por que você está fazendo essa alteração).

    
por 05.01.2012 / 21:48