使用扩展SMTP(ESMTP)解析响应结束

Mik*_*der 1 c++ ssl email-client smtp

要在发送"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
Run Code Online (Sandbox Code Playgroud)

十六进制:

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

由于SMTP规范声明一行必须以CR LF(0D 0A)结束,我们可以解析这两个字节以查找行,但是我们如何确定响应的结束?

通过卫星,响应可以分解成片段,两者之间有明显的延迟.这意味着响应可以在CR LF之后结束并且不完整,即:

250-mx.google.com at your service, [66.501.941.15]
250-SIZE 35651584
250-8BITMIME
Run Code Online (Sandbox Code Playgroud)

任何寻找尾随CR LF的逻辑都会假设响应完成.在这种情况下,我使用CryptLib来执行SLL隧道,但是如果有某种方法可以获得"响应结束",我可以使用自己的代码创建端口并将其传递给库.

R S*_*hko 8

响应在250和名称之间没有连字符的行上结束.

因此,如果该行的第4个字符是空格,那么它将是响应的最后一行.

RFC 2821的 4.2.1节:

多行回复的格式要求除了最后一行之外的每一行都以回复代码开头,后面紧跟一个连字符" - "(也称为减号),后跟文本.最后一行将以回复代码开头,紧接着是<SP>,可选择一些文本和<CRLF>.