我有一些代码可以验证电子邮件地址。它通过尝试通过 SMTP 发送邮件，然后退出而不发送任何内容来工作。它在大多数情况下都有效，但在某些特殊情况下却不起作用。我遇到过这种情况，我想知道是否有人知道邮件服务器可能对我的请求不满意的原因是什么？
这是端口 25 到 smtp.hp.com 的 TCP 会话（我在这里替换了真实的电子邮件地址）
220-g1t6210.austin.hp.com ESMTP Postfix
HELO ednasmtp.beweb.co.nz
250 g1t6210.austin.hp.com
MAIL FROM: <[email protected]>
250 2.1.0 Ok
RCPT TO: <[email protected]>
550 5.5.1 Protocol error
QUIT
550 5.5.1 Protocol error
我的问题是，为什么 HP 的 Postfix 服务器显示“协议错误”？我的邮件投递是否无效？
答案1
smtp.hp.com解析为 4 个不同的 IP 地址。每个 IP 地址都响应 SMTP，但它们的配置方式不同。如果不知道您连接到的是这 4 个地址中的哪一个，就很难确切地说出失败的原因。但我可以逐步检查您的会话并解释客户端在此过程中犯的多个错误。
220-g1t6210.austin.hp.com ESMTP Postfix
这是服务器的部分状态消息，如 所示-。状态的最后一行在该位置将有一个。4 个 SMTP 服务器中的 3 个以这种方式响应 2 行状态消息，两行之间有延迟。其中一个响应 1 行状态消息，这排除了该服务器已处理您的会话的可能性。客户端需要继续阅读状态消息，直到它看到所有内容。
HELO ednasmtp.beweb.co.nz
此时，客户端在收到完整状态之前发送命令，从而违反了协议。
250 g1t6210.austin.hp.com
在这里，服务器违反了协议，发送了不同的状态代码，符合标准的客户端会将其解释为220-上述状态行的延续。
MAIL FROM: <[email protected]>
这里，客户端违反了协议，在:和之间添加了多余的空格<。该位置绝对不允许出现空格，但有些邮件服务器会忽略该空格并允许交易继续进行。
250 2.1.0 Ok
RCPT TO: <[email protected]>
这里客户端以与命令中相同的方式再次违反了协议MAIL。
550 5.5.1 Protocol error
确实存在协议错误。很难判断它抱怨的是上述哪种协议错误。命令RCPT本身是错误的，但它没有遇到之前在事务中没有见过的错误。
QUIT
550 5.5.1 Protocol error
此时很难猜测哪一方关闭了连接。鉴于双方都违反了协议，这可能不再重要。我们甚至不能确定哪些状态代码适用于哪些命令。
答案2
您的主机未通过电子邮件服务器应有的多项验证：
- 对于上面显示的名称，rDNS验证失败。
- 它没有 SPF 记录（简单的“v=spf1 a -all”策略就足够了）。
- 发送域没有 DKIM 或 DMARC 记录。
如果您正在进行地址验证，则可能会触发多种垃圾邮件避免技术。虽然过去地址验证通常是允许的，但垃圾邮件发送者导致验证受到限制。修复上述问题可能会有所帮助，但我不会依赖它。
目前，唯一得到广泛支持的地址验证方式是发送一封带有验证链接的电子邮件，供用户确认他们的地址。
您可能想要查看有关电子邮件和 Postfix 的规范帖子。
答案3
简化回答：我们需要等待几秒钟，会显示更多行，然后我们就可以helo ..像往常一样了。
$ ncat 1.2.3.4 25
helo localhost
[..wait for a few seconds..and it works]