Não é possível receber emails de determinados domínios com o Exchange 2003.

Question

Recentemente tive um problema com meu servidor do Exchange 2003. Não consigo receber e-mails de determinados domínios. Existem apenas dois nomes de domínio em particular (apenas um usuário de cada domínio tentou enviar e-mails para nosso domínio).

Eu alterei os filtros para testar se era um problema de filtragem sem sucesso. Também procurei nos registros de controle de mensagens, mas não recebi nenhum email de nenhum domínio quando o remetente disse que enviaram vários e-mails de teste. Eu posso fazer telnet no servidor e obter respostas EHLO e HELO apropriadas, não estamos na lista negra e tudo parece correto.

Eu queria saber se alguém tinha alguma sugestão sobre o que eu posso verificar em seguida ou investigar. Se eu esqueci informações cruciais sobre isso, me avise e postarei mais informações. Desde já, obrigado.

    

Answer 1

Suponho que você esteja recebendo e-mails diretamente da Internet por meio de um registro MX que se refere ao seu computador com o Exchange Server (com base em suas declarações re: usando TELNET para executar o SMTP "manualmente"). Se você tiver algum filtro anti-spam / antivírus em vigor, deve duplicar / triplicar a verificação antes de começar a reclamar com os administradores de sistema de terceiros.

Tendo dito isso, o melhor lugar para solucionar isso, em seguida, seria no final do remetente. Se você não conseguir obter tração deles para monitorar o fluxo de e-mails enviados, poderá tentar capturar o tráfego do seu lado, mas é provável que você tenha um palheiro gigantesco para vasculhar.

Os remetentes devem procurar logs do protocolo SMTP ou qualquer sistema de email equivalente ao "Message Tracking" do Exchange (/var/log/mail.log, etc) para descobrir como o servidor configurou uma mensagem com falha (que o enviar usuário deve poder ajudá-los a identificar em seus logs). Supondo que eles estão "perdendo" a mensagem, bloqueando por política, etc, é bobagem que seus servidores não estejam enviando uma notificação de falha na entrega para o usuário que está enviando. O e-mail de saída do Black-holing nunca é a resposta. (Enviar NDRs para o e-mail de entrada, sem dúvida, pode não ser uma ótima idéia. Sim, sim-- eu sei que várias RFCs dizem que você deve ... > suspiro <)

Se os remetentes não puderem ajudá-lo, sua única esperança é, muito provavelmente, capturar o tráfego em sua fronteira e tentar identificar tentativas de conexão (ou a falta delas) de seu servidor de saída. Supondo que você possa obter alguém para enviar uma mensagem no comando (digamos, durante uma chamada telefônica) e supondo que a infra-estrutura de servidor de saída não demora muito para processar a mensagem, você deve conseguir capturar uma conversa SMTP com o servidor do remetente ( ou nada, se nunca chegar até você).

Na verdade, isso não é problema seu, de uma perspectiva técnica. Infelizmente, os usuários e o gerenciamento não entendem a natureza do "faroeste" do e-mail da Internet e frequentemente o veem como uma forma confiável de comunicação. Quando a realidade prova o contrário, eles culpam o sysadmin de e-mail mais próximo, em vez de aceitar isso, não diferentemente do correio postal, não é um sistema confiável.

    

Answer 2

Este é um problema que pode dar errado em três lugares:

1. O remetente. O servidor de e-mail no site do remetente realmente funciona?
2. O receptor. Em outras palavras: você
3. Muitos lugares entre os dois.

Para 1) você obviamente precisa da ajuda da pessoa que gerencia o e-mail no site do remetente. Não há muito o que você possa fazer exceto perguntar se eles estão bloqueando e-mails específicos (por exemplo, bloqueando todos os e-mails de um determinado tamanho e essa pessoa se você enviar arquivos iso enormes)

2) O receptor: Bem, você parece ter verificado a maioria das coisas no seu ponto final. E você recebe todos os outros emails (bem, bar outro remetente). A única coisa que resta verificar é se você recebe seu e-mail diretamente ou por meio de terceiros.

3) Se o servidor de e-mails dos remetentes não contatar diretamente seu servidor de e-mail, mas usar uma rota indireta, você terá alguns lugares adicionais onde as coisas podem dar errado. Tudo fora do seu controle.

Pessoalmente, tive um problema semelhante quando os spammers começaram a colocar seus spams em arquivos PDF. Todos ou o e-mail foi recebido por meio de uma agência de filtragem de spam e eles decidiram que todos os PDFs não eram suspeitos. Esses e-mails ficaram em quarentena e o destinatário final recebeu um e-mail uma vez por semana informando que havia feito uma quarentena de correspondências. (A configuração de uma vez por semana foi explicitamente definida pelo usuário e imediatamente esquecida). Algo semelhante poderia ser o caso.

    

Answer 3

O que você precisa fazer é informar aos administradores de e-mail nesses domínios (e aos usuários, se aplicável) que você só pode entregar e-mails que realmente chegam. Se não chegar aos seus sistemas, não há nada que você possa fazer sobre isso, ponto final.

Eu tive esse "problema" impingido em mim dezenas de vezes como um administrador do Domino ou Exchange e a resposta é sempre a mesma. O problema está no final do remetente (e eu já vi alguns retardados dessa natureza) ou em algum lugar entre você e eles. De qualquer forma, está fora de seu controle e não há nada que você possa fazer sobre isso.

"Ei, [outro admin de email], sua merda está quebrada. Conserte" vem gritando como a resposta enlatada que eu adoraria dar toda vez que isso acontece.

    

Answer 4

isso está acontecendo com todos os e-mails dos domínios específicos? Se você entrar em contato com a TI deles, de quais endereços IP eles enviarão?

Se eles estão sempre falhando, devem ter uma notificação da falha e por quê. Faça com que eles encaminhem a falha para sua conta de e-mail pública para que você possa ver o aviso de rejeição.

Você pode verificar se uma conexão foi tentada nos logs do IIS. Há um log de SMTP. Aumente o nível de registro, se necessário. Procure seu IP.

Isso também pode ser um problema de firewall do seu lado. Se você puder, tente ver se consegue ver os logs. Certifique-se de ter as atualizações mais recentes.

Eu também vi conexões ineternet ruins causarem esse problema. Realize um ping contínuo por 10 minutos para o seu ISP ou algum outro site que não se importe com o teste. Pacotes de alta latência ou com falha significa que você precisa falar com seu ISP sobre a linha.

Por fim, se você tiver os recursos, configure um servidor linux de filtragem de SPAM. Uma VM em execução em outra máquina que encaminha emails para seu servidor Exchange será boa. Se isso ainda acontece, então você sabe que não é o seu servidor de e-mail e você recebe uma camada extra de filtragem ...

    

Answer 5

Teste o telnet em cada um dos seus registros MX. Eu já me deparei com uma situação semelhante que acabou sendo causada por uma combinação do sistema de envio sempre usando um registro MX de prioridade mais baixa e um sistema que aceitou apenas entregas no primário. Os secundários simplesmente engoliam as mensagens sem repassá-las nem devolvê-las.

Naquele caso em particular, o sistema defeituoso era o MessageLabs, que é um serviço de filtragem de spam da Symantec, cujos operadores alegavam que o sistema agia assim porque, e cito, "somente spammers usam os secundários". A única solução disponível para mim foi eliminar todos os registros MX, exceto o principal, já que o cliente desejava continuar usando o MessageLabs para filtragem.

    

Answer 6

O log de controle de mensagens é útil apenas para emails que chegam ao Exchange e, mais especificamente, para emails que são entregues no armazenamento de informações. Os emails bloqueados pela filtragem do Destinatário ou do Remetente não serão exibidos no log de controle de mensagens, mas serão exibidos no log do SMTP. Você precisa ativar o log no serviço SMTP no servidor Exchange, pois esse é o ponto de "entrada" dos emails que chegam ao seu servidor Exchange. Os e-mails bloqueados pela filtragem de conexão não serão exibidos no log do SMTP, portanto, será necessário ativar o log no firewall ou roteador, pois esse é o ponto de "entrada" dos e-mails que chegam à sua rede. Se não houver entradas no log de controle de mensagens, no log do SMTP ou no log do seu firewall / roteador, você poderá ter certeza de que os emails em questão não estão chegando à sua rede e / ou ao servidor Exchange.

Em seguida, você precisa verificar se o DNS público está correto e se os registros NS, MX e A associados estão corretos e se estão resolvendo corretamente. Se houver um erro de configuração no seu DNS, esse é um possível ponto de falha para os servidores de e-mail externos que tentam enviar e-mails para seus domínios. Se houver problemas com seu DNS público, esse é o seu problema e você precisa corrigi-lo.

Se os registros mencionados acima não mostrarem entradas e seu DNS público estiver configurado e funcionando corretamente, e somente então, você poderá dizer com certeza que o problema não está do seu lado.