Network Working Group E. Allman
Request for Comments: 3885 Sendmail, Inc.
Updates: 3461 T. Hansen
Category: Standards Track AT&T Laboratories
September 2004
Network Working Group E. Allman
Request for Comments: 3885 Sendmail, Inc.
Updates: 3461 T. Hansen
Category: Standards Track AT&T Laboratories
September 2004
SMTP Service Extension for Message Tracking
用于邮件跟踪的SMTP服务扩展
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 memo defines an extension to the SMTP service whereby a client may mark a message for future tracking.
此备忘录定义了SMTP服务的扩展，客户机可以通过此扩展标记邮件以供将来跟踪。
The model used for Message Tracking is described in [RFC-MTRK-MODEL].
[RFC-MTRK-model]中描述了用于消息跟踪的模型。
Doing a Message Tracking query is intended as a "last resort" mechanism. Normally, Delivery Status Notifications (DSNs) [RFC-DSN-SMTP] and Message Disposition Notifications (MDNs) [RFC-MDN] would provide the primary delivery status. Only if the message is not received, or there is no response from either of these mechanisms should a Message Tracking query be issued.
执行消息跟踪查询是一种“最后手段”机制。通常，传递状态通知（DSN）[RFC-DSN-SMTP]和邮件处置通知（MDN）[RFC-MDN]将提供主传递状态。只有在未收到消息，或者没有来自这些机制的响应时，才应发出消息跟踪查询。
The definition of the base64 token is imported from section 6.8 of [RFC-MIME]. Formally,
base64令牌的定义从[RFC-MIME]的第6.8节导入。正式地
base64 = %x2b / %x2f / %x30-39 / %x41-5a / %x61-7a
base64 = %x2b / %x2f / %x30-39 / %x41-5a / %x61-7a
The definition of the DIGIT token is imported from [RFC-MSGFMT]. Formally,
数字令牌的定义从[RFC-MSGFMT]导入。正式地
DIGIT = %x30-39
DIGIT = %x30-39
Syntax notation in this document conforms to [RFC-ABNF].
本文件中的语法符号符合[RFC-ABNF]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC-KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC-关键词]中的描述进行解释。
The Message Tracking SMTP service extension uses the SMTP service extension mechanism described in [RFC-ESMTP]. The following service extension is hereby defined:
邮件跟踪SMTP服务扩展使用[RFC-ESMTP]中描述的SMTP服务扩展机制。特此定义以下服务扩展：
(1) The name of the SMTP service extension is "Message Tracking".
(1) SMTP服务扩展名为“邮件跟踪”。
(2) The EHLO keyword value associated with this extension is "MTRK".
(2) 与此扩展关联的EHLO关键字值为“MTRK”。
(3) No parameters are allowed with this EHLO keyword value. Future documents may extend this specification by specifying parameters to this keyword value.
(3) 此EHLO关键字值不允许使用任何参数。将来的文档可能会通过为此关键字值指定参数来扩展此规范。
(4) One optional parameter using the keyword "MTRK" is added to the MAIL command. In addition, the ENVID parameter of the MAIL command (as defined in RFC 3461) MUST be supported, with extensions as described below. The ORCPT parameter of the RCPT command (as defined in RFC 3461) MUST also be supported. All semantics associated with ENVID and ORCPT described in RFC 3461 MUST be supported as part of this extension.
(4) 将使用关键字“MTRK”的一个可选参数添加到MAIL命令中。此外，还必须支持MAIL命令的ENVID参数（如RFC 3461中定义的），扩展名如下所述。还必须支持RCPT命令的ORCPT参数（如RFC 3461中定义的）。RFC 3461中描述的所有与ENVID和ORCPT相关的语义都必须作为此扩展的一部分得到支持。
(5) The maximum length of a MAIL command line is increased by 40 characters by the possible addition of the MTRK keyword and value. Note that the 507 character extension of RCPT commands for the ORCPT parameter and the 107 character extension of MAIL commands for the ENVID parameter as mandated by RFC 3461 [RFC-DSN-SMTP] must also be included.
(5) 通过可能添加MTRK关键字和值，邮件命令行的最大长度增加了40个字符。请注意，还必须包括RFC 3461[RFC-DSN-SMTP]规定的用于ORCPT参数的RCPT命令的507字符扩展名和用于ENVID参数的邮件命令的107字符扩展名。
(6) No SMTP verbs are defined by this extension.
(6) 此扩展未定义SMTP谓词。
The extended MAIL command is issued by an SMTP client when it wishes to inform an SMTP server that message tracking information should be retained for future querying. The extended MAIL command is identical to the MAIL command as defined in [RFC-SMTP], except that MTRK, ORCPT, and ENVID parameters appear after the address.
当SMTP客户端希望通知SMTP服务器应保留邮件跟踪信息以供将来查询时，会发出“扩展邮件”命令。扩展邮件命令与[RFC-SMTP]中定义的邮件命令相同，只是MTRK、ORCPT和ENVID参数出现在地址后面。
Any sender wishing to request the retention of data for further tracking of message must first tag that message as trackable by creating two values A and B:
任何希望请求保留数据以进一步跟踪邮件的发件人必须首先通过创建两个值A和B将该邮件标记为可跟踪：
A = some-large-random-number B = SHA1(A)
A=某个大随机数B=SHA1（A）
The large random number A is calculated on a host-dependent basis. See [RFC-RANDOM] for a discussion of choosing good random numbers. This random number MUST be at least 128 bits but MUST NOT be more than 1024 bits.
大随机数A是在主机相关的基础上计算的。有关选择好的随机数的讨论，请参见[RFC-RANDOM]。此随机数必须至少为128位，但不得超过1024位。
The 128-bit hash B of A is then computed using the SHA-1 algorithm as described in [NIST-SHA1].
然后使用[NIST-SHA1]中所述的SHA-1算法计算A的128位散列B。
The sender then base64 encodes value B and passes that value as the mtrk-certifier on the MAIL command:
然后，发送方base64对值B进行编码，并将该值作为邮件命令上的mtrk证书传递：
mtrk-parameter = "MTRK=" mtrk-certifier [ ":" mtrk-timeout ]
mtrk-certifier = base64 ; authenticator
mtrk-timeout = 1*9DIGIT ; seconds until timeout
mtrk-parameter = "MTRK=" mtrk-certifier [ ":" mtrk-timeout ]
mtrk-certifier = base64 ; authenticator
mtrk-timeout = 1*9DIGIT ; seconds until timeout
A is stored in the originator's tracking database to validate future tracking requests as described in [RFC-MTRK-MTQP]. B is stored in tracking databases of compliant receiver MTAs and used to authenticate future tracking requests.
A存储在发起人的跟踪数据库中，以验证[RFC-MTRK-MTQP]中所述的未来跟踪请求。B存储在符合要求的接收方MTA的跟踪数据库中，用于验证未来的跟踪请求。
The mtrk-timeout field indicates the number of seconds that the client requests that this tracking information be retained on intermediate servers, as measured from the initial receipt of the message at that server. Servers MAY ignore this value if it violates local policy. In particular, servers MAY silently enforce an upper limit to how long they will retain tracking data; this limit MUST be at least one day.
mtrk timeout字段表示客户端请求将此跟踪信息保留在中间服务器上的秒数，从该服务器首次收到消息开始计算。如果此值违反本地策略，服务器可能会忽略此值。特别是，服务器可以默默地强制执行跟踪数据保留时间的上限；此限制必须至少为一天。
If no mtrk-timeout field is specified then the server should use a local default. This default SHOULD be 8-10 days and MUST be at least one day. Notwithstanding this clause, the information MUST NOT be
如果未指定mtrk超时字段，则服务器应使用本地默认值。此默认值应为8-10天，并且必须至少为一天。尽管有本条款的规定，信息不得
expired while the message remains in the queue for this server: that is, an MTQP server MUST NOT deny knowledge of a message while that same message sits in the MTA queue.
当邮件仍在此服务器的队列中时已过期：也就是说，当同一邮件位于MTA队列中时，MTQP服务器不得拒绝知道该邮件。
If the message is relayed to another compliant SMTP server, the MTA acting as the client SHOULD pass an mtrk-timeout field equal to the remaining life of that message tracking information. Specifically, the tracking timeout is decremented by the number of seconds the message has lingered at this MTA and then passed to the next MTA. If the decremented tracking timeout is less than or equal to zero, the entire MTRK parameter MUST NOT be passed to the next MTA; essentially, the entire tracking path is considered to be lost at that point.
如果邮件中继到另一个兼容的SMTP服务器，则作为客户端的MTA应传递一个mtrk超时字段，该字段等于该邮件跟踪信息的剩余寿命。具体而言，跟踪超时将按邮件在此MTA上停留并传递到下一个MTA的秒数递减。如果递减的跟踪超时小于或等于零，则不得将整个MTRK参数传递给下一个MTA；基本上，整个跟踪路径在该点被视为丢失。
See [RFC-DELIVERYBY] section 4 for an explanation of why a timeout is used instead of an absolute time.
请参见[RFC-DELIVERYBY]第4节，了解为什么使用超时而不是绝对时间。
To function properly, Message Tracking requires that each message have a unique identifier that is never reused by any other message. For that purpose, if the MTRK parameter is given, an ENVID parameter MUST be included, and the syntax of ENVID from RFC 3461 is extended as follows:
为了正常运行，消息跟踪要求每条消息都有一个唯一的标识符，该标识符永远不会被任何其他消息重用。为此，如果给定了MTRK参数，则必须包含一个ENVID参数，并且RFC 3461中ENVID的语法扩展如下：
envid-parameter = "ENVID=" unique-envid
unique-envid = local-envid "@" fqhn
local-envid = xtext
fqhn = xtext
envid-parameter = "ENVID=" unique-envid
unique-envid = local-envid "@" fqhn
local-envid = xtext
fqhn = xtext
The unique-envid MUST be chosen in such a way that the same ENVID will never be used by any other message sent from this system or any other system. In most cases, this means setting fqhn to be the fully qualified host name of the system generating this ENVID, and local-envid to an identifier that is never re-used by that host.
选择唯一的envid时，必须确保从本系统或任何其他系统发送的任何其他消息都不会使用相同的envid。在大多数情况下，这意味着将fqhn设置为生成此ENVID的系统的完全限定主机名，将local ENVID设置为该主机从不重复使用的标识符。
In some cases, the total length of (local-envid + fqhn + 1) (for the `@' sign) may exceed the total acceptable length of ENVID (100). In this case, the fqhn SHOULD be replaced by the SHA1(fqhn) encoded into BASE64. After encoding, the 160 bit SHA-1 will be a 27 octet string, which limits local-envid to 72 octets. Implementors are encouraged to use an algorithm for the local-envid that is reasonably unique. For example, sequential integers have a high probability of intersecting with sequential integers generated by a different host, but a SHA-1 of the current time of day concatenated with the host's IP address and a random number are unlikely to intersect with the same algorithm generated by a different host.
在某些情况下，（本地envid+fqhn+1）（用于“@”符号）的总长度可能超过envid（100）的总可接受长度。在这种情况下，fqhn应替换为编码到BASE64中的SHA1（fqhn）。编码后，160位SHA-1将是27个八位字节的字符串，这将本地envid限制为72个八位字节。鼓励实现者为本地envid使用合理独特的算法。例如，序列整数很可能与不同主机生成的序列整数相交，但与主机IP地址和随机数连接的当前时间的SHA-1不太可能与不同主机生成的相同算法相交。
Any resubmissions of this message into the message transmission system MUST assign a new ENVID. In this context, "resubmission" includes forwarding or resending a message from a user agent, but does not include MTA-level aliasing or forwarding where the message does not leave and re-enter the message transmission system.
任何将此消息重新提交到消息传输系统的操作都必须分配一个新的ENVID。在此上下文中，“重新提交”包括转发或重新发送来自用户代理的邮件，但不包括MTA级别的别名或转发，因为邮件不会离开并重新进入邮件传输系统。
MTAs SHOULD forward unexpired tracking certifiers to compliant mailers as the mail is transferred during regular hop-to-hop transfers. If the "downstream" MTA is not MTRK-compliant, then the MTRK= parameter MUST be deleted. If the downstream MTA is DSN-compliant, then the ENVID and ORCPT parameters MUST NOT be deleted.
MTA应将未过期的跟踪证明转发给符合要求的邮件发送人，因为邮件是在常规的逐跳传输过程中传输的。如果“下游”MTA不符合MTRK，则必须删除MTRK=参数。如果下游MTA符合DSN，则不得删除ENVID和ORCPT参数。
If aliasing, forwarding, or other redirection of a recipient occurs, and the result of the redirection is exactly one recipient, then the MTA SHOULD treat this as an ordinary hop-to-hop transfer and forward the MTRK=, ENVID=, and ORCPT= values; these values MUST NOT be modified except for decrementing the mtrk-timeout field of the MTRK= value, which MUST be modified as described in section 4.1 above.
如果收件人出现别名、转发或其他重定向，且重定向的结果恰好是一个收件人，则MTA应将其视为普通的逐跳传输，并转发MTRK=、ENVID=、ORCPT=值；除减少mtrk=值的mtrk超时字段外，不得修改这些值，该字段必须按照上述第4.1节所述进行修改。
MTAs MUST NOT copy MTRK certifiers when a recipient is aliased, forwarded, or otherwise redirected and the redirection results in more than one recipient. However, an MTA MAY designate one of the multiple recipients as the "primary" recipient to which tracking requests shall be forwarded; other addresses MUST NOT receive tracking certifiers. MTAs MUST NOT forward MTRK certifiers when doing mailing list expansion.
当收件人使用别名、转发或以其他方式重定向并且重定向导致多个收件人时，MTA不得复制MTRK证明文件。但是，MTA可以指定多个收件人中的一个作为“主要”收件人，跟踪请求将转发给该收件人；其他地址不得接收跟踪证明。MTA在扩展邮件列表时不得转发MTRK证明文件。
An attacker could attempt to flood the database of a server by submitting large numbers of small, tracked messages. In this case, a site may elect to lower its maximum retention period retroactively.
攻击者可以通过提交大量小的、跟踪的消息，试图淹没服务器的数据库。在这种情况下，网站可以选择追溯降低其最大保留期。
The mtrk-authenticator value ("A") must be hard to predict and not reused.
mtrk验证器值（“A”）必须难以预测且不能重复使用。
The originating client must take reasonable precautions to protect the secret. For example, if the secret is stored in a message store (e.g., a "Sent" folder), the client must make sure the secret isn't accessible by attackers, particularly on a shared store.
发起客户必须采取合理的预防措施来保护该秘密。例如，如果机密存储在消息存储中（例如，“已发送”文件夹），则客户端必须确保攻击者无法访问该机密，尤其是在共享存储上。
Many site administrators believe that concealing names and topologies of internal systems and networks is an important security feature. MTAs need to balance such desires with the need to provide adequate tracking information.
许多站点管理员认为，隐藏内部系统和网络的名称和拓扑是一项重要的安全功能。MTA需要平衡这些需求与提供足够跟踪信息的需求。
In some cases site administrators may want to treat delivery to an alias as final delivery in order to separate roles from individuals. For example, sites implementing "postmaster" or "webmaster" as aliases may not wish to expose the identity of those individuals by permitting tracking through those aliases. In other cases, providing the tracking information for an alias is important, such as when the alias points to the user's preferred public address.
在某些情况下，站点管理员可能希望将对别名的传递视为最终传递，以便将角色与个人分开。例如，使用“邮政局长”或“网站管理员”作为别名的网站可能不希望通过允许通过这些别名进行跟踪而暴露这些个人的身份。在其他情况下，提供别名的跟踪信息很重要，例如当别名指向用户首选的公共地址时。
Therefore, implementors are encouraged to provide mechanisms by which site administrators can choose between these alternatives.
因此，鼓励实现者提供机制，站点管理员可以通过这些机制在这些备选方案中进行选择。
IANA has registered the SMTP extension defined in section 3.
IANA已注册第3节中定义的SMTP扩展名。
Several individuals have commented on and enhanced this document, including Philip Hazel, Alexey Melnikov, Lyndon Nerenberg, Chris Newman, and Gregory Neil Shapiro.
一些人对本文件进行了评论和改进，包括菲利普·黑泽尔、阿列克谢·梅尔尼科夫、林登·内伦伯格、克里斯·纽曼和格雷戈里·尼尔·夏皮罗。
[RFC-MTRK-MODEL] Hansen, T., "Message Tracking Model and Requirements", RFC 3888, September 2004.
[RFC-MTRK-MODEL]Hansen，T，“消息跟踪模型和需求”，RFC 3888，2004年9月。
[RFC-MTRK-MTQP] Hansen, T., "Message Tracking Query Protocol", RFC 3887, September 2004.
[RFC-MTRK-MTQP]Hansen，T，“消息跟踪查询协议”，RFC 3887，2004年9月。
[RFC-ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC-ABNF]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[RFC-ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
[RFC-ESMTP]Klensin，J.，Freed，N.，Rose，M.，Stefferud，E.，和D.Crocker，“SMTP服务扩展”，STD 10，RFC 18691995年11月。
[RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC-MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC-MIME]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[NIST-SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard" National Institute of Standards and Technology, U.S. Department of Commerce, May 1994.
[NIST-SHA1]NIST FIPS PUB 180-1，“安全哈希标准”，美国商务部国家标准与技术研究所，1994年5月。
[RFC-SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC-SMTP]Klensin，J.，Ed.，“简单邮件传输协议”，RFC 28212001年4月。
[RFC-MSGFMT] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[RFC-MSGFMT]Resnick，P.，Ed.“互联网信息格式”，RFC 2822，2001年4月。
[RFC-DELIVERYBY] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 2000.
[RFC-DELIVERYBY]Newman，D.，“通过SMTP服务扩展进行交付”，RFC 2852000年6月。
[RFC-DSN-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[RFC-DSN-SMTP]Moore，K.，“用于传递状态通知（DSN）的简单邮件传输协议（SMTP）服务扩展”，RFC 34612003年1月。
[RFC-MDN] Hansen, T. and G. Vaudreuil, Eds., "Message Disposition Notification", RFC 3798, May 2004.
[RFC-MDN]Hansen，T.和G.Vaudreuil，编辑，“消息处置通知”，RFC 3798，2004年5月。
[RFC-RANDOM] Eastlake, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC-RANDOM]伊斯特莱克，D.，克罗克，S.，和J.席勒，“安全的随机性建议”，RFC 1750，1994年12月。
Eric Allman Sendmail, Inc. 6425 Christie Ave, 4th Floor Emeryville, CA 94608 U.S.A.
Eric Allman Sendmail，Inc.美国加利福尼亚州埃默里维尔克里斯蒂大道6425号4楼，邮编94608。
Phone: +1 510 594 5501
Fax: +1 510 594 5429
EMail: eric@Sendmail.COM
Phone: +1 510 594 5501
Fax: +1 510 594 5429
EMail: eric@Sendmail.COM
Tony Hansen AT&T Laboratories Middletown, NJ 07748 U.S.A.
美国新泽西州米德尔顿市托尼·汉森AT&T实验室，邮编：07748。
Phone: +1 732 420 8934
EMail: tony+msgtrk@maillennium.att.com
Phone: +1 732 420 8934
EMail: tony+msgtrk@maillennium.att.com
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编辑功能的资金目前由互联网协会提供。