Ask Your Question
0

MacOS Server SMTP Negotiation Issues

asked 2019-10-14 13:18:57 +0000

Joe Smith gravatar image

I was wondering if someone could help me with an issue I'm having with negotiating a SMTP connection. I'm attempting to establish a SMTP connection from my Lorex NVR to my macOS Server (v 5.6). I'll attempt to attach a screen capture. In it, you can see that everything look nominal until you get to packet #13. In packet #12, the Lorex is asking the server for a 'AUTH LOGIN' authentication. Instead of responding with the base64 Username prompt as it should, it responds with it's hostname (packet #13). This causes the Lorex to immediately QUIT the connection (packet #14). But, then, after the QUIT request, the server provides the base64 Username prompt, only it's too late. Have anyone ever seen this? It doesn't seem to follow the SMTP protocol - everything I've researched says that the proper response should always be the Username prompt. Any help would be much appreciated.

Thanks!

Joe

P.S. Sorry, I just saw that I don't have enough 'points' to actually upload the screen capture. It's too bad because I think it's really needed for context.

edit retag flag offensive close merge delete

Comments

What would be much more useful is the actual capture file, then folks can use our favourite tool to examine the data.

You can upload the capture file to a public file share, e.g. Google Drive, DropBox etc. and then post a link to the file back here.

grahamb gravatar imagegrahamb ( 2019-10-14 13:21:17 +0000 )edit

Gotcha!

Here's the link: SMTP Negotiation Failure

Joe

Joe Smith gravatar imageJoe Smith ( 2019-10-14 13:34:15 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2019-10-14 14:41:41 +0000

grahamb gravatar image

The SMTP communication looks a little odd. Using "Follow -> TCP Stream" gives the following SMTP communication:

220-server.thesmithcloud.com ESMTP Postfix
EHLO localhost
220 server.thesmithcloud.com ESMTP Postfix
HELO localhost
250-server.thesmithcloud.com
250-PIPELINING
250-SIZE
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5 GSSAPI
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250-BINARYMIME
250 CHUNKING
AUTH LOGIN
250 server.thesmithcloud.com
QUIT
334 VXNlcm5hbWU6
334 UGFzc3dvcmQ6

It's odd because the client, after sending the EHLO then sends a superfluous HELO.

The server continues it's response to the EHLO with the set of 250- responses, ending with the 250 CHUNKING (no dash after the 250 signals the end of the set).

The client then sends the AUTH LOGIN request and instead of the expected 334 VXNlcm5hbWU6 (Base64 encoding of "Username") receives the 250 response from the HELO request and the client then terminates the conversation with QUIT.

The server then does send the responses to the AUTH LOGIN but the client has given up and responds with a TCP RST.

I have no idea why the client is behaving this way.

FYI, a reasonable primer on the SMTP protocol can be found here.

edit flag offensive delete link more

Comments

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

Joe Smith gravatar imageJoe Smith ( 2019-10-14 15:17:45 +0000 )edit

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.

grahamb gravatar imagegrahamb ( 2019-10-14 15:34:33 +0000 )edit

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?

Joe Smith gravatar imageJoe Smith ( 2019-10-14 16:27:23 +0000 )edit

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".

grahamb gravatar imagegrahamb ( 2019-10-14 16:48:58 +0000 )edit

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.

grahamb gravatar imagegrahamb ( 2019-10-14 17:14:31 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2019-10-14 13:18:57 +0000

Seen: 23 times

Last updated: Oct 14