Qual lado da conversa SMTP está correto?

Question

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

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

O fluxo de trabalho SMTP é assim:

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 email upstream envia imediatamente outro comando MAIL FROM: e isso é rejeitado (porque o dispositivo de segurança pensa que faz parte da mesma transação.

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

Espero que isso faça sentido. Ficarei feliz em esclarecer. Estou tentando determinar qual entidade final está certa para poder envolver o recurso de suporte apropriado.

    

Answer 1

O aparelho está quebrado.

O RFC 5321 é claro quando, após o comando DATA, todo o estado é reinicializado, independentemente de a mensagem ser aceita ou rejeitada.

De seção 4.1.1.4 :

Receipt of the end of mail data indication requires the server to process the stored mail transaction information. This processing consumes the information in the reverse-path buffer, the forward-path buffer, and the mail data buffer, and on the completion of this command these buffers are cleared. If the processing is successful, the receiver MUST send an OK reply. If the processing fails, the receiver MUST send a failure reply.

(ênfase minha)

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

Com base na saída, eu acho que o appliance tem um milter quebrado que está estragando o processamento de e-mail. O Sendmail sozinho normalmente obtém o cumprimento da RFC.