Chilkat发信返回354 Enter message响应原因排查问询

我尝试使用Chilkat的AppendMail方法将已发送邮件存储至Sent（已发送）邮箱，调用代码如下：

$oIMAP.AppendMail($sMailbox_name, $oEmail)

多数场景下该功能运行正常，但在部分终端客户端配置环境下，获取到如下运行日志：

--sendCmdToSmtp
            --sendRcptTo
            sendCmdToSmtp:
              SmtpCmdSent: DATA<CRLF>
            --sendCmdToSmtp
            readSmtpResponse:
              SmtpCmdResp: 250 OK
            --readSmtpResponse
            readRcptTo:
              readSmtpResponse:
                SmtpCmdResp: 250 Accepted
              --readSmtpResponse
              recipient: *****@destination.pl
            --readRcptTo
            readRcptTo:
              readSmtpResponse:
                SmtpCmdResp: 250 Accepted
              --readSmtpResponse
              recipient: *****@sender.pl
            --readRcptTo
            readSmtpResponse:
              SmtpCmdResp: 354 Enter message, ending with "." on a line by itself
            --readSmtpResponse
          --sendWithPipelining
          sendCmdToSmtp:
            SmtpCmdSent: <CRLF>.<CRLF>
          --sendCmdToSmtp
          readSmtpResponse:
            SmtpCmdResp: 250 OK id=1nypCX-0005r9-EO
          --readSmtpResponse
        --sendSmtpEmail
      --sendMimeInner
    --sendEmailInner
    Success.
  --SendEmail
--ChilkatLog

• 为何会出现354 Enter message, ending with "." on a line by itself响应？
• 该问题是Chilkat组件本身存在缺陷，还是需要调整自身代码逻辑？

首先明确：354 Enter message, ending with "." on a line by itself 不是报错，是SMTP协议（RFC 5321）规定的标准中间响应：客户端发送DATA命令后，服务器返回该状态码，代表准备就绪，客户端可以开始传输邮件正文，正文传输完成后必须单独发送一行.作为内容结束标记。

从你提供的日志来看，整个SMTP交互流程完全合规，没有异常：

• 客户端发送DATA命令后，服务器先返回了所有收件人的250确认响应，再返回354提示可以发送正文
• 客户端传输完正文后，按协议要求发送了结束标记<CRLF>.<CRLF>
• 服务器最终返回250 OK id=1nypCX-0005r9-EO确认邮件接收成功，日志末尾也明确标注了Success.

你查阅资料中提到的程序bug，指的是开发者错误将354响应当成服务端报错，收到该响应后直接中断流程、不继续发送正文和结束标记的逻辑错误，和你当前的场景完全无关。

额外需要注意的点：

• 你贴出的日志全部是SMTP发信流程的输出，和你调用的IMAP协议AppendMail存已发送邮件的操作没有任何关联，不要把SMTP阶段的正常响应当成Append操作失败的原因
• 如果部分环境下已发送邮件存储失败，需要单独抓取IMAP Append操作对应的日志排查，常见故障点包括：账号对目标邮箱无写入权限、邮箱名特殊字符编码不匹配、传入的邮件MIME格式符合对应IMAP服务器的校验规则
• 现有日志可以证明Chilkat的SMTP交互逻辑完全符合协议规范，不存在RFC兼容层面的缺陷，不需要调整发信相关的代码逻辑。

内容的提问来源于stack exchange，提问作者Michał Lipok