Smtp envia via Exchange algumas mensagens não completam mas ainda enviam - por quê?

Question

Eu tenho um aplicativo que envia e-mail smtp por meio de um servidor Exchange local em um cliente. Todo o e-mail envia ok (ele chega ao destinatário), mas alguns e-mails são enviados várias vezes porque meu aplicativo nunca recebe o código de resposta 221 para dizer que ele funcionou bem e então tenta novamente. Poderíamos repetir as tentativas, mas geralmente isso é necessário para problemas genuínos.

Isso ocorre mais comumente em determinados endereços de e-mail de desingimento e acontecerá repetidamente nesse e-mail assim que ocorrer.

Eu capturei o fluxo TCP de um que funciona e outro que não funciona. Obviamente, os nomes mudaram para proteger os culpados.

Did work:
220 SBS4S1.example.local Microsoft ESMTP MAIL Service ready at Thu, 16 Apr 2015 11:51:16 +0100
EHLO example-PC
250-SBS4S1.example.local Hello [192.168.111.15]
250-SIZE 10485760
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-AUTH
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250-XEXCH50
250 XSHADOW
RSET
250 2.0.0 Resetting
MAIL FROM:<[email protected]>
250 2.1.0 Sender OK
RCPT TO:<[email protected]>
250 2.1.5 Recipient OK
DATA
354 Start mail input; end with <CRLF>.<CRLF>
--DATA Here, identical other than MIME/Content IDs in both emails--
.
250 2.6.0 <[email protected]> [InternalId=26602] Queued mail for delivery
QUIT
221 2.0.0 Service closing transmission channel

.

    Did NOT work:
    220 SBS4S1.example.local Microsoft ESMTP MAIL Service ready at Thu, 16 Apr 2015 11:43:39 +0100
    EHLO example-PC
    250-SBS4S1.example.local Hello [192.168.111.15]
    250-SIZE 10485760
    250-PIPELINING
    250-DSN
    250-ENHANCEDSTATUSCODES
    250-STARTTLS
    250-AUTH
    250-8BITMIME
    250-BINARYMIME
    250-CHUNKING
    250-XEXCH50
    250 XSHADOW
    RSET
    250 2.0.0 Resetting
    MAIL FROM:<[email protected]>
    250 2.1.0 Sender OK
    RCPT TO:<[email protected]>
    250 2.1.5 Recipient OK
    DATA
    354 Start mail input; end with <CRLF>.<CRLF>
    --DATA Here, identical other than MIME/Content IDs in both emails--
    .
    QUIT
    250 2.6.0 <[email protected]> [InternalId=26573] Queued mail for delivery


--This then times out but never gets the 221--

A única diferença que eu posso ver além do 221 que falta é que o 250 e o QUIT são o contrário na mensagem que "falha". Esta é uma peculiaridade conhecida do Exchange que temos que resolver, algo que poderíamos consertar ou lidar em nosso aplicativo ou algo que poderíamos pedir para ser alterado no servidor de email? Nós não queremos quebrar nada para a situação normal e comum.

Atualização: achei que não conseguiríamos acessar os registros do Exchange (os administradores nem sabiam onde estavam), mas eu tenho! Então a linha relevante é:

Tarpit para '0.00: 00: 32.619' devido a 'DelayedAck', Expirado; Tempo limite

Parece que pode ser devido a:

link

Preciso testá-lo primeiro.

    

Answer 1

Parece que, às vezes, seu aplicativo envia o comando QUIT antes de receber a resposta para o "ponto final" da mensagem (250 para OK).
Parece que o MTA (MS Exchange) ignora os comandos recebidos antes de enviar a resposta.

Correções sugeridas:
1) Aumentar o tempo limite para aguardar a resposta, não envie QUIT antes de recebê-lo (mesmo quando a extensão PIPELINING for anunciada). 2) Não reenvie se você receber 250 resposta para "o ponto final". Nesse caso, o MTA (MS Exchange) assume a responsabilidade de entregar a mensagem.

    

Answer 2

O motivo do problema foi a configuração "DelayedAck" no transporte do Exchange. O servidor de recebimento no "outro lado" do relé estava demorando muito para responder (mais de 30 segundos) e, portanto, a conexão que estávamos fazendo expirou e a conversa SMTP nunca foi concluída. (url eu adicionei na pergunta).

O administrador do Exchange desativou o DelayedAck no transporte interno e o problema desapareceu.

Poderíamos / deveríamos ter alterado nosso aplicativo para contornar isso, mas temos um componente de 3ª parte que tornou isso complicado e, portanto, não podemos verificar se isso funcionaria.