Por que o sendmail está chamando dns_getcanonname para domínios de não-destinatários no cabeçalho To:?

Question

Notamos um problema repetitivo ocasional em nossa configuração do sendmail. O cenário é que recebemos uma mensagem da Internet com um de nossos usuários na lista Para: e um dos outros usuários na lista Para: tem um domínio com um problema de DNS. Nesse caso, o sendmail obtém um erro de DNS no endereço incorreto e sai com "falha de pesquisa do nome do host", por isso a mensagem fica presa em nossa fila por alguns dias e nunca é entregue ao destinatário em nosso sistema.

Como exemplo, se eu enviar uma mensagem com essa frase Para::

  To: [email protected], [email protected]

swcp.com é um domínio local tratado por este servidor, e "bochechas" tem um alias local apontando para "bochechas @ ebi2". lovelacesandia.com é um domínio não local com um problema (atualmente todas as consultas resultam em SERVFAIL). O remetente de origem provavelmente tem uma cópia dessa mensagem presa em sua própria fila, porque eles também não podem acessar lovelacesandia.com. A cópia da mensagem que está presa na minha fila só tem um destinatário:

RPFDA:cheeks@ebi2

Aqui está a saída de "sendmail -v -d8-9.5 -qRcheeks"

Running /var/spool/mqueue/t7QHX1uB080255 (sequence 1 of 1)
host_map_lookup(swcp.com) => dns_getcanonname(swcp.com, trymx=1)
dns_getcanonname: trying swcp.com. (AAAA)
dns_getcanonname: trying swcp.com. (A)
dns_getcanonname: swcp.com
FOUND swcp.com
host_map_lookup(swcp.com) => CACHE swcp.com
host_map_lookup(ebi2) => dns_getcanonname(ebi2, trymx=1)
dns_getcanonname: trying ebi2.swcp.com (AAAA)
dns_getcanonname: trying ebi2.swcp.com (A)
dns_getcanonname: ebi2.swcp.com
FOUND ebi2.swcp.com
host_map_lookup(swcp.com) => CACHE swcp.com
getmxrr([ebi2.swcp.com], droplocalhost=1)
dns_getcanonname(ebi2.swcp.com, trymx=0)
dns_getcanonname: trying ebi2.swcp.com. (AAAA)
dns_getcanonname: trying ebi2.swcp.com. (A)
dns_getcanonname: ebi2.swcp.com
cheeks@ebi2... Connecting to ebi2.swcp.com. via smtp...
220 ebi2.swcp.com ESMTP Sendmail 8.15.1/8.14.9; Wed, 26 Aug 2015 11:44:59 -0600 (MDT)
>>> EHLO ame1.swcp.com
250-ebi2.swcp.com Hello ame1.swcp.com [216.184.2.118], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE 100000000
250-DSN
250-ETRN
250-STARTTLS
250-DELIVERBY
250 HELP
>>> STARTTLS
220 2.0.0 Ready to start TLS
>>> EHLO ame1.swcp.com
250-ebi2.swcp.com Hello ame1.swcp.com [216.184.2.118], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE 100000000
250-DSN
250-ETRN
250-AUTH PLAIN LOGIN
250-DELIVERBY
250 HELP
>>> MAIL From:<[email protected]> SIZE=1672
250 2.1.0 <[email protected]>... Sender ok
host_map_lookup(ebi2.swcp.com) => dns_getcanonname(ebi2.swcp.com, trymx=1)
dns_getcanonname: trying ebi2.swcp.com. (AAAA)
dns_getcanonname: trying ebi2.swcp.com. (A)
dns_getcanonname: ebi2.swcp.com
FOUND ebi2.swcp.com
>>> RCPT To:<[email protected]>
>>> DATA
250 2.1.5 <[email protected]>... Recipient ok
354 Enter mail, end with "." on a line by itself
host_map_lookup(swcp.com) => CACHE swcp.com
host_map_lookup(swcp.com) => CACHE swcp.com
host_map_lookup(lovelacesandia.com) => dns_getcanonname(lovelacesandia.com, trymx=1)
dns_getcanonname: trying lovelacesandia.com. (AAAA)
dns_getcanonname: trying lovelacesandia.com. (A)
dns_getcanonname: trying lovelacesandia.com. (MX)
dns_getcanonname: trying lovelacesandia.com.swcp.com (AAAA)
FAIL (2)
lovelacesandia.com: Name server timeout
timeout writing message to ebi2.swcp.com.
cheeks@ebi2... Deferred: Name server: ebi2.swcp.com.: host name lookup failure
Closing connection to ebi2.swcp.com.

Isso é com o Sendmail 8.15.1 no FreeBSD 10.1. Eu suspeito que esta condição existe há muito tempo, mas só recentemente diagnosticamos isso. A maioria das mensagens que se encaixam nesse cenário acabam sendo spam, então ninguém se importa. Mas ocasionalmente alguém envia um e-mail para uma lista grande de pessoas (sem usar o BCC) e um dos endereços deu errado.

Se estivéssemos envolvidos na tentativa de entregar ao endereço falso, eu entenderia porque tivemos um problema. O que eu não entendo é porque meu sendmail se preocupa com um endereço falso no cabeçalho Para: para o qual não vamos tentar entrega.

Temos esses recursos que achei que poderiam estar envolvidos:

FEATURE(blacklist_recipients)
FEATURE('delay_checks', 'friend', 'n')

Eu fiz testes com os dois removidos e obtive o mesmo resultado.

Se alguém tiver alguma ideia sobre o que causa isso ou como atenuá-lo, agradecemos. Obrigado,

Marcar

    

Answer 1

Com alguns experimentos rlytest , o sendmail não está tocando nos destinatários do cabeçalho; no entanto, no seu caso, o domínio ruim deve ter sido um destinatário, caso contrário, o endereço não será executado através do espremedor de pesquisa? Já que o sendmail tentará qualquer coisa destinada a um domínio que retorna SERVFAIL , um milter é independente da sua melhor aposta; configurar milter-regex é uma opção:

dnl for sendmail.mc
INPUT_MAIL_FILTER('milter-regex', 'S=unix:/var/spool/milter-regex/sock, T=S:30s;R:2m')dnl

E com esse daemon em execução e usando esse arquivo de soquete, um milter-regex.conf ao longo das linhas de:

discard
envrcpt /@lovelacesandia\.com>/i

Um fator complicador será se essas mensagens estiverem sendo entregues diretamente ao binário sendmail como o Agente de Envio de Mensagens. Nesse caso, a configuração submit.cf precisará ser alterada para chamar um milter ou instruída a não fazer isso. pesquisas de domínio e, em vez disso, canalizar tudo para o Agente de Transporte de Correio principal, que pode então fazer o descarte, se necessário.

    

Answer 2

Também fui atingido por esse problema.

Após algum tempo de pesquisa, uma solução possível é usar esse snippet em sendmail.mc :

FEATURE('nocanonify', 'canonify_hosts')
CANONIFY_DOMAIN('$=m')

Isso pode ter efeitos colaterais, conforme detalhado nos documentos, e não tenho certeza se é a melhor solução para o problema. Mas funciona por enquanto.