Alguns remetentes de domínios externos que recebem erros de "Usuário desconhecido"

Question

Tanto quanto eu posso dizer, esta questão ainda não existe aqui, mas se isso acontecer, então peço desculpas.

A partir de 1º de janeiro, o nome da nossa empresa mudou e, como tal, nossos endereços de e-mail foram alterados. O switch foi bem com exceção de alguns erros estranhos de "5.1.1 User Unknown" que alguns remetentes externos estão recebendo quando tentam enviar e-mails para nós.

Falei com um consultor externo para descobrir o que aconteceu e eles parecem achar que os destinatários têm registros DNS obsoletos. Os registros MX do nosso servidor existem em nosso DNS externo há mais de um mês. O novo domínio foi definido como nosso domínio "Principal" em 1º de janeiro.

Consegui obter alguns dos relatórios de erros dos destinatários e eles se parecem com isso. Qualquer ajuda seria apreciada com este assunto

The following recipient(s) cannot be reached:
      'User Name' on 13/01/2012 11:07 AM
            550 5.1.1 <[email protected]>... User unknown

EDIT: O domínio listado acima é o "novo domínio". Os e-mails enviados para o domínio antigo ainda são enviados sem problemas. Também posso verificar se a política foi definida para esse usuário e se o novo endereço de e-mail existe na guia "Endereços de e-mail".

EDIT 2: O servidor de email de recebimento está executando o VamSoft ORF para anti-spam. Nem os logs ORF da Vamsoft nem os logs de troca mostram qualquer sinal de que os e-mails chegam ao nosso domínio, no entanto, quando eles usam o domínio antigo, eles passam sem problemas.

    

Answer 1

A chave para solucionar esse problema é fazer com que alguém analise os logs da transação SMTP de saída no servidor do remetente. Você pode tentar correlacionar suas falhas com seus próprios logs de controle de mensagens, logs de protocolo SMTP ou sniffing de tráfego, mas os melhores dados virão do próprio servidor SMTP do remetente. Se o remetente tiver uma equipe de TI, recomendo trabalhar para entrar em contato com eles. Caso contrário, tente fazer com que o remetente forneça os relatórios de falha na entrega com os cabeçalhos completos de transporte.

Você precisa saber em qual servidor SMTP o remetente está realmente tentando realizar a entrega e, a partir daí, você deve ser capaz de rastrear a origem do problema. Se eles estão conversando com um servidor que você controla, então você deve ser capaz de obter um log da conversa SMTP, possivelmente todo o caminho até um farejamento de tráfego. Se eles não estão falando com um servidor que você possui, então você precisa descobrir por que eles não estão (ou seja, cache DNS obsoleto).

Pesquisas de DNS em cache para momentos totalmente inapropriados não são completamente desconhecidas, mas também não são comuns. Se você souber quem o remetente está usando para um servidor DNS upstream, tente fazer algumas pesquisas de registros MX para o seu domínio em relação a esse servidor DNS para ver o que você recebe de volta.

    

Answer 2

I've spoken to an external consultant to get their take on it and they seem to think the recipients have stale DNS records

Envie este "consultor" para o cu! Ele gera um absurdo analfabeto ! I SMTP-session instalada com o coletor correto (atribuída como MX para domínio e domínio manipulado no servidor) e apenas alguns e-mails não são mapeados para o problema de destino existente suas regras de rewiting locais | MDA no Exchange ou ( provavelmente existente ) border-MTA - não posso dizer mais sem exploração em deep-path-path para o seu subsistema de correio.

Infelizmente, eu não sei nada sobre o MTA do Exchange (exceto conhecido no denominador mundial de postmaster "Bullshit!"), mas, como postmaster de longa data, pode ver:

• você tem que identificar, o que seu servidor realmente gera salto (no caso de processamento encadeado "border-internal")
• melhor será encontrar todos os e-mails (usuários locais), que os e-mails recebidos são devolvidos
• depurar (monitorar) sessões SNTP de entrada para esses usuários em tempo real (se o gerador de problemas tiver capacidade de depurar) OR comparar usuários "ruins" e "bons" e pesquisar diferença nas definições

Adicionado após discussão com Evan

Você tem que identificar, que o correio não entregue é o seu problema no seu servidor. Solicite a qualquer proprietário de encaminhamento de email de resposta ("MIME-forward", com a mensagem original completa como anexo) e verifique os cabeçalhos de rejeição ( Received ) para confirmar (ou rejeitar) o envolvimento de seu MTA como segurança / p>

Do meu lado eu posso oferecer (alguma quantidade) meu tempo, atenção, mente, mãos e meu smtp-emitter para execuções de teste de SMTP de entrada