To use an example response from google when sent "EHLO":
250-mx.google.com at your service, [66.501.941.15]
250-SIZE 35651584
250-8BITMIME
250-AUTH LOGIN PLAIN
250-ENHANCEDSTATUSCODES
250 PIPELINING
Hex:
32 35 30 2D 6D 78 2E 67 6F 6F 67 6C 65 2E 63 6F 6D 20 61 74 20 79 6F 75 72 20 73 65 72 76 69 63 65 2C 20 5B 39 32 2E 34 32 31 2E 35 36 35 2E 34 32 5D 0D 0A 32 35 30 2D 53 49 5A 45 20 33 35 36 35 31 35 38 34 0D 0A 32 35 30 2D 38 42 49 54 4D 49 4D 45 0D 0A 32 35 30 2D 41 55 54 48 20 4C 4F 47 49 4E 20 50 4C 41 49 4E 0D 0A 32 35 30 2D 45 4E 48 41 4E 43 45 44 53 54 41 54 55 53 43 4F 44 45 53 0D 0A 32 35 30 20 50 49 50 45 4C 49 4E 49 4E 47 0D 0A
Since the SMTP spec states that a line must end with a CR LF (0D 0A), we can parse on those two bytes to find lines, but how do we determine the end of the response?
Over satellite, responses can be broken into pieces with a significant delay between. This means a response could end after a CR LF and not be complete ie:
250-mx.google.com at your service, [66.501.941.15]
250-SIZE 35651584
250-8BITMIME
Any logic that looks for a trailing CR LF would then assume the response is complete. IN this case I am using CryptLib to perform the SLL tunnel, but I can create the port with my own code and pass it to the library if there is some way to get an "end of response".