Normalmente, os atrasos por email são problemas de DNS.
Tente executar:
host -t mx problemdomain.com
Se isso não parece ser o problema, use sendmail -bi -v para obter mais resultados de depuração.
Em nosso servidor da Web, o comando PHP mail() fica pendurado em alguns endereços de e-mail, mas é bom para a maioria. Ele é interrompido por mais de 2 minutos, período em que o script PHP perdeu a conexão com o banco de dados, então retorna um erro para o navegador.
Nós usamos sendmail e eu posso ver um atraso de 2:36 no log de e-mail ( / var / log / maillog ) para o endereço de e-mail que causa o problema :
Dec 9 11:24:00 liveserver sendmail[12666]: nB9BLOHa012666: to=***blanked_out***, delay=00:02:36, mailer=esmtp, pri=31326, dsn=4.4.3, stat=queued
É fácil reproduzir o problema. Eu posso colocar o email que quero testar no seguinte comando:
echo "Test message from sendmail." | sendmail [email protected] [email protected]
A maioria dos endereços de e-mail faz com que o comando retorne dentro de 1s (incluindo endereços de e-mail inválidos). Mas o endereço de e-mail problemático fica por 2:36.
Observação: Atualmente, temos 550 mensagens em fila - mas esse número não está acima do normal ( find /var/spool/mqueue -type f -name qf\* -print|wc -l|tr -d ' ' ).
Talvez seu dns emite, tente fazer um dig do problemmail.com.
Você também pode tentar strace e ver o que o processo faz:
anexar ao processo:
strace -ff -s 512 -v -p pid
iniciar o processo com strace:
strace -ff -s 512 -v sendmail -ffromtest ...........
adicione -o ~ / sendmail.strace para a saída em um arquivo.
-ff faz seguir os garfos
Para responder minhas próprias perguntas (no caso de ser útil para outras pessoas):
Why doesn't sendmail queue the message and return immediately so PHP can continue running?
Deveria fazer. Se isso não acontecer, significa que a configuração do servidor DNS está quebrada. Normalmente, as pesquisas de DNS são rápidas - Uma consulta em um domínio / domínio inexistente deve receber uma resposta NXDOMAIN dentro de milissegundos. Ele não deve esperar tanto tempo - esse problema provavelmente está causando outros problemas com muitos programas, por exemplo, sshd e NFS?
Does anyone have any tips for debugging the issue?
Tente executar:
host -t mx problemdomain.com
Em seguida, execute-o novamente usando o googleDNS (endereço IP de 8.8.8.8) em vez do serviço DNS atual:
host -t mx problemdomain.com 8.8.8.8
Se houver uma diferença, significa que a configuração atual do servidor DNS está quebrada. Verifique os servidores de nomes em /etc/resolv.conf e, talvez, crie um ticket de problema com a empresa de hospedagem ou quem fornece os servidores de nomes que você está usando?
Como solução temporária, tente adicionar um tempo limite de DNS em /etc/resolv.conf :
timeout: n
sets the amount of time (in seconds) the resolver will wait for a response from a remote name server before retrying the query via a different name server.
Does anyone have any tips on how to probe the problematic email address to see why it is causing a delay?
Teste dig , um utilitário de pesquisa de DNS e monitore o código de status. por exemplo. NOERROR para sucesso, NXDOMAIN para não encontrado, etc:
dig problemdomain.com
Teste o nslookup , um programa para consultar servidores de nomes da Internet:
nslookup problemdomain.com
Tente cronometrar o comando sendmail e use -bi -v para obter mais informações:
time echo "This is a test message" | /usr/lib/sendmail -bi -v [email protected] [email protected]