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 [22.214.171.124], 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.
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 126.96.36.199:
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.
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.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.