Eu executo meu próprio servidor de email em uma VM Linux do Azure com Postfix. Como eu estava sob forte ataque de spam, reforcei minhas medidas de segurança do servidor de e-mail.
Sem entrar nas coisas de segurança, hoje notei algo particularmente incomum.
O Postfix não estava recebendo e-mails de alguns domínios conhecidos. Apenas alguns
# /var/log/mail
postfix/smtpd[40702]: NOQUEUE: reject: RCPT from xxxx.ing.net[xx.xx.xx.xx]: 451 4.3.5 <[email protected]>: Sender address rejected: Server configuration problem; from=<[email protected]> to=<xxxxxxxxxx> proto=ESMTP helo=<xxxx.ing.net>
# /var/log/warn
postfix/smtpd[32944]: warning: problem talking to server private/spf-policy: Connection timed out
O que eu fiz foi pingar o registro SPF em ing.com/ing.net
Da minha caixa do Windows nslookup
ing.com
Server: [8.8.8.8]
Address: 8.8.8.8
Risposta da un server non autorevole:
ing.com text =
"MS=ms77059065"
ing.com text =
"v=spf1 include:_spf.ing.net ip4:91.209.197.6 ip4:89.20.160.55 ip4:78.136.53.254 ip4:95.138.135.251 ip4:92.52.81.2 ip4:146.148.26.249 ip4:83.231.160.132 ip4:83.231.160.128/26 ip4:212.187.169.64/26"
" include:_spf_mx.solvinity.com include:mailplus.nl ip4:24.157.48.85 ip4:141.155.214.85 ip4:160.34.64.28 ip4:192.254.112.185 ip4:118.127.87.207 ip4:128.242.118.200 ip4:62.73.172.35 ip4:83.217.248.35 ip4:91.209.197.7 -all"
ing.com text =
"adobe-idp-site-verification=8b81f7b92ccac0b65bab7d47f9fcecaeda6f04ac870b79133d8ac54be7b53534"
ing.com text =
Da caixa do servidor de e-mail nslookup
> nslookup
> set type=txt
> ing.com
;; Truncated, retrying in TCP mode.
Da caixa do servidor de correio, configurar o servidor DNS para 8.8.8.8 retorna a mesma carga SPF.
A pergunta é: o que está causando esse problema com a resolução DNS TXT na VM do Azure? Antes de alterar cegamente as configurações de DNS do sistema, gostaria de entender o erro e sua causa e por que acontece apenas no DNS padrão do Azure
Parece que mudar o DNS para o DNS público do Google funciona e atualmente é a única maneira de fazer o SPF funcionar.
Acontece que, se uma consulta DNS for maior que 512 bytes, ela não poderá ser transmitida pelo UDP padrão.
nslookup
, pelo que pude ver, muda para TCP automaticamente.Mas o servidor DNS tem que suportar consultas TCP, ou seja, deve estar escutando TCP 53.
O problema parece estar na infraestrutura do Azure. O DNS (
168.63.129.16
) provavelmente está configurado incorretamente, simplesmente porque o tempo limite é excedido ao usar o TCP.(Dorme)
Tal problema não ocorre com outros serviços DNS, então isso me permite pensar que não é um problema com o firewall local do appliance
SuSEfirewall
.Alternar
/etc/resolv.conf
para qualquer outro DNS público (por exemplo8.8.8.8
, ) permite que a consulta TCP e o SPF retornem ao trabalho.Uma desvantagem é que algumas listas negras de spam não são muito amigáveis com o DNS do Google.
Por exemplo, eu tive que comentar no meu
main.cf
Os logs foram girados, então não consigo lembrar a mensagem de erro exata que recebi com esse RBL.