1

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:<footestuser@foo.com>
250 2.1.0 <footestuser@foo.com>... Sender ok
RCPT TO:<recipient@foo.com>
250 2.1.5 <recipient@foo.com>... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
X-Example-Header-Blah: Blah
From: <footestuser@foo.com>
To: <recipient@foo.com>
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:<completelydifferentsender@completelydifferentmessage.com>
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.

Mike B
  • 11,871
  • 42
  • 107
  • 168

1 Answers1

4

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.

Community
  • 1
Michael Hampton
  • 244,070
  • 43
  • 506
  • 972
  • Thanks. That makes sense. I have to ask though -- under what circumstances _should_ a remote sending system use `RSET`? I see in RFC5321, it says **This command specifies that the current mail transaction will be aborted. Any stored sender, recipients, and mail data MUST be discarded, and all buffers and state tables cleared.** but it's still unclear to me on when it should be used. – Mike B Mar 06 '18 at 23:19
  • @MikeB Automata might use RSET in the scenario where a server has two or more messages to deliver to a host, but that host rejects one at the MAIL or RCPT stage. It would then send RSET and try the second message. It's not necessary after DATA because the server should have already reset all the state. – Michael Hampton Mar 06 '18 at 23:21