Não entrega do correio (NDR) do Exchange 2003, atividade de spam? eventos 7002 e 7004

4

Windows Server 2003, Small Business Server SP2
Exchange versão 6.5 (compilação 7638.2: Service Pack 2)

Essa rede foi negligenciada e vem tendo problemas de e-mail há anos e estava em muitas listas negras. Eu fui chamado depois que o servidor eventualmente caiu ... O servidor voltou a funcionar, mas os problemas de email persistem.

A entrega de mensagens de saída é esporádica. Às vezes, o e-mail é enviado, às vezes um relatório de entrega atrasada é gerado após um dia ou mais, e às vezes parece passar, mas o destinatário nunca o recebe.

Não tenho certeza se os spammers estão usando com sucesso o servidor como um relé (veja entradas de eventos abaixo depois de ativar o registro máximo de SMTP) ...

  • Usuários de computadores infectados com vírus e servidores foram colocados em listas negras em muitos sites (usei o mxtoolbox.com)
  • Limpei todos os PCs e mudei todas as senhas (incluindo o administrador)
  • Solicitei a remoção de todas as listas negras - a maioria removeu a listagem, outras demoram mais tempo.
  • Eu configurei os registros do ponteiro do rDNS com o ISP (Comcast) - essa foi uma das razões para algumas das listas negras.

  • Eu testei que não é um relé aberto usando telnet como descrito aqui:
    www.amset.info/exchange/smtp-openrelay.asp

  • Eu segui o conselho de um Spamhaus & Artigo da Microsoft para habilitar o log máximo do SMTP. link
    que me direcionou para o artigo 895853 da Microsoft, especificamente, a parte 2/3 abaixo intitulada:
    "Se a retransmissão de email ocorrer em uma conta em um computador com Exchange que não esteja configurada como retransmissão aberta" .

O log de eventos do aplicativo está preenchendo esse tipo de atividade (erros de ID de evento 7002, 7002 e 3018):

Tipo de evento: erro
Origem do evento: MSExchangeTransport
Categoria do evento: Protocolo SMTP
ID do evento: 7004
Data: 1/18/2011
Horário: 7:33:29 AM
Usuário: N / A
Computador: SERVIDOR
Descrição:
Este é um log de erros do protocolo SMTP para o ID do servidor virtual 1, conexão # 621. O host remoto "212.52.84.180", respondeu ao comando SMTP "rcpt" com "550 # 5.1.0 Endereço rejeitado [email protected]". O comando completo enviado foi "RCPT TO:". Isso provavelmente fará com que a conexão falhe.

e isso:

Tipo de evento: Aviso
Origem do evento: MSExchangeTransport
Categoria do evento: Protocolo SMTP
ID do evento: 7002
Data: 1/18/2011
Horário: 7:33:29 AM
Usuário: N / A
Computador: SERVIDOR
Descrição:
Este é um log de aviso do protocolo SMTP para o ID do servidor virtual 1, conexão nº 620. O host remoto "212.52.84.170" respondeu ao comando SMTP "rcpt" com "452 Muitos destinatários receberam esta hora". O comando completo enviado foi "RCPT TO:". Isso pode causar falha na conexão.

ou uma variante de:

Tipo de evento: Aviso
Origem do evento: MSExchangeTransport
Categoria do evento: Protocolo SMTP
ID do evento: 7002
Data: 1/18/2011
Horário: 8:39:21 AM
Usuário: N / A
Computador: SERVIDOR
Descrição:
Este é um log de aviso do protocolo SMTP para o ID do servidor virtual 1, conexão nº 661. O host remoto "82.57.200.133", respondeu ao comando SMTP "rcpt" com "421 Service not available - too busy". O comando completo enviado foi "RCPT TO:". Isso pode causar falha na conexão.

também

Tipo de evento: erro
Origem do evento: MSExchangeTransport
Categoria do evento: NDR
Identificação do evento: 3018 Data: 1/18/2011
Horário: 9:49:37 AM
Usuário: N / A
Computador: SERVIDOR
Descrição:
Um relatório de falha na entrega com um código de status 5.4.0 foi gerado para o destinatário rfc822; [email protected] (Message-ID).
Causas: Esta mensagem indica um problema de DNS ou um problema de configuração de endereço IP. Solução: verifique o DNS usando nslookup ou dnsq. Verifique se o endereço IP está no formato literal do IPv4.
Dados:
0000: ef 02 04 c0 ï..À

Qualquer orientação e / ou sugestões e / ou testes para realizar seria muito apreciada.

    
por HighTechGeek 18.01.2011 / 15:27

1 resposta

0

Para corrigir isso, obtenha um novo endereço IP para o seu servidor de e-mail de saída o mais rápido possível. Lembre-se também de realinhar o DNS reverso para o endereço IP. Continue também com as remoções da lista negra. Se você não puder obter um IP externo, considere um serviço de filtragem de mensagens de terceiros ou um gateway.

Como acompanhamento, não envie e-mails diretamente do Exchange para a Internet. Se possível, coloque em um gateway de correio secundário que lhe permitirá gerenciar melhor seus e-mails enviados. Você pode configurá-lo com muita facilidade se tiver um pouco de experiência com o Linux, e também pode manter um bom registro de quem está usando seu servidor de e-mail para o quê. Você também pode fazer isso ativando o log de SMTP no servidor virtual SMTP em troca, mas acho que até mesmo esse log é um pouco difícil de obter medições precisas.

Se você não puder usar um gateway, mesmo que apenas como medida temporária, use um provedor externo, como postini ou laboratórios de mensagens. link

    
por 12.02.2011 / 17:33