Network Working Group C. Newman
Request for Comments: 3848 Sun Microsystems
Category: Standards Track July 2004
Network Working Group C. Newman
Request for Comments: 3848 Sun Microsystems
Category: Standards Track July 2004
ESMTP and LMTP Transmission Types Registration
ESMTP和LMTP传输类型注册
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This registers seven new mail transmission types (ESMTPA, ESMTPS, ESMTPSA, LMTP, LMTPA, LMTPS, LMTPSA) for use in the "with" clause of a Received header in an Internet message.
这注册了七种新的邮件传输类型（ESMTPA、ESMTPS、ESMTPSA、LMTP、LMTPA、LMTPS、LMTPSA），用于Internet消息中接收头的“with”子句。
As directed by SMTP [2], IANA maintains a registry [7] of "WITH protocol types" for use in the "with" clause of the Received header in an Internet message. This registry presently includes SMTP [6], and ESMTP [2]. This specification updates the registry as follows:
按照SMTP[2]的指示，IANA维护一个“WITH protocol types”注册表[7]，用于Internet邮件中接收头的“WITH”子句。该注册表目前包括SMTP[6]和ESMTP[2]。本规范更新注册表如下：
o The new keyword "ESMTPA" indicates the use of ESMTP when the SMTP AUTH [3] extension is also used and authentication is successfully achieved.
o 新关键字“ESMTPA”表示在同时使用SMTP AUTH[3]扩展并且成功实现身份验证时使用ESMTP。
o The new keyword "ESMTPS" indicates the use of ESMTP when STARTTLS [1] is also successfully negotiated to provide a strong transport encryption layer.
o 新的关键字“ESMTPS”表示在STARTTLS[1]也成功协商以提供强传输加密层时使用ESMTP。
o The new keyword "ESMTPSA" indicates the use of ESMTP when both STARTTLS and SMTP AUTH are successfully negotiated (the combination of ESMTPS and ESMTPA).
o 新关键字“ESMTPSA”表示在成功协商STARTTLS和SMTP验证（ESMTPS和ESMTPA的组合）时使用ESMTP。
o The new keyword "LMTP" indicates the use of LMTP [4].
o 新关键字“LMTP”表示使用LMTP[4]。
o The new keyword "LMTPA" indicates the use of LMTP when the SMTP AUTH extension is also used and authentication is successfully achieved.
o 新关键字“LMTPA”表示在同时使用SMTP身份验证扩展并且成功实现身份验证时使用LMTP。
o The new keyword "LMTPS" indicates the use of LMTP when STARTTLS is also successfully negotiated to provide a strong transport encryption layer.
o 新的关键字“LMTPS”表示在成功协商STARTTLS以提供强传输加密层时使用LMTP。
o The new keyword "LMTPSA" indicates the use of LMTP when both STARTTLS and SMTP AUTH are successfully negotiated (the combination of LSMTPS and LSMTPA).
o 新关键字“LMTPSA”表示在成功协商STARTTLS和SMTP身份验证（LSMTPS和LSMTPA的组合）时使用LMTP。
o The references for the ESMTP and SMTP entries in the registry should be updated to the latest specification [2] since both RFC 821 and RFC 1869 [5] are obsoleted by RFC 2821.
o 注册表中ESMTP和SMTP项的引用应更新为最新规范[2]，因为RFC 821和RFC 1869[5]都已被RFC 2821淘汰。
The ESMTPA, ESMTPS and ESMTPSA keywords have been implemented in deployed email server software for several years and no problems have been reported with their use.
ESMTPA、ESMTPS和ESMTPSA关键字已在部署的电子邮件服务器软件中实施了几年，并且在使用过程中未报告任何问题。
Use of these additional keywords provides trace information to indicate when various high-level security framing protocols are used for hop-to-hop transport of email without exposing details of the specifics of the security mechanism. This trace information provides an informal way to track the deployment of these mechanisms on the Internet and can assist after-the-fact diagnosis of email abuse.
使用这些附加关键字可提供跟踪信息，以指示何时在不公开安全机制细节的情况下，将各种高级安全框架协议用于电子邮件的逐跳传输。此跟踪信息提供了一种非正式的方式来跟踪这些机制在Internet上的部署，并可帮助事后诊断电子邮件滥用。
These keywords are not normally protected in transport which means they can be modified by an active attacker. They also do not indicate the specifics of the mechanism used, and therefore do not provide any real-world security assurance. They should not be used for mail filtering or relaying decisions except in very controlled environments. As they are both cryptic and hidden in trace headers used primarily to diagnose email problems, it is not expected they will mislead end users with a false sense of security. Information with a higher degree of reliability can be obtained by correlating the Received headers with the logs of the various Mail Transfer Agents through which the message passed.
这些关键字在传输中通常不受保护，这意味着活动攻击者可以修改它们。它们也没有说明所用机制的具体情况，因此没有提供任何实际的安全保证。它们不应用于邮件过滤或转发决策，除非在非常受控的环境中。由于它们既神秘又隐藏在主要用于诊断电子邮件问题的跟踪头中，因此预计它们不会以错误的安全感误导最终用户。通过将接收到的头与消息通过的各种邮件传输代理的日志相关联，可以获得可靠性更高的信息。
The trace information provided by these keywords and other parts of the Received header provide a significant benefit when doing after-the-fact diagnosis of email abuse or problems. Unfortunately, some people in a misguided attempt to hide information about their internal servers will strip Received headers of useful information
在对电子邮件滥用或问题进行事后诊断时，这些关键字和收到的邮件头的其他部分提供的跟踪信息提供了显著的好处。不幸的是，有些人在错误地试图隐藏有关其内部服务器的信息时，会剥夺接收到的有用信息的标题
and reduce their ability to correct security abuses after they happen. The result of such misguided efforts is usually a reduction of the overall security of the systems.
并降低他们在安全问题发生后纠正安全问题的能力。这种误入歧途的努力通常会降低系统的整体安全性。
[1] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[1] Hoffman，P.，“传输层安全SMTP的SMTP服务扩展”，RFC3207，2002年2月。
[2] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[2] 《简单邮件传输协议》，RFC 28212001年4月。
[3] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[3] 迈尔斯，J.，“用于身份验证的SMTP服务扩展”，RFC2554，1999年3月。
[4] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.
[4] Myers，J.，“本地邮件传输协议”，RFC 2033，1996年10月。
[5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
[5] Klensin，J.，Freed，N.，Rose，M.，Stefferud，E.，和D.Crocker，“SMTP服务扩展”，STD 10，RFC 18691995年11月。
[6] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[6] Postel，J.，“简单邮件传输协议”，STD 10，RFC 821，1982年8月。
[7] <http://www.iana.org/assignments/mail-parameters>
[7] <http://www.iana.org/assignments/mail-parameters>
Author's Address
作者地址
Chris Newman Sun Microsystems 1050 Lakes Drive West Covina, CA 91790 US
Chris Newman Sun Microsystems 1050 Lakes Drive West Covina，加利福尼亚州，美国91790
EMail: chris.newman@sun.com
EMail: chris.newman@sun.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。