后面的名字 EHLO 是客户端提供的SMTP身份，不能证明客户端拥有域或有权发送可见消息。 EHLO还要求服务器通告扩展。一项有用的调查将问候语名称、连接 IP、 信封发件人 并且消息在发件人域中可见。混淆它们可能会产生误报和无效的修复。
解读问候语
RFC 5321描述了客户端问候语以及用于识别客户端的域或地址文字形式。 EHLO请求扩展SMTP行为； HELO是基本的问候语。服务器的EHLO响应可以通告支持的扩展，但支持和权限是不同的。例如，宣传功能并不意味着未经身份验证的客户端可以将邮件转发给每个收件人。
客户端应提供适当的完全限定域名（如果可用），以及在协议定义的情况下使用的地址文字。通用工作站标签或不相关的域可能会导致互操作性或策略问题。检查实际服务器的要求，而不是假设每个部署都强制执行相同的检查。 RFC 5321第4.1.1.1和 4.1.4 节.
区分一致性检查和身份验证
操作员可以将问候语与转发或 反向DNS，但这样的比较是一个单独的信号，必须遵循协议和当地政策的限制。 RFC 5321规定服务器可以验证EHLO名称是否对应于客户端的 IP，但不能仅仅因为验证失败而拒绝消息。不要将常见的反滥用启发法转变为通用SMTP要求。
SPF 可以评估HELO身份，如下所述 RFC 7208。该结果不能与非空 MAIL FROM 身份的评估互换。对于空反向路径， SPF过程使用基于HELO构建的身份。保留已检查的身份，而不是显示一个未标记的SPF结果。
阅读假设的问候语交流
假设服务器发送 220，客户端发送EHLO client.example ，服务器回复 250 个连续行，后面是最后 250 行广告其可用扩展。这说明了问候和功能发现，而不是DNS解析、客户端所有权或中继权限的证明。
现在假设 RCPT TO 随后返回中继拒绝响应。成功的问候并未授予该权限。在 RCPT 记录拒绝情况以及实际连接和帐户状态，而不是得出EHLO身份验证失败的结论。相反，对EHLO本身的拒绝需要它自己的完整解释。这些是发明的协议案例，而不是保留的实验室或商业提供商的测试。
解决精确拒绝问题
保留完整的问候阶段回复和任何以后的拒绝。 EHLO失败可能需要检查语法、实现兼容性或预期的服务端点。 RCPT 的失败可能会涉及中继权限或接收者的存在。 DATA 之后的故障可能涉及内容或消息策略。不要仅仅因为最终消息失败而将客户端主机重命名为可见的 From 域 DMARC.
成功后 STARTTLS，丢弃 TLS 之前的SMTP信息并按照RFC 3207第 4.2 节的建议发送新的EHLO ；能力列表可能会改变。如果提交需要身份验证，请遵循提供商支持的安全方法。使用无害的内容测试更正的配置并记录每个阶段的最终响应。有用的结论是哪个操作失败以及原因，而不是主机名看起来是否合理。
从回复中选择下一个检查
- EHLO语法或问候语拒绝：检查确切的端点、提供的名称和完整回复。
- TLS之后的 AUTH 失败：检查提供商支持的安全方法和当前权限，而不暴露机密。
- RCPT拒绝：使用完整响应区分接收者存在与中继授权。
- 数据后拒绝：检查消息策略解释和可信身份验证证据。
- DMARC投诉：将实际SPF / DKIM身份与 From 进行比较；单独重命名EHLO并不是通用的 结盟 维修。