IIS / SMTP - os e-mails ficam presos na fila de correio / Fila

Estou tentando enviar emails via SMTP no diretório de recebimento do IIS. Infelizmente, os e-mails estão apenas entrando na pasta mailroot / fila e permanecendo lá. Eles nunca são realmente enviados.

Alguém sabe por que isso aconteceria e uma possível correção para o problema?

Teve um problema semelhante com os arquivos presos na fila. No gerenciador do IIS, Servidor Virtual SMTP> Propriedades> Entrega> Conexões de saída. A opção para Limit number of connections tofoi marcada e o valor foi 0. Portanto, ele foi configurado para nunca fazer nenhuma conexão de saída, fazendo com que os e-mails nunca saiam do servidor. Desmarquei a opção e reiniciei o servidor SMTP e estava tudo bem.

Eu tive esse problema hoje.

Depois de reiniciar o serviço 'SMTP (Simple Mail Transfer Protocol)', ele começou a funcionar novamente.

Apenas para constar: tivemos um caso em que o servidor não pôde mais resolver nomes devido a uma configuração de DNS incorreta. O comportamento resultante foi exatamente o que você descreveu.

IISRESET corrigiu isso para mim. Eu acredito que é semelhante à solução de redefinir o serviço SMTP, pois esse serviço depende do IIS. Depois de reiniciado, o correio dentro de C: \ inetpub \ mailroot \ Queue começou a desaparecer!

Encontrei esse problema recentemente. No meu caso, acabou por ser um problema com a definição do servidor DNS em um adaptador de rede (isso tem dois por algum motivo, sem o meu conhecimento). O servidor DNS designado foi definido como "127.0.0.1" em vez do normal "8.8.8.8" normalmente usado nesta rede. Alterei isso para o valor correto, reiniciei meu servidor SMTP e os emails em fila foram imediatamente distribuídos.

Como descobri isso para analisar o problema de definição de DNS:

• Utilizou o nslookup para encontrar um servidor mx para testar (testado 5 ou 6 diferentes)
• Tentei telnet para o servidor (toda vez que recebia uma mensagem "não conseguia conectar" que me fazia pensar inicialmente nos problemas do firewall)
• Tentou executar ping no valor do servidor mx testado (sempre que recebia uma mensagem "não foi possível conectar ao host")

Espero que isso ajude outra pessoa, não era algo que eu pensaria ver inicialmente.

Na minha experiência, isso geralmente ocorre porque o IIS SMTP tenta enviar e encontrar um erro temporário (código de resposta 4xx). Você ativou o log do serviço SMTP do IIS e revisou o log? Desculpe se isso é óbvio, mas é difícil saber a causa ou a correção sem saber o que o log mostra.

Acho que o problema pode ser que haja uma confusão entre o IPv4 e o IPv6 no sistema. Portanto, quando você especifica localhost, o protocolo IPv6 padrão é escolhido. Eu tive o mesmo problema hoje e foi corrigido depois que a referência do host local ao endereço IPv6 nos hosts foi resolvida, embora isso possa ter sido uma coincidência (também estou configurando o SVN). Então, aqui está a minha configuração, apenas no caso de:

1. No IIS7, tenho a opção "Entregar no servidor SMTP" ativada com o host local como o servidor escolhido.
2. No IIS6, tenho acesso definido como apenas 127.0.0.1, sem autenticação para entrada ou saída.

Eu brinquei com as configurações o dia todo, para ser honesto, sem saber o que mais poderia ter influenciado o fato de que está funcionando agora. Espero que isso ajude pelo menos um pouco.

O primeiro lugar para procurar são os arquivos de log do servidor. Isso informará se o servidor está tendo problemas para enviar para hosts específicos. Na maioria das vezes, isso acontece (nas minhas experiências) geralmente é o DNS (do seu lado ou remotamente) que é o culpado.

O servidor SMTP está procurando um host / gateway SMTP para o qual enviar o email.

Se você está tentando enviar para o host local, o IP do host local seria o gateway. Se você estiver tentando enviar para um endereço de e-mail externo, como o Gmail ou o Hotmail, precisará adicionar o gateway de e-mail do seu ISP como host inteligente.

Para configurar um host inteligente:

1. No Gerenciador do IIS, clique com o botão direito do mouse no servidor virtual SMTP e clique em Propriedades.
2. Clique na guia Entrega e clique em Avançado.
3. Na caixa Host inteligente, digite o nome do servidor host inteligente. Você pode digitar uma sequência para representar um nome ou inserir um endereço IP.
4. Se você deseja que o serviço SMTP tente entregar mensagens remotas diretamente antes de encaminhá-las ao servidor host inteligente, marque a caixa de seleção Tentar entrega direta antes de enviar ao host inteligente. O padrão é enviar todas as mensagens remotas para o host inteligente, não tentar a entrega direta.

Eu tive o mesmo problema depois de mudar o serviço de email de um host para outro (o novo é o Office 365). Após várias tentativas e erros, ele finalmente começou a funcionar, fazendo o seguinte:

1. Adicionar meu domínio de email ao IIS 6 como um domínio "remoto". (Este é o domínio hospedado no O365 e usado por todas as contas de usuário.)
2. No IIS 6, clique duas vezes nesse domínio; em "Domínio de rota", selecione "Encaminhar todos os emails para o host inteligente" e digite seu servidor (no meu caso, "smtp.office365.com"). Marque também a caixa "Permitir a retransmissão de emails para este domínio".
3. No IIS 6, clique com o botão direito do mouse no servidor virtual SMTP> Propriedades.
   • Guia Geral: Clique em Avançado e adicione o IP e a porta 587 do servidor local.
   • Guia Acesso: verifique se "Requer criptografia TLS" está marcado. Eu tive que criar um certificado de domínio no IIS 7 com o nome do meu domínio de email.
   • Guia Acesso: adicione o IP do servidor local às listas "Conexão" e "Retransmissão".
   • Guia Entrega: Segurança de saída: selecione autenticação básica, insira credenciais de um usuário licenciado válido; marque a caixa "criptografia TLS"
   • Guia Entrega: conexões de saída: digite 587 para a porta TCP
   • Guia Entrega: Avançado: insira seu domínio de email como "Nome de domínio totalmente qualificado" e seu servidor de email como "Host inteligente" (novamente no meu caso, smtp.office365.com).

Firewall: Eu li que você precisa abrir a porta 587 para saída. (Não o fiz porque este é um servidor VOIP que precisa do seu firewall desativado.)

Office 365: adicione um "conector" em Admin> Exchange para permitir seu IP estático local. A Microsoft fornece essas instruções online.

Deparamos com esse problema recentemente. Alguém instalou o MalwareBytes no servidor smtp e as pastas smtp mailroot não estavam na lista de permissões. O software tratou tudo na fila como uma potencial campanha de spam e permitiu que o tempo limite atingisse o tempo suficiente para passar para o correio incorreto. Todos os domínios foram afetados. Me deixou perplexo (operação impecável há anos ...) até que olhei para os processos em execução e notei o exe do mbam.

Eu tive o mesmo problema. Como outros afirmaram, estava relacionado ao DNS. Eu tenho uma zona de pesquisa direta em nossos servidores DNS internos para o nosso nome de domínio público (que é diferente do nosso nome de domínio interno). Eu tive que adicionar os registros MX nessa zona de pesquisa direta interna para corresponder aos registros MX em nossos registros DNS de domínio público. Isso resolveu o problema.