7. Security Considerations (安全考虑)
7.1. Mail Security and Spoofing (邮件安全和欺骗)
SMTP邮件本质上是不安全的，因为即使是相当随意的用户也可以直接与接收和中继SMTP服务器协商，并创建会欺骗天真收件人相信它们来自其他地方的消息。构造这样的消息以使专家无法检测到"欺骗"行为稍微困难一些，但不足以阻止有决心和知识的人。因此，随着对互联网邮件的了解增加，对SMTP邮件本质上无法在传输层进行身份验证或提供完整性检查的了解也在增加。真正的邮件安全仅在于涉及消息正文的端到端方法，例如使用数字签名的方法 (参见RFC 1847 [43]，例如RFC 4880 [44] 中的Pretty Good Privacy (PGP) 或RFC 3851 [45] 中的Secure/Multipurpose Internet Mail Extensions (S/MIME))。
在传输层提供身份验证的各种协议扩展和配置选项 (例如，从SMTP客户端到SMTP服务器) 在某种程度上改善了上述传统情况。然而，通常它们只是将一个服务器验证到另一个服务器，而不是中继和服务器链，更不用说验证用户或用户机器了。因此，除非它们伴随着在精心设计的信任环境中仔细移交责任，否则它们仍然本质上弱于使用数字签名消息而不是依赖于传输系统完整性的端到端机制。
试图使用户更难将信封返回路径和头部"From"字段设置为指向除自己之外的有效地址的努力在很大程度上是误导性的: 它们会阻碍合法应用程序，在这些应用程序中，一个用户代表另一个用户发送邮件，其中错误 (或正常) 回复应定向到特殊地址，或其中单个消息发送到不同主机上的多个收件人。(为用户提供基于每条消息更改这些头字段的便捷方法的系统应尝试为用户建立主要和永久的邮箱地址，以便可以合理地生成消息数据内的Sender头字段。)
本规范不进一步讨论与SMTP相关的身份验证问题，除了倡导不应禁用有用的功能，希望提供一些针对试图伪造邮件的用户的小保护裕度。
7.2. "Blind" Copies ("密送"副本)
由于多种原因，未出现在消息头部分中的地址可能出现在SMTP服务器的RCPT命令中。两个最常见的涉及使用邮件地址作为"列表扩展器" (解析为多个地址的单个地址) 和"密送副本"的出现。特别是当存在多个RCPT命令时，并且为了避免破坏这些机制的某些目的，SMTP客户端和服务器不应该 (SHOULD NOT) 将完整的RCPT命令参数集复制到头部分，无论是作为跟踪头字段的一部分还是作为信息性或专用扩展头字段。由于此规则在实践中经常被违反，并且无法强制执行，因此了解"bcc"使用的发送SMTP系统可以 (MAY) 发现将每个密送副本作为仅包含单个RCPT命令的单独消息事务发送会有所帮助。
SMTP事务 ("信封") 中的"反向" (来自MAIL, SAML等命令) 或"正向" (RCPT) 地址与头部分中的地址之间没有固有关系。接收系统不应该 (SHOULD NOT) 尝试推断此类关系并使用它们来更改消息的头部分以进行传递。流行的"Apparently-to"头字段违反了此原则，也是意外信息泄露的常见来源，不应该 (SHOULD NOT) 使用。
7.3. VRFY, EXPN, and Security (VRFY, EXPN和安全性)
如第3.5节所述，出于安全原因 (见下文)，各个站点可能希望禁用VRFY或EXPN中的一个或两个。作为上述的推论，允许这样做的实现禁止 (MUST NOT) 看起来已验证实际上未验证的地址。如果站点出于安全原因禁用这些命令，SMTP服务器必须 (MUST) 返回252响应，而不是可能与成功或不成功验证混淆的代码。
在仅检查语法后使用VRFY命令中列出的地址返回250应答代码违反了此规则。当然，无论地址是否有效，总是返回550的"支持"VRFY的实现同样不符合要求。
在公共互联网上，邮件列表的内容已成为所谓"垃圾邮件发送者"的流行地址信息源。随着列表管理员安装了针对列表本身不当使用的保护，使用EXPN来"收集"地址的情况有所增加。然而，VRFY和EXPN对于经过身份验证的用户和管理域内仍然有用。例如，VRFY和EXPN对于执行电子邮件如何路由的内部审计以检查并确保没有人自动将敏感邮件转发到组织外部很有用。实施SMTP身份验证的站点可以选择仅向经过身份验证的请求者提供VRFY和EXPN。实现应该 (SHOULD) 仍然提供对EXPN的支持，但站点应该 (SHOULD) 仔细评估权衡。
禁用VRFY是否提供任何真正的边际安全取决于一系列其他条件。在许多情况下，RCPT命令可用于获取有关地址有效性的相同信息。另一方面，特别是在RCPT命令的地址有效性确定被推迟到接收DATA命令之后的情况下，RCPT可能根本不返回任何信息，而VRFY应该在生成响应代码之前认真尝试确定有效性 (参见上面的讨论)。
7.4. Mail Rerouting Based on the 251 and 551 Response Codes (基于251和551响应代码的邮件重新路由)
在客户端使用来自RCPT命令的251或551应答代码自动更新其未来行为 (例如，更新用户的地址簿) 之前，它应该确定服务器的真实性。如果不这样做，它可能会受到中间人攻击。
7.5. Information Disclosure in Announcements (公告中的信息泄露)
关于在问候响应或响应HELP命令时公布服务器类型和版本 (有时甚至服务器域名) 的调试优势与暴露可能在潜在敌对攻击中有用的信息的劣势之间的权衡，一直存在持续的辩论。调试信息的实用性毋庸置疑。那些主张提供它的人指出，实际保护SMTP服务器远比试图通过隐藏服务器的精确身份来隐藏已知漏洞以提供更多保护要好得多。鼓励站点在考虑该问题的情况下评估权衡; 实现应该 (SHOULD) 至少提供以某种方式向其他网络主机提供类型和版本信息。
7.6. Information Disclosure in Trace Fields (跟踪字段中的信息泄露)
在某些情况下，例如当邮件源自其主机不直接在公共互联网上的LAN时，根据本规范生成的跟踪 ("Received") 头字段可能会泄露通常不可用的主机名和类似信息。这通常不会构成问题，但对名称泄露有特殊关注的站点应该意识到这一点。此外，当涉及多个收件人时，应谨慎提供可选的FOR子句或根本不提供，以免无意中向其他人泄露"密送副本"收件人的身份。
7.7. Information Disclosure in Message Forwarding (消息转发中的信息泄露)
如第3.4节所述，使用251或551应答代码来标识与邮箱关联的替换地址可能会无意中泄露敏感信息。关注这些问题的站点应确保它们适当地选择和配置服务器。
7.8. Resistance to Attacks (抵抗攻击)
近年来，针对SMTP服务器的攻击有所增加，无论是结合尝试发现用于发送未经请求的消息的地址，还是仅仅使服务器对其他人不可访问 (即，作为应用层拒绝服务攻击)。虽然这样做的方法超出了本标准的范围，但理性的操作行为要求允许服务器检测此类攻击并采取行动进行自我防御。例如，如果服务器确定正在发送大量RCPT TO命令，其中大多数或全部具有无效地址，作为此类攻击的一部分，则服务器在生成适当数量的5yz (通常为550) 应答后关闭连接是合理的。
7.9. Scope of Operation of SMTP Servers (SMTP服务器的操作范围)
SMTP服务器可以出于对提供服务器的站点有意义的任何操作或技术原因拒绝接受邮件，这是一个公认的原则。然而，站点和安装之间的合作使互联网成为可能。如果站点过度利用拒绝流量的权利，则电子邮件可用性的普遍性 (互联网的优势之一) 将受到威胁; 如果站点决定对其将接受和处理的流量进行选择，则应格外小心并保持平衡。
近年来，通过任意站点使用中继功能已被用作隐藏邮件实际来源的敌对努力的一部分。一些站点已决定将中继功能的使用限制在已知或可识别的来源，实现应该 (SHOULD) 提供执行此类过滤的能力。当由于这些或其他策略原因拒绝邮件时，应该 (SHOULD) 在响应EHLO (或HELO)、MAIL或RCPT时适当地使用550代码。