Network Working Group E. Hall
Request for Comments: 4155 September 2005
Category: Informational
Network Working Group E. Hall
Request for Comments: 4155 September 2005
Category: Informational
The application/mbox Media Type
应用程序/mbox媒体类型
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This memo requests that the application/mbox media type be authorized for allocation by the IESG, according to the terms specified in RFC 2048. This memo also defines a default format for the mbox database, which must be supported by all conformant implementations.
本备忘录要求IESG根据RFC 2048中规定的条款授权分配应用程序/mbox介质类型。此备忘录还定义了mbox数据库的默认格式，所有一致性实现都必须支持该格式。
UNIX-like operating systems have historically made widespread use of "mbox" database files for a variety of local email purposes. In the common case, mbox files store linear sequences of one or more electronic mail messages, with local email clients treating the database as a logical folder of email messages. mbox databases are also used by a variety of other messaging tools, such as mailing list management programs, archiving and filtering utilities, messaging servers, and other related applications. In recent years, mbox databases have also become common on a large number of non-UNIX computing platforms, for similar kinds of purposes.
类似UNIX的操作系统历来广泛使用“mbox”数据库文件用于各种本地电子邮件目的。在常见情况下，mbox文件存储一个或多个电子邮件消息的线性序列，本地电子邮件客户端将数据库视为电子邮件消息的逻辑文件夹。mbox数据库还可用于各种其他消息传递工具，如邮件列表管理程序、归档和筛选实用程序、消息传递服务器和其他相关应用程序。近年来，出于类似目的，mbox数据库在大量非UNIX计算平台上也变得很常见。
The increased pervasiveness of these files has led to an increased demand for a standardized, network-wide interchange of these files as discrete database objects. In turn, this dictates a need for a general media type definition for mbox files, which is the subject and purpose of this memo.
这些文件的日益普及导致了对这些文件作为离散数据库对象进行标准化、网络范围的交换的需求增加。反过来，这要求mbox文件需要一个通用的媒体类型定义，这是本备忘录的主题和目的。
The mbox database format is not documented in an authoritative specification, but instead exists as a well-known output format that is anecdotally documented, or which is only authoritatively documented for a specific platform or tool.
mbox数据库格式未在权威规范中记录，而是作为一种众所周知的输出格式存在，该格式以轶事形式记录，或仅针对特定平台或工具进行权威性记录。
mbox databases typically contain a linear sequence of electronic mail messages. Each message begins with a separator line that identifies the message sender, and also identifies the date and time at which the message was received by the final recipient (either the last-hop system in the transfer path, or the system which serves as the recipient's mailstore). Each message is typically terminated by an empty line. The end of the database is usually recognized by either the absence of any additional data, or by the presence of an explicit end-of-file marker.
mbox数据库通常包含电子邮件消息的线性序列。每封邮件都以分隔符行开头，分隔符行用于标识邮件发送者，还用于标识最终收件人（传输路径中的最后一个跃点系统或用作收件人邮件存储的系统）接收邮件的日期和时间。每条消息通常以空行结尾。数据库的结尾通常通过缺少任何附加数据或存在明确的文件结尾标记来识别。
The structure of the separator lines vary across implementations, but usually contain the exact character sequence of "From", followed by a single Space character (0x20), an email address of some kind, another Space character, a timestamp sequence of some kind, and an end-of-line marker. However, due to the lack of any authoritative specification, each of these attributes are known to vary widely across implementations. For example, the email address can reflect any addressing syntax that has ever been used on any messaging system in all of history (specifically including address forms that are not compatible with Internet messages, as defined by RFC 2822 [RFC2822]). Similarly, the timestamp sequences can also vary according to system output, while the end-of-line sequences will often reflect platform-specific requirements. Different data formats can even appear within a single database as a result of multiple mbox files being concatenated together, or because a single file was accessed by multiple messaging clients, each of which has used its own syntax for the separator line.
分隔符行的结构因实现而异，但通常包含“From”的确切字符序列，后跟单个空格字符（0x20）、某种电子邮件地址、另一种空格字符、某种时间戳序列和行尾标记。然而，由于缺乏任何权威规范，这些属性中的每一个在不同的实现中都有很大的差异。例如，电子邮件地址可以反映历史上任何消息传递系统上使用过的任何寻址语法（具体包括RFC 2822[RFC2822]定义的与互联网消息不兼容的地址形式）。类似地，时间戳序列也可以根据系统输出而变化，而行尾序列通常会反映特定于平台的需求。由于多个mbox文件被连接在一起，或者由于多个消息传递客户端访问了单个文件，每个客户端都使用了自己的语法作为分隔线，因此在单个数据库中甚至可能出现不同的数据格式。
Message data within mbox databases often reflects site-specific peculiarities. For example, it is entirely possible for the message body or headers in an mbox database to contain untagged eight-bit character data that implicitly reflects a site-specific default language or locale, or that reflects local defaults for timestamps and email addresses; none of this data is widely portable beyond the local scope. Similarly, message data can also contain unencoded eight-bit binary data, or can use encoding formats that represent a specific platform (e.g., BINHEX or UUENCODE sequences).
mbox数据库中的消息数据通常反映特定于站点的特性。例如，mbox数据库中的消息体或消息头完全可能包含未标记的八位字符数据，该数据隐式地反映特定于站点的默认语言或语言环境，或反映时间戳和电子邮件地址的本地默认值；所有这些数据都不能广泛移植到本地范围之外。类似地，消息数据还可以包含未编码的八位二进制数据，或者可以使用表示特定平台的编码格式（例如，BINHEX或UUENCODE序列）。
Many implementations are also known to escape message body lines that begin with the character sequence of "From ", so as to prevent confusion with overly-liberal parsers that do not search for full separator lines. In the common case, a leading Greater-Than symbol (0x3E) is used for this purpose (with "From " becoming ">From "). However, other implementations are known not to escape such lines unless they are immediately preceded by a blank line or if they also appear to contain an email address and a timestamp. Other implementations are also known to perform secondary escapes against these lines if they are already escaped or quoted, while others ignore these mechanisms altogether.
许多实现还可以转义以“From”字符序列开头的消息体行，以避免与不搜索完整分隔符行的过于自由的解析器混淆。在常见情况下，前导大于符号（0x3E）用于此目的（“From”变为“>From”）。然而，已知其他实现不会转义这些行，除非它们前面紧跟着一个空行，或者它们似乎也包含电子邮件地址和时间戳。如果这些行已经转义或引用，其他实现也会对它们执行二次转义，而其他实现则完全忽略这些机制。
A comprehensive description of mbox database files on UNIX-like systems can be found at http://qmail.org./man/man5/mbox.html, which should be treated as mostly authoritative for those variations that are otherwise only documented in anecdotal form. However, readers are advised that many other platforms and tools make use of mbox databases, and that there are many more potential variations that can be encountered in the wild.
有关类UNIX系统上mbox数据库文件的全面说明，请访问http://qmail.org./man/man5/mbox.html，对于那些仅以轶事形式记录的变体，应将其视为最权威的。然而，读者们被告知，许多其他平台和工具使用mbox数据库，并且在野外可能会遇到更多的潜在变化。
In order to mitigate errors that may arise from such vagaries, this specification defines a "format" parameter to the application/mbox media type declaration, which can be used to identify the specific kind of mbox database that is being transferred. Furthermore, this specification defines a "default" database format which MUST be supported by implementations that claim to be compliant with this specification, and which is to be used as the implicit format for undeclared application/mbox data objects. Additional format types are to be defined in subsequent specifications. Messaging systems that receive an mbox database with an unknown format parameter value SHOULD treat the data as an opaque binary object, as if the data had been declared as application/octet-stream
为了减轻这些异常情况可能导致的错误，本规范为应用程序/mbox媒体类型声明定义了一个“格式”参数，该参数可用于标识正在传输的特定类型的mbox数据库。此外，本规范定义了一种“默认”数据库格式，声称符合本规范的实现必须支持该格式，并将其用作未声明的应用程序/mbox数据对象的隐式格式。其他格式类型将在后续规范中定义。接收具有未知格式参数值的mbox数据库的消息传递系统应将数据视为不透明的二进制对象，就像数据已声明为应用程序/八位字节流一样
Refer to Appendix A for a description of the default mbox format.
有关默认mbox格式的说明，请参阅附录A。
Note that RFC 2046 [RFC2046] defines the multipart/digest media type for transferring platform-independent message files. Because that specification defines a set of neutral and strict formatting rules, the multipart/digest media type already facilitates highly-predictable transfer and conversion operations; as such, implementers are strongly encouraged to support and use that media type where possible.
请注意，RFC 2046[RFC2046]定义了用于传输独立于平台的消息文件的多部分/摘要媒体类型。由于该规范定义了一组中性和严格的格式化规则，因此多部分/摘要媒体类型已经促进了高度可预测的传输和转换操作；因此，强烈鼓励实施者在可能的情况下支持和使用该媒体类型。
Readers of this document are expected to be familiar with the specification for MIME [RFC2045] and MIME-type registrations [RFC2048].
本文档的读者应该熟悉MIME[RFC2045]和MIME类型注册[RFC2048]的规范。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This section provides the media type registration application (as per [RFC2048]).
本节提供媒体类型注册应用程序（根据[RFC2048]）。
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: mbox
MIME子类型名称：mbox
Required parameters: none
所需参数：无
Optional parameters: The "format" parameter identifies the format of the mbox database and the messages contained therein. The default value for the "format" parameter is "default", and refers to the formatting rules defined in Appendix A of this memo. mbox databases that do not have a "format" parameter SHOULD be interpreted as having the implicit "format" value of "default". mbox databases that have an unknown value for the "format" parameter SHOULD be treated as opaque data objects, as if the media type had been specified as application/octet-stream. Additional values for the format parameter are to be defined in subsequent specifications, and registered with IANA.
可选参数：“format”参数标识mbox数据库的格式以及其中包含的消息。“format”参数的默认值为“default”，指本备忘录附录A中定义的格式规则。没有“format”参数的mbox数据库应解释为具有隐式“format”值“default”。对于“format”参数具有未知值的mbox数据库，应将其视为不透明数据对象，就像将媒体类型指定为应用程序/八位字节流一样。格式参数的附加值将在后续规范中定义，并在IANA中注册。
Encoding considerations: If an email client receives an mbox database as a message attachment, and then stores that attachment within a local mbox database, the contents of the two database files may become irreversibly intermingled, such that both databases are rendered unrecognizable. In order to avoid these collisions, messaging systems that support this specification MUST encode an mbox database (or at a minimum, the separator lines) with non-transparent transfer encoding (such as BASE64 or Quoted-Printable) whenever an application/mbox object is transferred via messaging protocols. Other transfer services are generally encouraged to adopt similar encoding strategies in order to allow for any subsequent retransmission that might occur, but this is not a requirement. Implementers should also be prepared to encode mbox data locally if non-compliant data is received.
编码注意事项：如果电子邮件客户端将mbox数据库作为邮件附件接收，然后将该附件存储在本地mbox数据库中，则两个数据库文件的内容可能会不可逆转地混合在一起，从而使两个数据库都无法识别。为了避免这些冲突，每当通过消息传递协议传输应用程序/mbox对象时，支持此规范的消息传递系统必须使用非透明传输编码（例如BASE64或带引号的Printable）对mbox数据库（或至少分隔线）进行编码。通常鼓励其他传输服务采用类似的编码策略，以便允许可能发生的任何后续重传，但这不是一项要求。如果收到不符合要求的数据，实施者还应准备在本地对mbox数据进行编码。
Security considerations: mbox data is passive, and does not generally represent a unique or new security threat. However, there is risk in sharing any kind of data, because unintentional information may be exposed, and this risk certainly applies to mbox data as well.
安全注意事项：mbox数据是被动的，通常不代表唯一或新的安全威胁。然而，共享任何类型的数据都有风险，因为可能会暴露无意的信息，这种风险当然也适用于mbox数据。
Interoperability considerations: Due to the lack of a single authoritative specification for mbox databases, there are a large number of variations between database formats (refer to the introduction text for common examples), and it is expected that non-conformant data will be erroneously tagged or exchanged. Although the "default" format specified in this memo does not allow for these kinds of vagaries, prior negotiation or agreement between humans may sometimes be needed.
互操作性注意事项：由于缺乏mbox数据库的单一权威规范，数据库格式之间存在大量差异（参考介绍文本了解常见示例），预计不一致数据将被错误标记或交换。尽管本备忘录中规定的“默认”格式不允许出现此类异常情况，但有时可能需要事先协商或达成协议。
Published specification: see Appendix A.
公布的规范：见附录A。
Applications that use this media type: hundreds of messaging products make use of the mbox database format, in one form or another.
使用这种媒体类型的应用程序：数百种消息传递产品以某种形式使用mbox数据库格式。
Magic number(s): mbox database files can be recognized by having a leading character sequence of "From", followed by a single Space character (0x20), followed by additional printable character data (refer to the description in Appendix A for details). However, implementers are cautioned that all such files will not be compliant with all of the formatting rules, therefore implementers should treat these files with an appropriate amount of circumspection.
幻数：mbox数据库文件的识别方法是：前导字符序列为“From”，后跟一个空格字符（0x20），后跟其他可打印字符数据（有关详细信息，请参阅附录a中的说明）。但是，实现者需要注意的是，所有这些文件都不会符合所有的格式规则，因此实现者应该谨慎对待这些文件。
File extension(s): mbox database files sometimes have an ".mbox" extension, but this is not required nor expected. As with magic numbers, implementers should avoid reflexive assumptions about the contents of such files.
文件扩展名：mbox数据库文件有时具有“.mbox”扩展名，但这不是必需的，也不是预期的。与幻数一样，实现者应该避免对这些文件的内容进行自反性假设。
Macintosh File Type Code(s): None are known to be common.
Macintosh文件类型代码：已知没有常见的文件类型代码。
Person & email address to contact for further information: Eric A. Hall (ehall@ntrg.com)
联系人和电子邮件地址，以获取更多信息：Eric A.Hall(ehall@ntrg.com)
Intended usage: COMMON
预期用途：普通
See the discussion in section 4.
参见第4节中的讨论。
The IANA has registered the application/mbox media type in the MIME registry, using the application provided in section 4 above.
IANA已经使用上面第4节提供的应用程序在MIME注册表中注册了应用程序/mbox媒体类型。
Furthermore, IANA has established and will maintain a registry of values for the "format" parameter as described in this memo. The first registration is the "default" value, using the description provided in Appendix A. Subsequent values for the "format" parameter MUST be accompanied by some form of recognizable, complete, and legitimate specification, such as an IESG-approved specification, or some kind of authoritative vendor documentation.
此外，IANA已建立并将维护本备忘录中所述的“格式”参数值注册表。第一次注册是“默认”值，使用附录A中提供的说明。随后的“格式”参数值必须附有某种形式的可识别、完整和合法的规范，如IESG批准的规范或某种权威的供应商文件。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
[RFC2048]Freed，N.，Klensin，J.和J.Postel，“多用途互联网邮件扩展（MIME）第四部分：注册程序”，BCP 13，RFC 2048，1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
Appendix A. The "default" mbox Database Format
附录A.“默认”mbox数据库格式
In order to improve interoperability among messaging systems, this memo defines a "default" mbox database format, which MUST be supported by all implementations that claim to be compliant with this specification.
为了提高消息传递系统之间的互操作性，本备忘录定义了“默认”mbox数据库格式，所有声称符合本规范的实现都必须支持该格式。
The "default" mbox database format uses a linear sequence of Internet messages, with each message being immediately prefaced by a separator line, and being terminated by an empty line. More specifically:
“默认”mbox数据库格式使用互联网消息的线性序列，每条消息的前面都有一个分隔符行，最后是一个空行。更具体地说：
o Each message within the database MUST follow the syntax and formatting rules defined in RFC 2822 [RFC2822] and its related specifications, with the exception that the canonical mbox database MUST use a single Line-Feed character (0x0A) as the end-of-line sequence, and MUST NOT use a Carriage-Return/Line-Feed pair (NB: this requirement only applies to the canonical mbox database as transferred, and does not override any other specifications). This usage represents the most common historical representation of the mbox database format, and allows for the least amount of conversion.
o 数据库中的每条消息必须遵循RFC 2822[RFC2822]及其相关规范中定义的语法和格式规则，但规范mbox数据库必须使用单换行字符（0x0A）作为行尾序列，并且不得使用回车符/换行符对（注意：此要求仅适用于传输的规范mbox数据库，不覆盖任何其他规范）。此用法表示mbox数据库格式最常见的历史表示形式，并允许最少的转换量。
o Messages within the default mbox database MUST consist of seven-bit characters within an eight-bit stream. Eight-bit data within the stream MUST be converted to a seven-bit form (using appropriate, standardized encoding) and appropriately tagged (with the correct header fields) before the database is transferred.
o 默认mbox数据库中的消息必须由八位流中的七位字符组成。在传输数据库之前，必须将流中的8位数据转换为7位形式（使用适当的标准化编码）并进行适当标记（使用正确的头字段）。
o Message headers and data in the default mbox database MUST be fully-qualified, as per the relevant specification(s). For example, email addresses in the various header fields MUST have legitimate domain names (as per RFC 2822), while extended characters and encodings MUST be specified in the appropriate location (as per the appropriate MIME specifications), and so forth.
o 根据相关规范，默认mbox数据库中的消息头和数据必须完全合格。例如，各个标题字段中的电子邮件地址必须具有合法的域名（根据RFC 2822），而扩展字符和编码必须在适当的位置指定（根据适当的MIME规范），等等。
o Each message in the mbox database MUST be immediately preceded by a single separator line, which MUST conform to the following syntax:
o mbox数据库中的每条消息前面必须紧跟一行分隔符，该分隔符必须符合以下语法：
The exact character sequence of "From";
“From”的确切字符序列；
a single Space character (0x20);
单个空格字符（0x20）；
the email address of the message sender (as obtained from the message envelope or other authoritative source), conformant with the "addr-spec" syntax from RFC 2822;
消息发送者的电子邮件地址（从消息信封或其他权威来源获得），符合RFC 2822中的“addr spec”语法；
a single Space character;
单个空格字符；
a timestamp indicating the UTC date and time when the message was originally received, conformant with the syntax of the traditional UNIX 'ctime' output sans timezone (note that the use of UTC precludes the need for a timezone indicator);
一个时间戳，指示最初收到消息时的UTC日期和时间，符合传统UNIX“ctime”输出无时区的语法（注意，使用UTC不需要时区指示器）；
an end-of-line marker.
一种行尾标记。
o Each message in the database MUST be terminated by an empty line, containing a single end-of-line marker.
o 数据库中的每条消息都必须以空行终止，其中包含一个行结束标记。
Note that the first message in an mbox database will only be prefaced by a separator line, while every other message will begin with two end-of-line sequences (one at the end of the message itself, and another to mark the end of the message within the mbox database file stream) and a separator line (marking the new message). The end of the database is implicitly reached when no more message data or separator lines are found.
请注意，mbox数据库中的第一条消息将仅以分隔符行开头，而每一条消息都将以两个行尾序列（一个在消息本身的末尾，另一个在mbox数据库文件流中标记消息的结尾）和分隔符行（标记新消息）开头。当找不到更多的消息数据或分隔符行时，将隐式到达数据库的末尾。
Also note that this specification does not prescribe any escape syntax for message body lines that begin with the character sequence of "From ". Recipient systems are expected to parse full separator lines as they are documented above.
还要注意，本规范没有规定以“From”字符序列开头的消息正文行的转义语法。收件人系统需要解析完整的分隔符行，如上所述。
Author's Address
作者地址
Eric A. Hall
埃里克·A·霍尔
EMail: ehall@ntrg.com
EMail: ehall@ntrg.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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.
本文件受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编辑功能的资金目前由互联网协会提供。