Precisa de ajuda para configurar os erros de relay do Sendmail / Conexão recusada

Question

Estou executando o Ubuntu 10.04 com o Sendmail em uma VM do VMWare. No meu arquivo mail.log eu tenho milhares de erros Connection Refused, e eu gostaria de me livrar deles. Existem vários erros a cada segundo e estou convencido de que esse problema está fazendo com que alguns dos nossos emails legítimos não sejam enviados.

Exemplo:

Jul 13 08:20:02 mail sm-msp-queue[28076]: s6C3K6e0008595: to=root, ctladdr=smmsp (115/126), delay=1+08:59:56, xdelay=00:00:00, mailer=relay, pri=8940371, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]
Jul 13 08:20:02 mail sm-msp-queue[28076]: s6C3K19D008593: to=smmsp, delay=1+08:59:58, xdelay=00:00:00, mailer=relay, pri=8941647, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]
Jul 13 08:20:02 mail sm-msp-queue[28076]: s6D2K2lX023270: to=postmaster, delay=09:59:56, xdelay=00:00:00, mailer=relay, pri=9331939, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]
Jul 13 08:20:02 mail sm-msp-queue[28076]: s6C7e3Cp010618: to=postmaster, delay=1+04:39:47, xdelay=00:00:00, mailer=relay, pri=9754324, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]
Jul 13 08:20:02 mail sm-msp-queue[28076]: s6BNe474006871: to=root, ctladdr=smmsp (115/126), delay=1+12:39:58, xdelay=00:00:00, mailer=relay, pri=9930371, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]
Jul 13 08:20:02 mail sm-msp-queue[28076]: s6CMK1lb021417: to=root, delay=13:59:57, xdelay=00:00:00, mailer=relay, pri=10410356, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]
Jul 13 08:20:02 mail sm-msp-queue[28076]: s6BLK2Bk005641: to=postmaster, delay=1+14:59:56, xdelay=00:00:00, mailer=relay, pri=10571717, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]
Jul 13 08:20:02 mail sm-msp-queue[28076]: s6BK01i9004244: to=postmaster, delay=1+16:20:00, xdelay=00:00:00, mailer=relay, pri=10926911, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]'

Eu li onde um problema em potencial é o sendmail não está escutando na porta 25, então eu corri este comando

# sudo netstat -a -n -p |grep 0.0.0.0:25
tcp        0      0 0.0.0.0:25                  0.0.0.0:*               LISTEN      1137/sendmail: MTA:'

Eu também tentei alterar as linhas:

DAEMON_OPTIONS('Name=MTA, Addr=127.0.0.1, Port=smtp')dnl'
DAEMON_OPTIONS('Name=MSP, Addr=127.0.0.1, Port=submission')dnl'

no meu sendmail.mc e reconstruindo a configuração do sendmail, mas não consegui enviar e-mails quando o fiz.

Também estou anexando uma cópia do meu arquivo de hosts, já que não tenho 100% de certeza de que está correto.

127.0.0.1 example.org localhost localhost.localdomain mail.example.org.localdomain'
10.1.1.204 example.org mail.example.org mail.example.ci.oh.us mail-server'

Nosso servidor de e-mail 'mail.example.org' manipula todos os e-mails retransmitidos de nosso servidor da web 'example.org' Essa parte sempre me confunde, mas foi configurada assim quando assumi o gerenciamento desses servidores.

Obrigado por qualquer ajuda e deixe-me saber se você precisa de mim para postar qualquer outra coisa. Eu farei o que for preciso para corrigir esses erros.

    

Answer 1

Você pesquisou os logs do sendmail para rejecting connections ... ?
O Sendmail pode se recusar a aceitar conexões de entrada quando a média de carga do sistema é muito alta.

Verifique o número de mensagens na "fila do cliente" ( mailq -Ac ) - em alguns casos, esses problemas foram causados por um grande número de mensagens de spam na fila do cliente. devido a páginas web "spam" hospedadas / invadidas.
Como ler enorme clientmqueue em formato humano?

Você pode aumentar a "média de carga recusada" do padrão 12 usando a seguinte linha no seu arquivo sendmail.mc:

define('confREFUSE_LA','20')  

"Sendmail Performance Tuning" de Nick Christenson (página 139) fala sobre a configuração entre 12 e 20 no servidor não Linux dedicado e ainda mais alto no servidor Linux dedicado. [O Linux calcula a média de carga de uma maneira diferente]

O Sendmail-8.14.0 introduziu a opção para defini-lo como o parâmetro DaemonPortOptions. Você pode usá-lo para definir diferentes refuseLA para loopback (127.0.0.1), endereços IP internos e públicos.

    

Answer 2

Parece que as mensagens estão sendo adiadas, por isso pode ser que você tenha algumas mensagens na fila que estão sendo repetidas várias vezes. Dê uma olhada na sua fila (mailq) para ver se esse pode ser o caso.

Você pode examinar mensagens individuais na sua fila: Vá para o diretório de filas e você terá dois arquivos para cada e-mail, um começando com df * e outro com qf *. Combinados eles compõem toda a mensagem (um contém informações sobre os detalhes da fila, o outro o conteúdo do e-mail ... sim explicação propositalmente simplificada :-)). Se você observar os detalhes e decidir que deseja remover a mensagem da fila, basta excluir os dois arquivos para o mesmo ID da fila. Alternativamente, você poderia mover todos os arquivos para outro diretório que os removeria da fila, onde você poderia olhar em seu tempo livre e voltar qualquer um que você realmente quisesse tentar reenviar (eu nunca encontrei um problema de ID de fila fazendo então .. mas naturalmente você está entrando no meio do processo normal do sendmail fazendo isso).

Se eles forem legítimos e precisarem ser repetidos, talvez seja necessário ajustar as configurações de nova tentativa em sua configuração do sendmail para que sejam tentadas com menos frequência (tanto a frequência quanto o tempo total antes de desistir e gerar uma notificação de falha na entrega). Vou deixar esse exercício de olhar através dessas configurações para você (fácil de encontrar na própria configuração, ou com uma pesquisa básica na web).

Determinar quais são as mensagens é o primeiro passo, para que você possa ver se algo está preenchendo sua fila ou simplesmente tentando enviar um e-mail inválido, etc.

Quanto ao servidor web que retransmite através do servidor de email que não é tão incomum. Normalmente, ter apenas um ponto de saída para o correio facilita o gerenciamento de itens como seus registros SPF, etc. O cuidado normal é garantir que seu servidor da Web não seja comprometido e transformá-lo em um spammer (já que seu servidor de correio retransmitirá tudo que enviar). claro, garantido.

Por fim, a única maneira que normalmente veria essas tentativas / conexões afetando o e-mail legítimo é se você está lidando com uma fila grande o suficiente para que e-mails legítimos sejam aguardados por novas tentativas. Isso normalmente não é o caso, pois um novo e-mail será tentado primeiro na fila ... no entanto, se for adiado por um motivo legítimo normal, ele terá que passar pela repetição normal da fila.

Adição: Ao analisar sua entrada de log, ela fornece o ID da fila. Por exemplo, se a entrada "s6C3K6e0008595" ainda estiver na sua fila, você terá um arquivo qfs6C3K6e0008595 e dfs6C3K6e0008595 que poderá examinar.