MacOS Server SMTP Negotiation Issues

edit

grahamb,

Thanks for that most helpful insight! I didn't know what was a normal SMPT negotiation and at some point wondered about the HELO packet following the EHLO packet myself. It seems the fault is on the client side (Lorex NVR), whereas I was focusing my efforts on the Server. I have a call in to the manufacturer's Level 2 support this afternoon (Lorex) and will see where it leads me.

Thanks!

Joe

I've had another look at it, trying to figure out what caused the client behaviour, and if it might be the server.

The initial greeting from the server indicates a multi-line response (220-) which is a bit odd, the client sends EHLO and then receives the last line of the greeting (220). I think this triggers the client into believing that the EHLO has failed, even though it's not an error code, so sends the fallback HELO. According to RFC 5321 a 220 is not a valid response to an EHLO, but if the client had correctly received the multi-line greeting then this wouldn't have been an issue.

I'm uncertain if the multi-line greeting from the server is legal, but in the spirit of SMTP, the client should accept it.

So, if I'm reading you correctly, the multi-line (250) greeting is a delayed response to the initial EHLO and the "250 server.thesmithcloud.com" is a delayed response to the HELO? Are they out of sequence?

I don't think the responses are necessarily delayed, just that the client has jumped in very quickly after the first line of the server greeting.

The 250 multi-line response to the EHLO is transmitted fairly quickly, and it then appears that the server processes the HELO and sends the response, then processes the AUTH LOGIN and sends the response.

Note that the multi-line EHLO response is sent in a single TCP packet that is captured (and likely transmitted, I think the capture is from the server) very quickly after the last line of the greeting.

Remember it's over TCP which is bi-directional and depending on where and how the capture was taken may not show the true order of events.

I still think the issue is caused by the server sending a multi-line greeting that isn't handled correctly by the client causing the two to become "out-of-step".

Further investigation shows that a multi-line greeting is legal and has been used to detect SPAM zombies by checking for clients that "speak" before the server has sent the complete multi-line response, e.g. the "pregreet test" as part of the Postfix "postscreen" mail server protection.