Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 6647 Cloudmark
Category: Standards Track D. Crocker
ISSN: 2070-1721 Brandenburg InternetWorking
June 2012
Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 6647 Cloudmark
Category: Standards Track D. Crocker
ISSN: 2070-1721 Brandenburg InternetWorking
June 2012
Email Greylisting: An Applicability Statement for SMTP
电子邮件Greylisting：SMTP的适用性声明
Abstract
摘要
This document describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism.
本文档描述了电子邮件灰色列表的艺术，即为未知电子邮件客户端提供临时降级服务作为一种防滥用机制的实践。
Greylisting is an established mechanism deemed essential to the repertoire of current anti-abuse email filtering systems.
Greylisting是一种已建立的机制，被认为是当前反滥用电子邮件过滤系统的重要组成部分。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6647.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6647.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Background .................................................3
1.2. Definitions ................................................4
2. Types of Greylisting ............................................4
2.1. Connection-Level Greylisting ...............................4
2.2. SMTP HELO/EHLO Greylisting .................................5
2.3. SMTP MAIL Greylisting ......................................5
2.4. SMTP RCPT Greylisting ......................................5
2.5. SMTP DATA Greylisting ......................................6
2.6. Additional Heuristics ......................................7
2.7. Exceptions .................................................7
3. Benefits and Costs ..............................................8
4. Unintended Consequences .........................................9
4.1. Unintended Mail Delivery Failures ..........................9
4.2. Unintended SMTP Client Failures ...........................10
4.3. Address Space Saturation ..................................11
5. Recommendations ................................................12
6. Measuring Effectiveness ........................................13
7. IPv6 Applicability .............................................14
8. Security Considerations ........................................14
8.1. Trade-Offs ................................................14
8.2. Database ..................................................14
9. References .....................................................15
9.1. Normative References ......................................15
9.2. Informative References ....................................15
Appendix A. Acknowledgments ......................................17
1. Introduction ....................................................3
1.1. Background .................................................3
1.2. Definitions ................................................4
2. Types of Greylisting ............................................4
2.1. Connection-Level Greylisting ...............................4
2.2. SMTP HELO/EHLO Greylisting .................................5
2.3. SMTP MAIL Greylisting ......................................5
2.4. SMTP RCPT Greylisting ......................................5
2.5. SMTP DATA Greylisting ......................................6
2.6. Additional Heuristics ......................................7
2.7. Exceptions .................................................7
3. Benefits and Costs ..............................................8
4. Unintended Consequences .........................................9
4.1. Unintended Mail Delivery Failures ..........................9
4.2. Unintended SMTP Client Failures ...........................10
4.3. Address Space Saturation ..................................11
5. Recommendations ................................................12
6. Measuring Effectiveness ........................................13
7. IPv6 Applicability .............................................14
8. Security Considerations ........................................14
8.1. Trade-Offs ................................................14
8.2. Database ..................................................14
9. References .....................................................15
9.1. Normative References ......................................15
9.2. Informative References ....................................15
Appendix A. Acknowledgments ......................................17
Preferred techniques for handling email abuse explicitly identify good actors and bad actors, giving each significantly different service quality. In some cases, an actor does not have a known reputation; this can justify providing degraded service, until there is a basis for providing better service. This latter approach is known as "greylisting". Broadly, the term refers to any degradation of service for an unknown or suspect source, over a period of time (typically measured in minutes or a small number of hours). The narrow use of the term refers to generation of an SMTP temporary failure reply code for traffic from such sources. There are diverse implementations of this basic concept and predictably, therefore, some blurred terminology.
处理电子邮件滥用的首选技术明确地确定了好的参与者和坏的参与者，使每个参与者的服务质量显著不同。在某些情况下，演员没有知名度；这可以证明提供降级服务是合理的，直到有了提供更好服务的基础。后一种方法称为“灰色列表”。广义上，该术语指在一段时间内（通常以分钟或少量小时为单位）未知或可疑来源的任何服务降级。该术语的狭义用法是指为来自此类源的流量生成SMTP临时故障回复代码。这一基本概念有多种不同的实现方式，因此，可以预见，有些术语是模糊的。
Absent a perfect abuse-detection mechanism that incurs no cost, the current requirement is for an array of techniques to be used by each filtering system. They range in cost, effectiveness, and types of abuse techniques they target.
由于缺乏一个不产生成本的完善的滥用检测机制，目前的要求是每个过滤系统使用一系列技术。它们在成本、有效性和它们所针对的滥用技术类型方面都存在差异。
Greylisting happens to be a technique that is cheap and early (in terms of its application in the SMTP sequence) and surprisingly remains useful. Some spamware does indeed route around this technique, but much does not.
Greylisting恰好是一种廉价且早期的技术（就其在SMTP序列中的应用而言），并且令人惊讶地仍然有用。一些spamware确实绕过了这一技术，但很多并非如此。
The firehose of spam over the Internet represents a wide range of sophistication. Greylisting is useful for removing a large amount of simplistic-but-significant traffic.
互联网上的垃圾信息代表了一种广泛的复杂性。灰色列表对于删除大量简单但重要的流量非常有用。
This memo documents common greylisting techniques and discusses their benefits and costs. It also defines terminology to enable clear distinction and discussion of these techniques.
本备忘录记录了常见的灰色列表技术，并讨论了它们的优点和成本。它还定义了术语，以明确区分和讨论这些技术。
There is some confusion in the industry that conflates greylisting with an SMTP temporary failure for any reason. The purpose of this memo is also to dispel such confusion.
业界存在一些混淆，将灰色列表与SMTP临时失败混为一谈，不管原因为何。这份备忘录的目的也是为了消除这种混乱。
For many years, large amounts of spam have been sent through purpose-built software, or "spamware", that supports only a constrained version of SMTP. In particular, such software does not perform retransmission attempts after receiving an SMTP temporary failure. That is, if the spamware cannot deliver a message, it just goes on to the next address in its list since, in spamming, volume counts for far more than reliability. Greylisting exploits this by rejecting mail from unfamiliar sources with a "transient (soft) fail" (4xx) [SMTP] error code. Another application of greylisting is to delay
多年来，大量垃圾邮件都是通过专门构建的软件或“spamware”发送的，该软件只支持受限制的SMTP版本。特别是，此类软件在收到SMTP临时故障后不会执行重新传输尝试。也就是说，如果垃圾软件无法传递消息，它只会继续发送到列表中的下一个地址，因为在垃圾软件中，数量远远超过可靠性。Greylisting通过拒绝来自不熟悉来源的带有“暂时（软）失败”（4xx）[SMTP]错误代码的邮件来利用此漏洞。灰色列表的另一个应用是延迟
mail from newly seen IP addresses on the theory that, if it's a spam source, then by the time it retries, it will appear in a list of sources to be filtered, and the mail will not be accepted.
来自新出现的IP地址的邮件的原理是，如果它是垃圾邮件源，那么当它重试时，它将出现在要过滤的源列表中，邮件将不会被接受。
Early references for greylisting descriptions and implementations can be found at [SAUCE] and [PUREMAGIC].
关于灰色列表的描述和实现的早期参考资料可以在[SAUCE]和[PUREMAGIC]上找到。
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 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
Readers need to be familiar with the material and terminology discussed in [MAIL], [EMAIL-ARCH], and [SMTP].
读者需要熟悉[MAIL]、[EMAIL-ARCH]和[SMTP]中讨论的材料和术语。
Greylisting is primarily performed at some phase during an SMTP session. A set of attributes about the client-side SMTP server are used for assessing whether to perform greylisting. At its simplest, the attribute is the IP address of the client, and the assessment is whether it has previously connected recently. More elaborate attribute combinations and more sophisticated assessments can be performed. The following discussion covers the most common combinations and relies on knowledge of [SMTP], its commands, and the distinction between envelope and content.
Greylisting主要在SMTP会话期间的某个阶段执行。客户端SMTP服务器的一组属性用于评估是否执行灰色列表。最简单的情况是，该属性是客户端的IP地址，评估是它以前是否最近连接过。可以执行更复杂的属性组合和更复杂的评估。下面的讨论涵盖了最常见的组合，并依赖于[SMTP]的知识、其命令以及信封和内容之间的区别。
Connection-level greylisting decides whether to accept the TCP connection from a "new" [SMTP] client. At this point in the communication between the client and the server, the only information known to the receiving server is the incoming IP address. This, of course, is often (but not always) translatable into a host name.
连接级别greylisting决定是否接受来自“新”[SMTP]客户端的TCP连接。在客户端和服务器之间的通信中，接收服务器所知道的唯一信息是传入的IP地址。当然，这通常（但并非总是）可翻译为主机名。
The typical application of greylisting here is to keep a record of SMTP client IP addresses and/or host names (collectively, "sources") that have been seen. Such a database acts as a cache of known senders and might or might not expire records after some period. If the source is not in the database, or the record of the source has not reached some required minimum age (such as 30 minutes since the initial connection attempt), the server does one of the following, inviting a later retry:
这里greylisting的典型应用是保存已看到的SMTP客户端IP地址和/或主机名（统称为“源”）的记录。这样的数据库充当已知发送者的缓存，在一段时间后，记录可能会过期，也可能不会过期。如果源不在数据库中，或者源的记录未达到所需的最短期限（例如，自初始连接尝试后30分钟），服务器将执行以下操作之一，邀请稍后重试：
o returns a 421 SMTP reply and closes the connection, or
o 返回421 SMTP回复并关闭连接，或
o returns a different 4yz SMTP reply to all further commands in this SMTP session.
o 对此SMTP会话中的所有其他命令返回不同的4yz SMTP答复。
A useful variant of the basic known/unknown policy is to limit greylisting to those addresses that are on some list of IP addresses known to be affiliated with bad actors. Whereas the simpler policy affects all new connections, including those from good actors, the constrained policy applies greylisting actions only to sites that already have a negative reputation.
基本已知/未知策略的一个有用变体是将灰色列表限制在已知与坏参与者相关的IP地址列表中的那些地址。较简单的策略会影响所有新的连接，包括来自好参与者的连接，而受约束的策略只会将灰色列表操作应用于已经具有负面声誉的站点。
HELO/EHLO greylisting refers to the first command verb in an SMTP session. It includes a single, required parameter that is supposed to contain the client's fully qualified host name or its literal IP address.
HELO/EHLO greylisting是指SMTP会话中的第一个命令动词。它包含一个必需的参数，该参数应包含客户端的完全限定主机名或其文本IP地址。
Greylisting implemented at this phase retains a record of sources coupled with HELO/EHLO parameters. It returns 4yz SMTP replies to all commands until the end of the SMTP session if that tuple has not previously been recorded or if the record exists but has not reached some configured minimum age.
在此阶段实现的灰色列表保留了与HELO/EHLO参数耦合的源记录。如果以前未记录该元组，或者记录存在但未达到某个配置的最低期限，则它将返回4yz SMTP对所有命令的回复，直到SMTP会话结束。
MAIL command greylisting refers to the command verb in an SMTP session that initiates a new transaction. It includes at least one required parameter that indicates the return email address (RFC5321.MailFrom) of the message being relayed from the client to the server.
邮件命令greylisting是指SMTP会话中启动新事务的命令动词。它至少包括一个必需参数，用于指示从客户端中继到服务器的消息的返回电子邮件地址（RFC5321.MailFrom）。
Greylisting implemented at this phase retains a record of sources coupled with return email addresses. It returns 4yz SMTP replies to all commands for the remainder of the SMTP session if that tuple has not previously been recorded or if the record exists but has not met some configured minimum age.
在这个阶段实现的Greylisting保留了一个源的记录以及返回的电子邮件地址。如果以前未记录该元组，或者该记录存在但未满足某些配置的最短期限，则它将返回对SMTP会话剩余部分的所有命令的4yz SMTP回复。
RCPT greylisting refers to the command verb in an SMTP session that specifies intended recipients of an email transaction. It includes at least one required parameter that indicates the email address of an intended recipient of the message being relayed from the client to the server.
RCPT greylisting是指SMTP会话中的命令动词，用于指定电子邮件事务的预期收件人。它包括至少一个必需参数，用于指示从客户端中继到服务器的消息的预期收件人的电子邮件地址。
Greylisting implemented at this phase retains a record of tuples that combines the provided recipient address with any combination of the following:
在此阶段实现的Greylisting保留一个元组记录，该元组将提供的收件人地址与以下任意组合相结合：
o the source, as described above;
o 来源，如上所述；
o the return email address; and
o 返回电子邮件地址；和
o the other recipient addresses of the message (if any).
o 邮件的其他收件人地址（如果有）。
If the selected tuple is not found in the database, or if the record is present but has not reached some configured minimum age, the greylisting Mail Transfer Agent (MTA) [EMAIL-ARCH] returns 4yz SMTP replies to all commands for the remainder of the SMTP session.
如果在数据库中找不到所选元组，或者如果记录存在但未达到某个配置的最低期限，则greylisting邮件传输代理（MTA）[EMAIL-ARCH]会在SMTP会话的剩余时间内返回4yz SMTP对所有命令的回复。
Note that often a match on a tuple involving the first valid RCPT is sufficient to identify a retry correctly, and further checks can be omitted.
请注意，通常情况下，涉及第一个有效RCPT的元组上的匹配足以正确标识重试，并且可以省略进一步的检查。
DATA greylisting refers to the command verb in an SMTP session that transmits the actual message content, as opposed to its envelope details.
数据灰色列表是指SMTP会话中传输实际邮件内容的命令动词，而不是其信封详细信息。
This type of greylisting can be performed at two places in the SMTP sequence:
这种类型的灰色列表可以在SMTP序列中的两个位置执行：
1. on receipt of the DATA command, because at that point the entire envelope has been received (i.e., all MAIL and RCPT commands have been issued); or
1. 收到数据命令时，因为此时已收到整个信封（即已发出所有邮件和RCPT命令）；或
2. on completion of the DATA command, i.e., after the "." that terminates transmission of the message body, since at that point a digest or other analysis of the message could be performed.
2. 数据命令完成时，即在终止消息正文传输的“.”之后，因为此时可以执行消息摘要或其他分析。
Some implementations do filtering here because there are clients that don't bother checking SMTP reply codes to commands other than DATA. Hence, it can be useful to add greylisting capability at that point in an SMTP session.
有些实现在这里进行过滤，因为有些客户端不需要检查SMTP回复代码，而只需要检查数据。因此，在SMTP会话中的该点添加greylisting功能非常有用。
Numerous greylisting policies are possible at this point. All of them retain a record of tuples that combine the various parts of the SMTP transaction in some combination, including:
在这一点上，许多灰色列表策略都是可能的。它们都保留一个元组记录，元组以某种组合方式组合SMTP事务的各个部分，包括：
o the source, as described above;
o 来源，如上所述；
o the return email address;
o 返回电子邮件地址；
o the recipients of the message, as a set or individually;
o 消息的接收者，作为一组或单独；
o identifiers in the message header, such as the contents of the RFC5322.From or RFC5322.To fields;
o 消息头中的标识符，如RFC5322.From或RFC5322.To字段的内容；
o other prominent parts of the content, such as the RFC5322.Subject field;
o 内容的其他突出部分，如RFC5322.主题字段；
o a digest of some or all of the message content, as a test for uniqueness; and
o 部分或全部消息内容的摘要，作为唯一性测试；和
o analysis of arbitrary portions of the message body.
o 分析消息正文的任意部分。
(The last four items in the list above are only possible at the end of DATA, not on receipt of the DATA command.)
（以上列表中的最后四项仅在数据结束时可用，在收到数据命令时不可用。）
If the selected tuple is not found in the database, or if the record exists but has not reached some configured minimum age, the greylisting MTA returns 4yz SMTP replies to all commands for the remainder of the SMTP session.
如果在数据库中找不到选定的元组，或者如果记录存在但未达到某个配置的最低期限，则greylisting MTA将在SMTP会话的其余部分返回4yz SMTP对所有命令的回复。
Since greylisting seeks to target spam senders, it follows that being able to identify spamware within the SMTP context beyond the simple notion of "not seen before" would be desirable. A more targeted approach might also include in its selection heuristics such as the following:
由于greylisting旨在针对垃圾邮件发送者，因此，能够在SMTP上下文中识别垃圾邮件，而不仅仅是简单的“以前未见过”的概念是可取的。更具针对性的方法可能还包括以下选择启发法：
o If a DNS blacklist [DNSBL] lists an IP address but the implementer wishes to be cautious with mitigation actions rather than blocking traffic from the IP address outright, then subject it to greylisting.
o 如果DNS黑名单[DNSBL]列出了一个IP地址，但实施者希望谨慎地采取缓解措施，而不是完全阻止来自IP地址的流量，则将其置于灰色列表中。
o If the value found in a PTR record follows common naming patterns for dynamic IP addresses, then subject it to greylisting.
o 如果PTR记录中的值遵循动态IP地址的通用命名模式，则将其置于灰色列表中。
Most greylisting systems provide for an exception mechanism, allowing one to specify IP addresses, IP address Classless Inter-Domain Routing (CIDR) [CIDR] blocks, host names, or domain names that are exempt from greylisting checks and thus whose SMTP client sessions are not subject to such interference.
大多数greylisting系统提供了一种异常机制，允许用户指定IP地址、IP地址无类域间路由（CIDR）[CIDR]块、主机名或域名，这些都不受greylisting检查的影响，因此其SMTP客户端会话不会受到此类干扰。
Likely candidates to be excepted from greylisting include those known not to retry according to a pattern that will be observed as legitimate and those that send so rarely that they will age out of
可能被排除在灰色列表之外的候选对象包括那些已知不会按照合法模式重试的人，以及那些很少发送邮件以致于过时的人
the database. In both cases, the excepted source is known not to be an abusive one by the site implementing greylisting. Otherwise, typical non-abusive senders will enter the exception list on the first proper retry and remain there permanently.
数据库。在这两种情况下，执行greylisting的站点都知道例外源不是滥用源。否则，典型的非滥用发件人将在第一次正确重试时进入例外列表，并永久保留在该列表中。
One could also use a [DNSBL] that lists known good hosts as a greylisting exception set.
还可以使用[DNSBL]将已知的好主机列为灰色列表异常集。
The most obvious benefit with any of the above techniques is that spamware generally does not retry and is therefore less likely to succeed, absent a record of a previous delivery attempts.
上述任何一种技术最明显的好处是，spamware通常不会重试，因此在没有以前的交付尝试记录的情况下，成功的可能性较小。
The most obvious detriment to implementing greylisting is the imposition of delay on legitimate mail. Some popular MTAs do not retry failed delivery attempts for an hour or more, which can cause expensive delays when delivery of mail is time critical. Worse, some legitimate MTAs do not retry at all. (Note, however, that non-retrying clients are not fully SMTP-capable, per Section 2.1 of [SMTP]. A client does not know, nor is it entitled to know, the reason for the temporary failure status code being returned; greylisting could be in effect, or it could be caused by a local resource issue at the server. A client therefore needs to be equipped to retry in order to be considered fully capable.)
实施greylisting最明显的危害是对合法邮件的延迟。一些流行的MTA不会在一小时或更长时间内重试失败的传递尝试，这可能会在邮件传递时间紧迫时造成昂贵的延迟。更糟糕的是，一些合法的MTA根本不重试。（但是，请注意，根据[SMTP]第2.1节，非重试客户端不完全支持SMTP）。客户端不知道也无权知道返回临时故障状态代码的原因；greylisting可能有效，也可能是由服务器上的本地资源问题引起的。因此，客户端需要具备重试能力才能被视为完全有能力。）
The counterargument to this "false positive" problem is that email has always been a "best-effort" mechanism; thus, this cost is ultimately low in comparison to the cost of dealing with high volumes of unwanted mail. Still, the actual effect of such delays can be significant, such as altering the tone or flow of a multi-participant discussion to a mailing list.
对这一“误报”问题的反驳是，电子邮件一直是一种“尽力而为”的机制；因此，与处理大量无用邮件的成本相比，这一成本最终是较低的。尽管如此，这种延迟的实际影响可能是巨大的，例如改变多参与者讨论的基调或流程到邮件列表。
When the clients are subjected to any kind of reconfiguration, especially network renumbering, the cache of information stored about SMTP client history does not benefit legitimate clients that are already listed for acceptance. To the greylisting implementation, such clients are once again unknown, and they will once again be subjected to the delay.
当客户端进行任何类型的重新配置（尤其是网络重新编号）时，存储的有关SMTP客户端历史记录的信息缓存不会使已列出接受的合法客户端受益。对于greylisting实现，这样的客户机再次是未知的，它们将再次受到延迟的影响。
Another obvious cost is for the required database. It has to be large enough to keep the necessary history and fast enough to avoid excessive inefficiencies in the server's operations. The primary consideration is the maximum age of records in the database. If records age out too soon, then hosts that do retry per [SMTP] will be periodically subjected to greylisting even though they are well-
另一个明显的成本是所需的数据库。它必须足够大以保持必要的历史记录，并且必须足够快以避免服务器操作中的过度低效。主要考虑的是数据库中记录的最长期限。如果记录过期太快，那么按照[SMTP]重试的主机将定期进行灰色列表，即使它们运行良好-
behaved; if records age out after too long a period, then eventually spamware that launches a new campaign will not be identified as "unknown" in this manner and will not be required to retry.
表现；如果记录在一段时间后过期，那么发起新活动的垃圾邮件最终将不会以这种方式被标识为“未知”，也不需要重试。
Presuming that known friendly senders will be manually configured as exceptions to the greylisting check, a steady state will eventually be reached wherein the only mail that is delayed is mail from an IP address that has never sent mail before. Experience suggests that the vast majority of mail comes from places on a developed exception list, so after a training period, only a small proportion of mail is actually affected. The training period could be replaced by processing a history of email traffic and adding the IP addresses from which most traffic arrives to the exception list.
假定已知的友好发件人将被手动配置为greylisting检查的例外情况，最终将达到稳定状态，其中唯一延迟的邮件是来自以前从未发送过邮件的IP地址的邮件。经验表明，绝大多数邮件来自已制定的例外列表中的位置，因此经过一段培训期后，只有一小部分邮件受到实际影响。可以通过处理电子邮件流量历史记录并将大多数流量到达的IP地址添加到异常列表中来替代培训期。
Applying greylisting based on actual message content (i.e., post-DATA) is substantially more expensive than any of the other alternatives both in terms of the resources required to accept and temporarily store a complete message body (which can be quite substantial) and any processing that is done on that content. As a consequence, such methods incur more cost during the session and thus are not typical practice.
基于实际消息内容（即，post数据）应用greylisting比任何其他备选方案都要昂贵得多，无论是在接受和临时存储完整消息体所需的资源方面（这可能是相当可观的），还是在该内容上进行的任何处理方面。因此，此类方法在会话期间会产生更多成本，因此不是典型的实践。
There are a few failure modes of greylisting that are worth considering. For example, consider an email message intended for user@example.com. The example.com domain is served by two receiving mail servers, one called mail1.example.com and one called mail2.example.com. On the first delivery attempt, mail1.example.com greylists the client, and thus the client places the message in its outgoing queue for later retry. Later, when a retry is attempted, mail2.example.com is selected for the delivery, either because mail1.example.com is unavailable or because a round-robin [DNS] evaluation produces that result. However, the two example.com hosts do not share greylisting databases, so the second host again denies the attempt. Thus, although example.com has sought to improve its email throughput by having two servers, it has, in fact, amplified the problem of legitimate mail delay introduced by greylisting.
有一些灰色列表的故障模式值得考虑。例如，考虑一个电子邮件消息user@example.com. example.com域由两个接收邮件的服务器提供服务，一个名为mail1.example.com，另一个名为mail2.example.com。在第一次尝试传递时，mail1.example.com会将客户机列为灰色列表，因此客户机会将消息放入其传出队列中，以便稍后重试。稍后，当尝试重试时，会选择mail2.example.com进行传递，这可能是因为mail1.example.com不可用，或者是因为循环[DNS]计算产生了该结果。但是，这两个example.com主机不共享greylisting数据库，因此第二个主机再次拒绝尝试。因此，尽管example.com试图通过拥有两台服务器来提高其电子邮件吞吐量，但事实上，它加剧了greylisting带来的合法邮件延迟问题。
Similarly, consider a site with multiple outbound MTAs that share a common queue. On a first outbound delivery attempt to example.com, the attempt is greylisted. On a later retry, a different outbound MTA is selected, which means example.com sees a different source, and once again greylisting occurs on the same message. The same effect can result from the use of [DHCP], where the IP address of an outbound MTA changes between attempts.
类似地，考虑具有多个出站MTA的站点，共享共享队列。在第一次尝试向example.com进行出站传递时，该尝试被列为灰色列表。稍后重试时，会选择不同的出站MTA，这意味着example.com会看到不同的源，并且同一邮件上再次出现灰色列表。使用[DHCP]也会产生同样的效果，其中出站MTA的IP地址在尝试之间会发生更改。
For systems that do DATA-level greylisting, if any part of the message has changed since the first attempt, the tuple constructed might be different than the one for the first attempt, and the delivery is again greylisted. Some MTAs do reformulate portions of the message at submission time, and this can produce visible differences for each attempt.
对于执行数据级灰色列表的系统，如果消息的任何部分在第一次尝试后发生了更改，则构造的元组可能与第一次尝试的元组不同，并且传递再次被灰色列表。有些MTA会在提交时重新格式化邮件的某些部分，这会在每次尝试时产生明显的差异。
A host that sends mail to a particular destination infrequently might not remain "known" in the receiving server's database and will therefore be greylisted for a high percentage of mail despite possibly being a legitimate sender.
不经常向特定目的地发送邮件的主机可能在接收服务器的数据库中并不“已知”，因此，尽管可能是合法的发件人，但仍会被列为高百分比邮件的灰色列表。
All of these and other similar cases can cause greylisting to be applied improperly to legitimate MTAs multiple times, leading to long delays in delivery or ultimately the return of the message to its sender. Other side effects include out-of-order delivery of related sequenced messages.
所有这些和其他类似的情况都可能导致greylisting多次不正确地应用于合法MTA，从而导致邮件传递的长时间延迟或最终返回给发件人。其他副作用包括相关顺序消息的无序传递。
Address translation technologies such as [NAT] cause distinct MTAs to appear to come from a common IP address. This can cause greylisting to be applied only to the first connection attempt from the shared IP address, meaning future MTAs connecting for the first time will be exempted from the protection greylisting provides.
诸如[NAT]之类的地址转换技术会使不同的MTA看起来来自同一个IP地址。这可能会导致灰色列表仅应用于共享IP地址的第一次连接尝试，这意味着将来首次连接的MTA将不受灰色列表提供的保护。
Atypical SMTP client behaviors also need to be considered when deploying greylisting.
在部署greylisting时，还需要考虑非典型SMTP客户端行为。
Some clients do not retry messages for very long periods. Popular open source MTAs implement increasing backoff times when messages receive temporary failure messages and/or degrade queue priority for very large messages. This means greylisting introduces even more delay for MTAs implementing such schemes, and the delay can become large enough to become a nuisance to users.
有些客户端不会很长时间重试消息。流行的开源MTA在消息接收临时失败消息和/或降低非常大的消息的队列优先级时，会增加退避时间。这意味着greylisting为MTA实现此类方案引入了更多的延迟，并且延迟可能会变得足够大，从而对用户造成滋扰。
Some clients do not retry messages at all, in violation of [SMTP]. This means greylisting will cause outright delivery failure right away for sources, envelopes, or messages that it has not seen before, regardless of the client attempting the delivery, essentially treating legitimate mail and spam the same.
某些客户端根本不重试邮件，这违反了[SMTP]。这意味着，对于以前从未见过的来源、信封或邮件，无论客户是否尝试传递，greylisting都会立即导致彻底的传递失败，基本上对合法邮件和垃圾邮件的处理是相同的。
If a greylisting scheme requires a database record to have reached a certain age rather than merely testing for the presence of the record in the database, and the client has a retry schedule that is too aggressive, the client could be subjected to rate limiting by the MTA independent of the restrictions imposed by greylisting.
如果greylisting方案要求数据库记录已达到某个时间段，而不仅仅是测试数据库中是否存在该记录，并且客户端的重试计划过于激进，则客户端可能会受到MTA的速率限制，而与greylisting施加的限制无关。
Some SMTP implementations make the error of treating all error codes as fatal, contrary to [SMTP]; that is, a 4yz response is treated as if it were a 5yz response, and the message is returned to the sender as undeliverable. This can result in such things as inadvertent removal from mailing lists in response to the perceived rejections.
与[SMTP]相反，某些SMTP实现将所有错误代码视为致命错误；也就是说，4yz响应被视为5yz响应，消息被返回给发送方，作为无法传递。这可能会导致一些事情，例如，由于感知到拒绝而无意中从邮件列表中删除邮件。
Some clients encode message-specific details in the address parameter to the [SMTP] MAIL command. If doing so causes the parameter to change between retry attempts, a greylisting implementation could see it as a new delivery rather than a retry and disallow the delivery. In such cases, the mail will never be delivered and will be returned to the sender after the retry timeout expires.
某些客户端将address参数中特定于邮件的详细信息编码为[SMTP]邮件命令。如果这样做会导致参数在重试尝试之间发生更改，则灰色列表实现可能会将其视为新的传递，而不是重试，并禁止传递。在这种情况下，邮件将永远不会被传递，并将在重试超时过期后返回给发件人。
A client subjected to greylisting might move to the next host found in the ordered [DNS] MX record set for the destination domain and re-attempt delivery. This has several considerations of its own:
接受灰色列表的客户端可能会移动到目标域的有序[DNS]MX记录集中找到的下一个主机，并重新尝试传递。这有几个考虑因素：
o Traffic to those alternate servers increases merely as a result of greylisting.
o 到这些备用服务器的流量仅仅是由于灰色列表而增加的。
o Alternate (MX) servers SHOULD share the same greylisting database. When they do not -- as is often true when the servers occupy different Administrative Management Domains (ADMDs) -- SMTP clients can see variable treatment if they try to send to different MX hosts.
o 备用（MX）服务器应共享相同的灰色列表数据库。如果它们不这样做——当服务器占用不同的管理管理域（ADMD）时通常是这样——SMTP客户端在尝试发送到不同的MX主机时会看到不同的处理方式。
o When alternate MX servers relay mail back to the "primary" MX server, the latter SHOULD be configured to permit the other servers to relay mail without being subjected to greylisting.
o 当备用MX服务器将邮件中继回“主”MX服务器时，应将后者配置为允许其他服务器中继邮件而不必进行灰色列表。
There are some applications that connect to an SMTP server and simulate a transaction up to the point of sending the RCPT command in an attempt to confirm that an address is valid. Some of these are legitimate applications (e.g., mailing list servers), and others are automated programs that attempt to ascertain valid addresses to which to send spam (a "directory harvesting" attack). Greylisting can interfere with both instances, with harmful effects on the former.
有些应用程序连接到SMTP服务器并模拟事务，直到发送RCPT命令为止，以尝试确认地址是否有效。其中一些是合法的应用程序（如邮件列表服务器），另一些是自动程序，试图确定发送垃圾邮件的有效地址（“目录捕获”攻击）。灰色列表可能会干扰这两种情况，对前者产生有害影响。
Greylisting is obviously not a foolproof solution to avoiding abusive traffic. Bad actors that send mail with just enough frequency to avoid having their records expire will never be caught by this mechanism after the first instance.
对于避免滥用流量，Greylisting显然不是一个万无一失的解决方案。发送邮件的频率刚好足以避免记录过期的坏角色在第一次执行后将永远不会被此机制捕获。
Where this is a concern, combining greylisting with some form of reputation service that estimates the likely behavior for IP addresses that are not intercepted by the greylisting function would be a good choice.
考虑到这一点，将greylisting与某种形式的信誉服务结合起来，以估计greylisting函数未截获的IP地址的可能行为将是一个不错的选择。
The following practices are RECOMMENDED based on collected experience:
根据收集的经验，建议采取以下做法：
1. Implement greylisting based on a tuple consisting of (IP address, RFC5321.MailFrom, and the first RFC5321.RcptTo). It is sufficient to use only the first RFC5321.RcptTo as legitimate MTAs appear not to reorder recipients between retries. Including RFC5321.MailFrom improves accuracy where the IP address is being matched in clusters (e.g., CIDR blocks) rather than precisely (see below). After a successful retry, allow all further [SMTP] traffic from the IP address in that tuple regardless of envelope information.
1. 基于元组实现greylisting，元组包括（IP地址，RFC5321.MailFrom和第一个RFC5321.RcptTo）。仅使用第一个RFC5321.RcptTo就足够了，因为合法MTA似乎不会在重试之间重新排序收件人。包含RFC5321.MailFrom可以提高IP地址在集群（例如CIDR块）中匹配的准确性，而不是精确匹配（见下文）。成功重试后，允许来自该元组中IP地址的所有进一步[SMTP]通信，而不考虑信封信息。
2. Include a configurable range of time within which a retry from a greylisted host is considered and outside of which it is otherwise ignored. The range needs to cover typical retry times of common MTA configurations, thus anticipating that a fully capable MTA will retry sometime after the beginning of the range and before the end of it. The default range SHOULD be from one minute to 24 hours. Retries within the range are permitted and satisfy the greylisting test, and the client is thus no longer likely to be a sender of spam. Retries after the end of the range SHOULD be considered to be a new message for the purposes of greylisting evaluation (i.e., reset the "first seen" timestamp for that IP address). Some sites use a higher time value for the low end of the time range to match common legitimate MTA retry timeouts, but additional benefit from doing so appears unlikely.
2. 包括一个可配置的时间范围，在该时间范围内，将考虑来自灰色列表主机的重试，在该时间范围之外，将忽略该重试。该范围需要涵盖常见MTA配置的典型重试时间，因此预计完全可用的MTA将在范围开始之后和结束之前重试。默认范围应为1分钟到24小时。允许在该范围内重试并满足灰色列表测试，因此客户端不再可能是垃圾邮件的发送者。出于灰色列表评估的目的，范围结束后的重试应视为新消息（即，重置该IP地址的“首次看到”时间戳）。一些站点在时间范围的低端使用更高的时间值来匹配常见的合法MTA重试超时，但这样做的额外好处似乎不太可能。
3. Include a timeout for database entries, after which records for IP addresses that have generated no recent traffic are deleted. This step is intended to re-enable greylisting for an IP address in the event that it has changed "owners" and will subject the client to another round of greylisting. The default SHOULD be at least one week.
3. 包括数据库项的超时，在此超时之后，删除最近没有生成流量的IP地址的记录。此步骤旨在在IP地址已更改“所有者”的情况下为其重新启用灰色列表，并将使客户端接受另一轮灰色列表。默认值应至少为一周。
4. For an Administrative Management Domain (ADMD), all inbound border MTAs listed in the [DNS] SHOULD share a common greylisting database and common greylisting policies. This handles sequences in which a client's retry goes to a different server after the first 4yz reply, and it lets all servers share the list of hosts that did retry successfully.
4. 对于管理管理域（ADMD），[DNS]中列出的所有入站边界MTA应共享一个通用的灰色列表数据库和通用的灰色列表策略。这将处理客户机的重试在第一个4yz回复后转到其他服务器的序列，并允许所有服务器共享成功重试的主机列表。
5. To accommodate those senders that have clusters of outgoing mail servers, greylisting servers MAY track CIDR blocks of a size of its own choosing, such as /24, rather than the full IPv4 address. (Note, however, that this heuristic will not work for clusters having machines on different networks.) A similar grouping capability MAY be established based on the domain name of the mail server if one can be determined.
5. 为了适应那些拥有传出邮件服务器集群的发件人，greylisting服务器可以跟踪其自己选择大小的CIDR块，例如/24，而不是完整的IPv4地址。（但是，请注意，这种启发式方法不适用于在不同网络上有机器的集群。）如果可以确定，可以基于邮件服务器的域名建立类似的分组能力。
6. Include a manual override capability for adding specific IP addresses or network blocks that always bypass checks. There are legitimate senders that simply don't respond well to greylisting for a variety of reasons, most of which do not conflict with [SMTP]. There are also some highly visible online entities such as email service providers that will be certain to retry; thus, those that are known SHOULD be allowed to bypass the filter.
6. 包括手动覆盖功能，用于添加始终绕过检查的特定IP地址或网络块。有一些合法的发件人由于各种原因对greylisting响应不好，其中大多数与[SMTP]不冲突。还有一些高度可见的在线实体，如电子邮件服务提供商，他们肯定会重试；因此，应允许已知的过滤器旁通。
7. Greylisting SHOULD NOT be applied by an ADMD's submission service (see [SUBMISSION]) for authenticated client hosts. It also SHOULD not be applied against any authenticated ADMD session. Authentication can include whatever mechanisms are deemed appropriate for the ADMD, such as known internal IP addresses, protocol-level client authentication, or the like.
7. ADMD的提交服务（请参阅[submission]）不应为经过身份验证的客户端主机应用灰色列表。它也不应应用于任何经过身份验证的ADMD会话。认证可以包括被认为适合于ADMD的任何机制，例如已知的内部IP地址、协议级客户端认证等。
There is no specific recommendation as to the specific choice of 4yz code to be returned as a result of a greylisting delay. Per [SMTP], however, the only two reasonable choices are 421 if the implementation wishes to terminate the connection immediately and 450 otherwise. It is possible that some clients treat different 4yz codes differently, but no data is available on whether using 421 versus some other 4yz code is particularly advantageous.
对于由于灰色列表延迟而返回的4yz代码的具体选择，没有具体的建议。但是，根据[SMTP]，如果实现希望立即终止连接，则只有421个合理选择，否则为450个。一些客户可能会以不同的方式对待不同的4yz代码，但没有数据表明使用421与其他4yz代码相比是否特别有利。
There is also no specific recommendation as to the choice of text to include in the SMTP reply, if any. Some implementers argue that indicating that greylisting is in effect can give spamware a hint as to when to try again for successful delivery, while others suspect that it won't matter to spamware and thus the more likely audience is legitimate senders seeking to understand why their mail is being delayed.
对于选择SMTP回复中包含的文本（如果有），也没有具体建议。一些实现者认为，表明greylisting有效可以给spamware一个提示，告诉他们何时再次尝试成功交付，而其他人则怀疑这对spamware来说无关紧要，因此更可能的受众是那些试图了解邮件延迟原因的合法发件人。
A few techniques are common when measuring the effectiveness of greylisting in a particular installation:
在特定安装中测量灰色列表的有效性时，有几种常用技术：
o Arrange to log the spam versus legitimate determinations of messages and what the greylisting decision would have been if enabled; then determine whether there is a correlation (and, of course, whether too much legitimate email would also be affected).
o 安排记录垃圾邮件与合法邮件的确定，以及如果启用灰色列表决策，会是什么；然后确定是否存在相关性（当然，过多的合法电子邮件是否也会受到影响）。
o Continuing from the previous point, query the set of IP addresses subjected to greylisting in any popular [DNSBL] to see if there is a strong correlation.
o 从上一点继续，在任何流行的[DNSBL]中查询要进行灰色列表的IP地址集，以查看是否存在强相关性。
The descriptions and recommendations presented in this memo are based on many years of experience with greylisting in the IPv4 Internet environment, so they clearly pertain to IPv4 deployments only.
本备忘录中的描述和建议基于多年在IPv4 Internet环境中使用灰色列表的经验，因此它们显然只适用于IPv4部署。
The greater size of an IPv6 address seems likely to permit differences in behaviors by bad actors, and this could well mean needing to alter the details for applying greylisting; it might even negate any benefits in using greylisting at all. At a minimum, it is likely to call for different specific choices for any greylisting algorithm variables.
IPv6地址的更大尺寸似乎可能允许不良参与者的行为有所不同，这很可能意味着需要更改应用greylisting的细节；它甚至可能完全否定使用greylisting的任何好处。至少，它可能会为任何灰色列表算法变量调用不同的特定选择。
In addition, an obvious consideration is that the size of the database required to store records of all of the IP addresses seen will likely be substantially larger in the IPv6 environment.
此外，一个明显的考虑因素是，在IPv6环境中，存储所看到的所有IP地址的记录所需的数据库的大小可能会大得多。
This section discusses potential security issues related to greylisting.
本节讨论与灰色列表相关的潜在安全问题。
The discussion above highlights the fact that, although greylisting provides some obvious and valuable defenses, it can introduce unintentional and detrimental consequences for delivery of legitimate mail. Where timely delivery of email is essential, especially for financial, transactional, or security-related applications, the possible consequences of such systems need to be carefully considered.
上面的讨论强调了这样一个事实，即尽管greylisting提供了一些明显而有价值的防御措施，但它可能会对合法邮件的交付带来无意的有害后果。如果必须及时发送电子邮件，特别是对于金融、交易或安全相关应用程序，则需要仔细考虑此类系统可能产生的后果。
Specific sources can be exempted from greylisting, but, of course, that means they have elevated privilege in terms of access to the mailboxes on the greylisting system, and malefactors can seek to exploit this.
特定来源可以免于使用greylisting，但是，当然，这意味着他们在访问greylisting系统上的邮箱方面拥有更高的特权，而犯罪分子可以试图利用这一特权。
The database that has to be maintained as part of any greylisting system will grow as the diversity of its SMTP clients' hosts grows and, of course, is larger in general depending on the nature of the tuple stored about each delivery attempt. Even with a record aging policy in place, such a database could grow large enough to interfere
作为任何greylisting系统的一部分必须维护的数据库将随着其SMTP客户端主机的多样性的增长而增长，当然，通常更大，这取决于关于每次传递尝试存储的元组的性质。即使有了记录老化策略，这样的数据库也可能变得足够大，足以进行干扰
with the system hosting it, or at least to a point at which greylisting service is degraded. Moreover, an attacker knowing which greylisting scheme is in use could rotate parameters of SMTP clients under its control, in an attempt to inflate the database to the point of denial-of-service.
或者至少到了灰名单服务降级的程度。此外，知道正在使用哪个greylisting方案的攻击者可能会在其控制下旋转SMTP客户端的参数，试图将数据库膨胀到拒绝服务的程度。
Implementers could consider configuring an appropriate failure policy so that something locally acceptable happens when the database is attacked or otherwise unavailable.
实现者可以考虑配置适当的故障策略，以便当数据库受到攻击或不可用时，本地可接受的事件发生。
In practice, this has not appeared as a serious concern, because any reasonable aging policy successfully moderates database growth. It is nevertheless identified here as a consideration as there may be implementations in some environments where this is indeed an issue.
在实践中，这并不是一个严重的问题，因为任何合理的老化策略都能成功地减缓数据库的增长。尽管如此，这里还是将其确定为一个考虑因素，因为在某些环境中可能会有实现，而这确实是一个问题。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[EMAIL-ARCH]Crocker，D.，“互联网邮件体系结构”，RFC 55982009年7月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[SUBMISSION] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011.
[提交资料]Gellens，R.和J.Klensin，“邮件信息提交”，STD 72，RFC 6409，2011年11月。
[CIDR] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
[CIDR]Fuller，V.和T.Li，“无类域间路由（CIDR）：互联网地址分配和聚合计划”，BCP 122，RFC 4632，2006年8月。
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[DHCP]Droms，R.，“动态主机配置协议”，RFC 21311997年3月。
[DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[DNS]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[DNSBL] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, February 2010.
[DNSBL]Levine，J.，“DNS黑名单和白名单”，RFC 5782，2010年2月。
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[邮件]Resnick，P.，Ed.，“互联网信息格式”，RFC5322，2008年10月。
[NAT] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[NAT]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 30222001年1月。
[PUREMAGIC] Harris, E., "The Next Step in the Spam Control War: Greylisting", August 2003, <http://projects.puremagic.com/greylisting/ whitepaper.html>.
[PUREMAGIC]Harris，E.，“垃圾邮件控制战争的下一步：Greylisting”，2003年8月<http://projects.puremagic.com/greylisting/ 白皮书.html>。
[SAUCE] Jackson, I., "GNU SAUCE", 2001, <http://www.gnu.org/software/sauce>.
[酱汁]杰克逊，I.，“GNU酱汁”，2001年<http://www.gnu.org/software/sauce>.
The authors wish to acknowledge Mike Adkins, Steve Atkins, Mihai Costea, Derek Diget, Peter J. Holzer, John Levine, Chris Lewis, Jose-Marcio Martins da Cruz, John Klensin, S. Moonesamy, Suresh Ramasubramanian, Mark Risher, Jordan Rosenwald, Gregory Shapiro, Joe Sniderman, Roland Turner, and Michael Wise for their contributions to this memo. The various participants of the MAAWG Open Sessions about greylisting were also valued contributors.
作者希望感谢迈克·阿德金斯、史蒂夫·阿特金斯、米海·科斯蒂亚、德里克·迪吉特、彼得·霍尔泽、约翰·莱文、克里斯·刘易斯、何塞·马西奥·马丁斯·达克鲁兹、约翰·克莱辛、S·穆内萨米、苏雷什·拉马苏伯拉曼尼亚、马克·里舍、乔丹·罗森瓦尔德、格雷戈里·夏皮罗、乔·斯奈德曼、罗兰·特纳和迈克尔·怀斯对本备忘录的贡献。MAAWG关于greylisting的公开会议的各种参与者也是有价值的贡献者。
Authors' Addresses
作者地址
Murray S. Kucherawy Cloudmark 128 King St., 2nd Floor San Francisco, CA 94107 US
Murray S. Kucherawy CuldM标记128国王圣，第二楼旧金山，CA 94107美国
Phone: +1 415 946 3800
EMail: superuser@gmail.com
Phone: +1 415 946 3800
EMail: superuser@gmail.com
Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 USA
Dave Crocker Brandenburg互联网675 Spruce Dr.Sunnyvale，加利福尼亚州，美国94086
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
URI: http://bbiw.net
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
URI: http://bbiw.net