Início / server / Perguntas / 900350
Accepted
Mike B
Asked: 2018-03-07 14:45:29 +0800 CST

Qual lado desta conversa SMTP está correto?

  • 772

Eu tenho um cenário estranho com dois servidores de e-mail se comunicando e preciso de ajuda para determinar qual deles está se comportando corretamente.

É um pouco complicado de explicar, então acho que uma conversa SMTP é provavelmente a maneira mais fácil de descrevê-la. Nesse cenário, mailserver1.foo.com está tentando passar uma mensagem para securityappliance.foo.com.

O fluxo de trabalho SMTP se parece com isso:

220 securityappliance.foo.com ESMTP Sendmail 8.14.4/8.14.4; Tue, 6 Mar 2018 14:21:53 -0800 
EHLO mailserver1.foo.com
250-securityappliance.foo.com Hello mailserver1.foo.com [1.1.1.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-DELIVERBY
250 HELP
MAIL FROM:<[email protected]>
250 2.1.0 <[email protected]>... Sender ok
RCPT TO:<[email protected]>
250 2.1.5 <[email protected]>... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
X-Example-Header-Blah: Blah
From: <[email protected]>
To: <[email protected]>
Subject: Message #1. I expect this to fail and am not concerned about that. 

Extra text/attachments.
.
550 5.3.0 Requested action on message failed; message rejected
MAIL FROM:<[email protected]>
557 5.3.0 Milter Implementation Error: Invalid argument passed

Portanto, temos duas mensagens que estavam sendo entregues em arquivo único como parte da mesma conexão SMTP. A primeira mensagem resulta em um erro 550 (sabemos por que isso aconteceu). O servidor de correio upstream envia imediatamente outro MAIL FROM:comando e é rejeitado (porque o dispositivo de segurança pensa que é parte da mesma transação.

O servidor upstream precisa emitir um RSETcomando antes de enviar a mensagem completamente separada? Ou o dispositivo de segurança receptor deve entender que o e-mail é completamente diferente e não considerá-lo parte da mensagem nº 1?

Espero que isto faça sentido. Terei prazer em esclarecer. Estou tentando determinar qual entidade final está correta para poder contratar o recurso de suporte apropriado.

smtp

1 respostas

  1. Best Answer

    O aparelho está quebrado.

    A RFC 5321 deixa claro que, após o comando DATA, todo o estado é redefinido, independentemente de a mensagem de correio ter sido aceita ou rejeitada.

    Da seção 4.1.1.4 :

    O recebimento da indicação de dados de fim de correio requer que o servidor processe as informações de transação de correio armazenadas. Esse processamento consome as informações no buffer de caminho reverso, no buffer de caminho de encaminhamento e no buffer de dados de correio e, na conclusão desse comando, esses buffers são limpos . Se o processamento for bem sucedido, o receptor DEVE enviar uma resposta OK. Se o processamento falhar, o receptor DEVE enviar uma resposta de falha.

    (ênfase minha)

    Este não é um requisito novo. RFC 2821 disse a mesma coisa .

    Com base na saída, eu acho que o aparelho tem um filtro quebrado que está atrapalhando o processamento de e-mail. O Sendmail sozinho geralmente acerta a conformidade com RFC.

    • 4

relate perguntas