Which side of this SMTP conversation is correct?

Mike B asked:

I have an odd scenario with two mail servers communicating with one another and need help determining which one is behaving correctly.

It’s a little complicated to explain, so I think a SMTP conversation is probably the easiest way to describe it. In this scenario, mailserver1.foo.com is trying to pass a message to securityappliance.foo.com.

SMTP workflow looks like this:

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

So, we have two messages that were being delivered in single-file as part of the same SMTP connection. The first message results in a 550 error (we know why that happened). The upstream mail server then immediately submits another MAIL FROM: command and that gets rejected (because the security appliance thinks it’s part of the same transaction.

Does the upstream server need to issue a RSET command before sending the completely separate message? Or should the receiving security appliance understand that the email is completely different and not consider it a part of message #1?

I hope this makes sense. I’ll be happy to clarify. I’m trying to determine which end-entity is in the right so I can engage the appropriate support resource.

My answer:


The appliance is broken.

RFC 5321 is crystal clear that after the DATA command all the state gets reset, regardless of whether the mail message was accepted or rejected.

From section 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.

(Emphasis mine)

This is not a new requirement. RFC 2821 said the same thing.


Based on the output, I would guess the appliance has a broken milter which is screwing up mail processing. Sendmail alone usually gets RFC compliance right.


View the full question and any other answers on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.