Network Working Group C. Malamud
Request for Comments: 3865 Memory Palace Press
Category: Standards Track September 2004
Network Working Group C. Malamud
Request for Comments: 3865 Memory Palace Press
Category: Standards Track September 2004
A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension
无请求简单邮件传输协议（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 document proposes an extension to Soliciting Simple Mail Transfer Protocol (SMTP) for an electronic mail equivalent to the real-world "No Soliciting" sign. In addition to the service extension, a new message header and extensions to the existing "received" message header are described.
本文档提出了对请求简单邮件传输协议（SMTP）的扩展，该协议适用于相当于真实世界“禁止请求”标志的电子邮件。除了服务扩展之外，还描述了新的消息头和对现有“已接收”消息头的扩展。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Spam Pandemic. . . . . . . . . . . . . . . . . . . . 3
1.2. No Soliciting in the Real World. . . . . . . . . . . . . 4
1.3. No Soliciting and Electronic Mail. . . . . . . . . . . . 5
2. The No-Soliciting SMTP Service Extension . . . . . . . . . . . 6
2.1. The EHLO Exchange. . . . . . . . . . . . . . . . . . . . 7
2.2. Solicitation Class Keywords. . . . . . . . . . . . . . . 7
2.2.1. Note on Choice of Solicitation Class Keywords. . 8
2.3. The MAIL FROM Command. . . . . . . . . . . . . . . . . . 9
2.4. Error Reporting and Enhanced Mail Status Codes . . . . . 10
2.5. Solicitation Mail Header . . . . . . . . . . . . . . . . 10
2.6. Insertion of Solicitation Keywords in Trace Fields . . . 11
2.7. Relay of Messages. . . . . . . . . . . . . . . . . . . . 12
2.8. No Default Solicitation Class. . . . . . . . . . . . . . 12
3. Security Considerations . . . . . . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
4.1. The Mail Parameters Registry . . . . . . . . . . . . . . 13
4.2. Trace Fields . . . . . . . . . . . . . . . . . . . . . . 14
4.3. The Solicitation Mail Header . . . . . . . . . . . . . . 14
5. Author's Acknowledgements . . . . . . . . . . . . . . . . . . 14
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Normative References . . . . . . . . . . . . . . . . . . 15
6.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Collected ABNF Descriptions (Normative) . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Spam Pandemic. . . . . . . . . . . . . . . . . . . . 3
1.2. No Soliciting in the Real World. . . . . . . . . . . . . 4
1.3. No Soliciting and Electronic Mail. . . . . . . . . . . . 5
2. The No-Soliciting SMTP Service Extension . . . . . . . . . . . 6
2.1. The EHLO Exchange. . . . . . . . . . . . . . . . . . . . 7
2.2. Solicitation Class Keywords. . . . . . . . . . . . . . . 7
2.2.1. Note on Choice of Solicitation Class Keywords. . 8
2.3. The MAIL FROM Command. . . . . . . . . . . . . . . . . . 9
2.4. Error Reporting and Enhanced Mail Status Codes . . . . . 10
2.5. Solicitation Mail Header . . . . . . . . . . . . . . . . 10
2.6. Insertion of Solicitation Keywords in Trace Fields . . . 11
2.7. Relay of Messages. . . . . . . . . . . . . . . . . . . . 12
2.8. No Default Solicitation Class. . . . . . . . . . . . . . 12
3. Security Considerations . . . . . . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
4.1. The Mail Parameters Registry . . . . . . . . . . . . . . 13
4.2. Trace Fields . . . . . . . . . . . . . . . . . . . . . . 14
4.3. The Solicitation Mail Header . . . . . . . . . . . . . . 14
5. Author's Acknowledgements . . . . . . . . . . . . . . . . . . 14
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Normative References . . . . . . . . . . . . . . . . . . 15
6.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Collected ABNF Descriptions (Normative) . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 19
Unsolicited Bulk Email (UBE), otherwise known as spam, has become as one of the most pressing issues on the Internet. One oft-quoted study estimated that spam would cost businesses $13 billion in 2003 [Ferris]. In April 2003, AOL reported that it had blocked 2.37 billion pieces of UBE in a single day [CNET]. And, in a sure sign that UBE has become of pressing concern, numerous politicians have begun to issue pronouncements and prescriptions for fighting this epidemic [Schumer][FTC].
未经请求的批量电子邮件（UBE），也称为垃圾邮件，已成为互联网上最紧迫的问题之一。一项经常被引用的研究估计，2003年垃圾邮件将使企业损失130亿美元[Ferris]。2003年4月，美国在线报告称，它在一天内就拦截了23.7亿块UBE[CNET]。而且，有一个明确的迹象表明，UBE已经成为一个紧迫的问题，许多政客已经开始发布公告和处方来对抗这一流行病[Schumer][FTC]。
A variety of mechanisms from the technical community have been proposed and/or implemented to fight UBE:
已经提出和/或实施了技术界的各种机制来应对：
o Whitelists are lists of known non-spammers. For example, Habeas, Inc. maintains a Habeas User List (HUL) of people who have agreed to not spam. By including a haiku in email headers and enforcing copyright on that ditty, they enforce their anti-spamming terms of service [Habeas].
o 白名单是已知非垃圾邮件发送者的名单。例如，Habeas，Inc.维护同意不发送垃圾邮件的人身保护用户列表（HUL）。通过在邮件标题中加入俳句，并对该小曲实施版权保护，他们实施了反垃圾邮件服务条款[人身保护]。
o Blacklists are lists of known spammers or ISPs that allow spam [ROKSO].
o 黑名单是允许垃圾邮件的已知垃圾邮件发送者或ISP的名单[ROKSO]。
o Spam filters run client-side or server-side to filter out spam based on whitelists, blacklists, and textual and header analysis [Assassin].
o 垃圾邮件过滤器运行客户端或服务器端，根据白名单、黑名单、文本和标题分析过滤垃圾邮件[刺客]。
o A large number of documents address the overall technical considerations for the control of UBE [crocker-spam-techconsider], operational considerations for SMTP agents [RFC2505], and various extensions to the protocols to support UBE identification and filtering [danisch-dns-rr-smtp][daboo-sieve-spamtest][crouzet-amtp].
o 大量文件阐述了UBE控制的总体技术考虑因素[crocker spam TechConcern]，SMTP代理的操作考虑因素[RFC2505]，以及支持UBE识别和过滤的各种协议扩展[danisch dns rr SMTP][daboo sieve spamtest][crouzet amtp]。
o Various proposals have been advanced for "do not spam" lists, akin to the Federal Trade Commission's "Do Not Call" list for telemarketers [FTC.TSR].
o 针对“禁止垃圾邮件”名单提出了各种各样的建议，类似于联邦贸易委员会的电话销售“禁止呼叫”名单[FTC.TSR]。
Terminology
术语
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
Municipalities frequently require solicitors to register with the town government. And, in many cases, the municipalities prohibit soliciting in residences where the occupant has posted a sign. The town of West Newbury, Massachusetts, for example, requires:
市政当局经常要求律师向市政府登记。而且，在许多情况下，市政当局禁止在居住者张贴标志的住宅中拉客。例如，马萨诸塞州西纽伯里镇需要：
"It shall be unlawful for any canvasser or solicitor to enter the premises of a resident or business who has displayed a 'No Trespassing' or 'No Soliciting' sign or poster. Further, it shall be unlawful for canvassers or solicitors to ignore a resident or business person's no solicitation directive or remain on private property after its owner has indicated that the canvasser or solicitor is not welcome" [Newbury].
“任何拉票人或律师进入展示“禁止侵入”或“禁止招揽”标志或海报的居民或企业的处所均属违法。此外，拉票人或律师无视居民或企业人士的“禁止招揽”指示，或在其所有人离开后留在私人财产上均属违法表示不欢迎拉票人或律师“[Newbury]。
Registration requirements for solicitors, particularly those soliciting for political or religious reasons, have been the subject of a long string of court cases. However, the courts have generally recognized that individuals may post "No Soliciting" signs and the government may enforce the citizen's desire. In a recent case where Jehovah's Witnesses challenged a registration requirement in the city of Stratton, Connecticut, saying they derived their authority from the Scriptures, not the city. However, the court noted:
律师的注册要求，特别是那些出于政治或宗教原因的律师，一直是一系列法庭案件的主题。然而，法院普遍承认，个人可以张贴“禁止拉客”标志，政府可以强制执行公民的愿望。在最近的一个案件中，耶和华见证人在康涅狄格州斯特拉顿市对登记要求提出质疑，称他们的权威来自圣经，而不是城市。然而，法院指出：
"A section of the ordinance that petitioners do not challenge establishes a procedure by which a resident may prohibit solicitation even by holders of permits. If the resident files a 'No Solicitation Registration Form' with the mayor, and also posts a 'No Solicitation' sign on his property, no uninvited canvassers may enter his property... " [Watchtower].
“该条例中请愿人不得质疑的一节规定了一个程序，居民可以通过该程序禁止拉客，即使是许可证持有人。如果居民向市长提交“禁止拉客登记表”，并在其财产上张贴“禁止拉客”标志，未经邀请的拉票者不得进入其财产……”[望塔]。
Even government, which has a duty to promote free expression, may restrict the use of soliciting on government property. In one case, for example, a school district was allowed to give access to its internal electronic mail system to the union that was representing teachers, but was not required to do so to a rival union that was attempting to gain the right to represent the teachers. The court held that where property is not a traditional public forum "and the Government has not dedicated its property to First Amendment activity, such regulation is examined only for reasonableness" [Perry].
即使是有义务促进言论自由的政府，也可能限制在政府财产上进行拉客。例如，在一个案例中，一个学区被允许让代表教师的工会访问其内部电子邮件系统，但不要求让试图获得代表教师权利的敌对工会访问其内部电子邮件系统。法院认为，如果财产不是传统的公共场所，“而且政府没有将其财产用于《第一修正案》的活动，则仅对此类法规的合理性进行审查”[Perry]。
The courts have consistently held that the state has a compelling public safety reason for regulating solicitation. In Cantwell v. Connecticut, the Supreme Court held that "a State may protect its citizens from fraudulent solicitation by requiring a stranger in the community, before permitting him publicly to solicit funds for any purpose, to establish his identity and his authority to act for the
法院一贯认为，国家有一个令人信服的公共安全理由来规范招标活动。在坎特威尔五世。康涅狄格州最高法院认为，“一个州可以通过要求社区中的陌生人在公开允许他为任何目的筹集资金之前，确定他的身份和他为该州采取行动的权力，来保护其公民不受欺诈性招揽。”
cause which he purports to represent" [Cantwell]. And, in Martin v. City of Struthers, the court noted that "burglars frequently pose as canvassers, either in order that they may have a pretense to discover whether a house is empty and hence ripe for burglary, or for the purpose of spying out the premises in order that they may return later" [Martin]. The public safety issue applies very much to email, where viruses can easily be delivered, in contrast to telephone solicitations where public safety is not nearly as much an issue.
他声称代表的原因“[Cantwell]。在Martin诉Struthers市一案中，法院指出，“窃贼经常假扮成拉票人，要么是为了他们可能有借口发现一所房子是否空无一人，因此适合入室行窃，要么是为了监视该房屋，以便他们稍后返回。”[马丁]。公共安全问题在很大程度上适用于电子邮件，在电子邮件中病毒很容易传播，而在电话征集中，公共安全问题几乎没有那么重要。
This analysis is U.S.-centric, which is partly due to the background of the author. However, the concept of prohibiting unwanted solicitation does carry over to other countries:
这一分析以美国为中心，部分原因在于作者的背景。然而，禁止不必要的招揽的概念确实传到了其他国家：
o In Hong Kong, offices frequently post "no soliciting" signs.
o 在香港，办公室经常张贴“请勿招呼”的招牌。
o In the United Kingdom, where door-to-door peddlers are fairly common, "no soliciting" signs are also common.
o 在英国，挨家挨户叫卖的小贩相当普遍，“禁止拉客”标志也很常见。
o In Australia, where door-to-door does not appear to be a pressing social problem, there was legislation passed which outlawed the practice of placing ads under wipers of parked cars.
o 在澳大利亚，挨家挨户似乎不是一个紧迫的社会问题，通过了一项立法，禁止在停放的汽车的刮水器下放置广告。
o In France, which has a long tradition of door-to-door solicitation, apartment buildings often use trespass laws to enforce "no solicitation" policies.
o 在有着长期挨家挨户拉客传统的法国，公寓楼经常使用侵入法来执行“禁止拉客”政策。
o In the Netherlands, where door-to-door solicitation is not a pressing issue, there is a practice of depositing free publications in mailboxes. The postal equivalent of "no spam" signs are quite prevalent and serve notice that the publications are not desired.
o 在荷兰，上门征集不是一个紧迫的问题，有一种将免费出版物存入邮箱的做法。相当于“禁止垃圾邮件”的邮政标志相当普遍，并提醒人们不要出版这些出版物。
Many of the anti-spam proposals that have been advanced have great merit, however none of them give notice to an SMTP agent in the process of delivering mail that the receiver does not wish to receive solicitations. Such a virtual sign would serve two purposes:
许多已经提出的反垃圾邮件建议都有很大的优点，但是没有一个建议在发送邮件的过程中通知SMTP代理收件人不希望收到邀请。这种虚拟标志有两个用途：
o It would allow the receiving system to "serve notice" that a certain class of electronic mail is not desired.
o 它将允许接收系统“发出通知”，表明不需要某类电子邮件。
o If a message is properly identified as belonging to a certain class and that class of messages is not desired, transfer of the message can be eliminated. Rather than filtering after delivery, elimination of the message transfer can save network bandwidth, disk space, and processing power.
o 如果消息被正确地标识为属于某个类别，并且不需要该类别的消息，则可以消除该消息的传输。而不是在传递后过滤，消除消息传输可以节省网络带宽、磁盘空间和处理能力。
This memo details a series of extensions to SMTP that have the following characteristics:
此备忘录详细介绍了SMTP的一系列扩展，这些扩展具有以下特征：
o A service extension is described that allows a receiving Mail Transport Agent (MTA) to signal the sending MTA that no soliciting is in effect.
o 描述了一种服务扩展，该扩展允许接收邮件传输代理（MTA）向发送MTA发出信号，表明没有有效的请求。
o A header field for the sender of the message is defined that allows the sender to flag a message as conforming to a certain class.
o 定义了消息发送方的头字段，允许发送方将消息标记为符合某个类。
o Trace fields for intermediate MTAs are extended to allow the intermediate MTA to signal that a message is in a certain class.
o 中间MTA的跟踪字段被扩展，以允许中间MTA发出消息在某个类中的信号。
Allowing the sender of a message to tag a message as being, for example, unsolicited commercial email with adult content, allows "good" spammers to conform to legal content labelling requirements by governmental authorities, license agreements with service providers, or conventions imposed by "whitelist" services. For senders of mail who choose not to abide by these conventions, the intermediate trace fields defined here allow the destination MTAs to perform appropriate dispositions on the received message.
允许消息发送者将消息标记为（例如）含有成人内容的未经请求的商业电子邮件，允许“优秀”垃圾邮件发送者遵守政府当局的合法内容标签要求、与服务提供商的许可协议或“白名单”服务强加的约定。对于选择不遵守这些约定的邮件发件人，此处定义的中间跟踪字段允许目标MTA对收到的邮件执行适当的处理。
This extension provides a simple mean for senders, MTAs, and receivers to assert keywords. This extension does not deal with any issues of authentication or consent.
此扩展为发件人、MTA和收件人提供了一个简单的方法来断言关键字。此扩展不涉及任何身份验证或同意问题。
Per [RFC2821], a "NO-SOLICITING" SMTP service extension is defined. The service extension is declared during the initial "EHLO" SMTP exchange. The extension has one optional parameter, consisting of zero or more solicitation class keywords. Using the notation as described in the Augmented BNF [RFC2234], the syntax is:
根据[RFC2821]，定义了“无请求”SMTP服务扩展。服务扩展在初始“EHLO”SMTP交换期间声明。扩展名有一个可选参数，由零个或多个请求类关键字组成。使用增广BNF[RFC2234]中描述的符号，语法为：
No-Soliciting-Service = "NO-SOLICITING" [ SP Solicitation-keywords ]
无邀约服务=“无邀约”[SP邀约关键字]
As will be further described below, the "Solicitation-keywords" construct is used to indicate which classes of messages are not desired. A keyword that is presented during the initial "EHLO" exchange applies to all messages exchanged in this session. As will also be further described below, additional keywords may be specified on a per-recipient basis as part of the response to a "RCPT TO" command.
如下文将进一步描述的，“请求关键字”构造用于指示不需要哪类消息。在初始“EHLO”交换期间显示的关键字适用于此会话中交换的所有消息。如下文还将进一步描述的，作为对“RCPT to”命令的响应的一部分，可以在每个接收者的基础上指定附加关键字。
Keywords presented during the initial exchange indicate that no soliciting in the named classes is in effect for all messages delivered to this system. It is equivalent to the sign on the door of an office building announcing a company-wide policy. For example:
在初始交换期间显示的关键字表明，对于传递到此系统的所有消息，命名类中没有有效的请求。这相当于办公大楼门上的标志，宣布了一项公司范围内的政策。例如：
R: <wait for connection on TCP port 25>
S: <open connection to server>
R: 220 trusted.example.com SMTP service ready
S: EHLO untrusted.example.com
R: 250-trusted.example.com says hello
R: 250-ENHANCEDSTATUSCODES
R: 250-NO-SOLICITING net.example:ADV
R: 250 SIZE 20480000
R: <wait for connection on TCP port 25>
S: <open connection to server>
R: 220 trusted.example.com SMTP service ready
S: EHLO untrusted.example.com
R: 250-trusted.example.com says hello
R: 250-ENHANCEDSTATUSCODES
R: 250-NO-SOLICITING net.example:ADV
R: 250 SIZE 20480000
The "net.example:ADV" parameter to the "NO-SOLICITING" extension is an example of a solicitation class keyword, the syntax of which is described in the following section.
“NO-requicing”扩展名的“net.example:ADV”参数是请求类关键字的一个示例，其语法将在下一节中描述。
Historical Note:
历史注释：
A similar proposal was advanced in 1999 by John Levine and Paul Hoffman. This proposal used the SMTP greeting banner to specify that unsolicited bulk email is prohibited on a particular system through the use of the "NO UCE" keyword [Levine]. As the authors note, their proposal has the potential of overloading the semantics of the greeting banner, which may also be used for other purposes (see, e.g., [Malamud]).
约翰·莱文和保罗·霍夫曼在1999年提出了类似的建议。该提案使用SMTP问候横幅，通过使用“无UCE”关键字[Levine]，规定禁止在特定系统上发送未经请求的批量电子邮件。正如作者所指出的，他们的建议可能会使问候语横幅的语义过载，这也可能用于其他目的（例如，参见[Malamud]）。
The "NO-SOLICITING" service extension uses solicitation class keywords to signify classes of solicitations that are not accepted. Solicitation class keywords are separated by commas.
“禁止招揽”服务扩展使用招揽类关键字表示未接受的招揽类。请求类关键字用逗号分隔。
There is no default solicitation class keyword for the service. In other words, the following example is a "no-op":
服务没有默认的请求类关键字。换句话说，以下示例是“无操作”：
R : 250-NO-SOLICITING
R:250-禁止拉客
While the above example is a "no-op" it is useful for an MTA that wishes to pass along all messages, but would also like to pass along "SOLICIT=" parameters on a message-by-message basis. The above example invokes the use of the extension but does not signal any restrictions by class of message.
虽然上面的示例是“无操作”，但对于希望传递所有消息，但也希望逐个消息传递“request=”参数的MTA来说，它很有用。上面的示例调用了扩展的使用，但没有按消息类发出任何限制信号。
The initial set of solicitation class keywords all begin with a domain name with the labels reversed, followed by a colon. For example, the domain name "example.com" could be used to form the beginning of a solicitation class keyword of "com.example:". The solicitation class keyword is then followed by an arbitrary set of characters drawn from the following construct:
最初的一组请求类关键字都以域名开头，标签颠倒，后跟冒号。例如，域名“example.com”可用于构成“com.example:”的征求类关键字的开头。然后，请求类关键字后跟从以下构造中提取的任意字符集：
Solicitation-keywords = word
0*("," word)
; length of this string is limited
; to <= 1000 characters
word = ALPHA 0*(wordchar)
wordchar = ("." / "-" / "_" / ":" / ALPHA / DIGIT)
Solicitation-keywords = word
0*("," word)
; length of this string is limited
; to <= 1000 characters
word = ALPHA 0*(wordchar)
wordchar = ("." / "-" / "_" / ":" / ALPHA / DIGIT)
A solicitation class keyword MUST be less than 1000 characters. Note however that a set of keywords used in the operations defined in this document must also be less than 1000 characters. Implementors are thus advised to keep their solicitation class keywords brief.
请求类关键字必须少于1000个字符。但是请注意，本文档中定义的操作中使用的一组关键字也必须少于1000个字符。因此，建议实现者保持其请求类关键字的简短。
Any registrant of a domain name may define a solicitation class keyword. Discovery of solicitation class keywords is outside the scope of this document. However, those registrants defining keywords are advised to place a definition of their solicitation class keywords on a prominent URL under their control such that search engines and other discovery mechanisms can find them.
域名的任何注册人都可以定义一个征求类关键字。请求类关键字的发现不在本文档的范围内。但是，建议定义关键词的注册人将其邀请类关键词的定义放在其控制下的突出URL上，以便搜索引擎和其他发现机制可以找到它们。
While this document defines solicitation class keywords as beginning with a reversed domain name followed by a colon (":"), future RFCs may define additional mechanisms that do not conflict with this naming scheme.
虽然本文档将请求类关键字定义为以反向域名开头，后跟冒号（“：”），但未来的RFC可能会定义与此命名方案不冲突的其他机制。
This document does not specify which solicitation class keywords shall or shall not be used on a particular message. The requirement to use a particular keyword is a policy decision well outside the scope of this document. It is expected that relevant policy bodies (e.g., governments, ISPs, developers, or others) will specify appropriate keywords, the definition of the meaning of those keywords, and any other policy requirements, such as a requirement to use or not use this extension in particular circumstances.
本文件未规定在特定报文上应使用或不应使用哪种征求类关键字。使用特定关键字的要求是一项政策决策，远远超出了本文件的范围。预计相关政策机构（如政府、ISP、开发商或其他机构）将指定适当的关键字、这些关键字含义的定义以及任何其他政策要求，例如在特定情况下使用或不使用此扩展的要求。
During discussions of this proposal, there were several suggestions to do away with the solicitation class keywords altogether and replace the mechanism with a simple boolean (e.g., "NO-SOLICITING YES" or "ADV" or "UBE"). Under a boolean mechanism, this extension would have to adopt a single definition of what "YES" or other label
在讨论该提案的过程中，有几项建议建议完全取消征求类关键字，并用简单的布尔值替换该机制（例如，“不征求是”或“ADV”或“UBE”）。在布尔机制下，此扩展必须采用“是”或其他标签的单一定义
means. By using the solicitation class keywords approach, the mail infrastructure remains a neutral mechanism, allowing different definitions to co-exist.
方法通过使用请求类关键字方法，邮件基础设施仍然是一种中立的机制，允许不同的定义共存。
"SOLICIT" is defined as a parameter for the "MAIL FROM" command. The "SOLICIT" parameter is followed by an equal sign and a comma separated list of solicitation class keywords. The syntax for this parameter is:
“请求”被定义为“邮件发件人”命令的参数。“请求”参数后面是等号和逗号分隔的请求类关键字列表。此参数的语法为：
Mail-From-Solicit-Parameter = "SOLICIT" "=" Solicitation-keywords ; Solicitation-keywords, when used in MAIL FROM command ; MUST be identical to those in the Solicitation: header.
来自请求的邮件参数=“请求”“=”请求关键字；请求关键字，当用于来自命令的邮件时；必须与邀约：标题中的内容相同。
Note that white space is not permitted in this production.
请注意，此产品中不允许使用空白。
As an informational message, the "550" or "250" replies to the "RCPT TO" command may also contain the "SOLICIT" parameter. If a message is being rejected due to a solicitation class keyword match, implementations SHOULD echo which solicitation classes are in effect. See Section 2.4 for more on error reporting.
作为信息性消息，对“RCPT to”命令的“550”或“250”回复也可能包含“request”参数。如果消息由于请求类关键字匹配而被拒绝，则实现应回显有效的请求类。有关错误报告的更多信息，请参见第2.4节。
The receiving system may decide on a per-message basis the appropriate disposition of messages:
接收系统可根据每条消息决定消息的适当处理：
R: <wait for connection on TCP port 25>
S: <open connection to server>
R: 220 trusted.example.com SMTP service ready
S: EHLO untrusted.example.com
R: 250-trusted.example.com says hello
R: 250-NO-SOLICITING net.example:ADV
S: MAIL FROM:<save@example.com> SOLICIT=org.example:ADV:ADLT
S: RCPT TO:<coupon_clipper@moonlink.example.com>
R: 250 <coupon_clipper@moonlink.example.com>... Recipient ok
S: RCPT TO:<grumpy_old_boy@example.net>
R: 550 <grumpy_old_boy@example.net> SOLICIT=org.example:ADV:ADLT
R: <wait for connection on TCP port 25>
S: <open connection to server>
R: 220 trusted.example.com SMTP service ready
S: EHLO untrusted.example.com
R: 250-trusted.example.com says hello
R: 250-NO-SOLICITING net.example:ADV
S: MAIL FROM:<save@example.com> SOLICIT=org.example:ADV:ADLT
S: RCPT TO:<coupon_clipper@moonlink.example.com>
R: 250 <coupon_clipper@moonlink.example.com>... Recipient ok
S: RCPT TO:<grumpy_old_boy@example.net>
R: 550 <grumpy_old_boy@example.net> SOLICIT=org.example:ADV:ADLT
In the previous example, the receiving MTA returned a "550" status code, indicating that one message was being rejected. The implementation also echoes back the currently set keywords for that user on the "550" status message. The solicitation class keyword which is echoed back is "org.example:ADV:ADLT" which illustrates how this per-recipient solicitation class keyword has supplemented the base "net.example:ADV" class declared in the "EHLO" exchange.
在上一个示例中，接收MTA返回“550”状态代码，表示有一封邮件被拒绝。该实现还回显“550”状态消息中当前为该用户设置的关键字。回显的请求类关键字是“org.example:ADV:ADLT”，它说明了每个收件人请求类关键字是如何补充在“EHLO”交换中声明的基本“net.example:ADV”类的。
It is the responsibility of a receiving MTA to maintain a consistent policy. If the receiving MTA will reject a message because of solicitation class keywords, the MTA SHOULD declare those keywords either in the initial "EHLO" exchange or on a per-recipient basis. Likewise, a receiving MTA SHOULD NOT deliver a message where the "Solicitation:" matches a solicitation class keyword that was presented during the initial "EHLO" exchange or on a per-recipient basis.
接收MTA有责任维护一致的政策。如果接收MTA因请求类关键字而拒绝邮件，MTA应在初始“EHLO”交换中或按每个收件人声明这些关键字。同样，接收MTA不应在“请求：”与初始“EHLO”交换期间或每个收件人提供的请求类关键字匹配的情况下发送邮件。
Developers should also note that the source of the solicitation class keywords used in the "MAIL FROM" command MUST be the "Solicitation:" header described in Section 2.5 and MUST NOT be supplemented by additional solicitation class keywords derived from the "Received:" header trace fields which are described in Section 2.6.
开发人员还应注意，“邮件发件人”命令中使用的请求类关键字的来源必须是第2.5节中描述的“请求：”标题，并且不得由第2.6节中描述的“已接收：”标题跟踪字段派生的其他请求类关键字进行补充。
If a session between two MTAs is using both the "NO-SOLICITING" extension and the Enhanced Mail Status Codes as defined in [RFC3463] and a message is rejected based on the presence of a "SOLICIT" parameter, the correct error message to return will usually be "5.7.1", defined as "the sender is not authorized to send to the destination... (because) of per-host or per-recipient filtering."
如果两个MTA之间的会话同时使用“禁止请求”扩展名和[RFC3463]中定义的增强邮件状态代码，并且由于存在“请求”参数而拒绝邮件，则返回的正确错误消息通常为“5.7.1”，定义为“发件人无权发送到目的地…”（因为）每个主机或每个收件人的筛选。“
Other codes, including temporary status codes, may be more appropriate in some circumstances and developers should look to [RFC3463] on this subject. An example of such a situation might be the use of quotas or size restrictions on messages by class. An implementation MAY impose limits such as message size restrictions based on solicitation classes, and when such limits are exceed they SHOULD be reported using whatever status code is appropriate for that limit.
在某些情况下，其他代码（包括临时状态代码）可能更合适，开发人员应参考[RFC3463]中的相关内容。这种情况的一个例子可能是按类对消息使用配额或大小限制。实现可能会施加限制，例如基于请求类的消息大小限制，当超过此类限制时，应使用适合该限制的任何状态代码进行报告。
In all cases, an implementation SHOULD include a "Mail-From-Solicit-Parameter" on a "550" or other reply that rejects message delivery. The parameter SHOULD includes the solicitation class keyword(s) that matched. In addition to the solicitation class keyword(s) that matched, an implementation MAY include additional solicitation class keywords that are in effect.
在所有情况下，实现都应该在“550”或拒绝消息传递的其他回复上包含“来自请求的邮件”参数。参数应包括匹配的请求类关键字。除了匹配的请求类关键字外，实现还可以包括有效的其他请求类关键字。
Per [RFC2822], a new "Solicitation:" header field is defined which contains one or more solicitation class keywords.
根据[RFC2822]，定义了一个新的“请求：”标题字段，其中包含一个或多个请求类关键字。
Solicitation-header = "Solicitation:" 1*SP Solicitation-keywords
Solicitation-header = "Solicitation:" 1*SP Solicitation-keywords
An example of this header follows:
此标题的示例如下所示：
To: Coupon Clipper <coupon_clipper@moonlink.example.com>
From: Spam King <save@burntmail.example.com>
Solicitation: net.example:ADV,org.example:ADV:ADLT
To: Coupon Clipper <coupon_clipper@moonlink.example.com>
From: Spam King <save@burntmail.example.com>
Solicitation: net.example:ADV,org.example:ADV:ADLT
Several proposals, particularly legal ones, have suggested requiring the use of keywords in the "Subject:" header. While embedding information in the "Subject:" header may provide visual cues to end users, it does not provide a straightforward set of cues for computer programs such as mail transfer agents. As with embedding a "no solicitation" message in a greeting banner, this overloads the semantics of the "Subject:" header. Of course, there is no reason why both mechanisms can't be used, and in any case the "Solicitation:" header could be automatically inserted by the sender's Mail User Agent (MUA) based on the contents of the subject line.
一些提案，特别是法律提案，建议在“主题：”标题中使用关键词。虽然在“主题：”标题中嵌入信息可以为最终用户提供视觉提示，但它不能为计算机程序（如邮件传输代理）提供一组简单的提示。与在问候横幅中嵌入“禁止邀请”消息一样，这会使“主题：”标题的语义过载。当然，没有理由不能使用这两种机制，而且在任何情况下，“请求：”标题都可以由发件人的邮件用户代理（MUA）根据主题行的内容自动插入。
The "Solicitation:" mail header is only available to the sending client. RFCs 2821 and 2822 are quite specific that intermediate MTAs shall not change message headers, with the sole exception of the "Received:" trace field. Since many current systems use an intermediate relay to detect unsolicited mail, an addition to the "Received:" header is described.
“请求：”邮件头仅对发送客户端可用。RFC 2821和2822非常明确，中间MTA不得更改消息头，唯一的例外是“Received:”跟踪字段。由于许多当前系统使用中间中继来检测未经请求的邮件，因此描述了对“Received:”标头的添加。
[RFC2821] documents the following productions for the "Received:" header in a mail message:
[RFC2821]为邮件消息中的“Received:”标题记录以下产品：
; From RFC 2821
With = "WITH" FWS Protocol CFWS
Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
; From RFC 2821
With = "WITH" FWS Protocol CFWS
Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
Additionally, [RFC2822] defines a comment field as follows:
此外，[RFC2822]定义注释字段如下：
; From RFC 2822
comment = "(" *([FWS] ccontent) [FWS] ")"
ccontent = ctext / quoted-pair / comment
; From RFC 2822
comment = "(" *([FWS] ccontent) [FWS] ")"
ccontent = ctext / quoted-pair / comment
The "Mail-From-Solicit-Parameter" defined in Section 2.3 above is a restricted form of ctext, yielding the following production:
上文第2.3节中定义的“来自请求的邮件参数”是ctext的限制形式，产生以下结果：
With-Solicit = "WITH" FWS Protocol
"(" [FWS] comment [FWS] ")"
comment = "(" *([FWS] ccontent) [FWS] ")"
ccontent = ctext / quoted-pair /
comment / Mail-From-Solicit-Parameter
With-Solicit = "WITH" FWS Protocol
"(" [FWS] comment [FWS] ")"
comment = "(" *([FWS] ccontent) [FWS] ")"
ccontent = ctext / quoted-pair /
comment / Mail-From-Solicit-Parameter
; The Mail-From-Solicit-Parameter ; is a restricted form of ctext
; 来自请求的邮件参数；是ctext的限制形式
An example of a Received: header from a conforming MTA is as follows:
从符合条件的MTA收到的：标头示例如下：
Received: by foo-mta.example.com with
ESMTP (SOLICIT=net.example:ADV,org.example:ADV:ADLT) ;
Sat, 9 Aug 2003 16:54:42 -0700 (PDT)
Received: by foo-mta.example.com with
ESMTP (SOLICIT=net.example:ADV,org.example:ADV:ADLT) ;
Sat, 9 Aug 2003 16:54:42 -0700 (PDT)
It should be noted that keywords presented in trace fields may not agree with those found in the "Solicitation:" header and trace fields may exist even if the header is not present. When determining which keywords are applicable to a particular exchange of messages, implementors SHOULD examine any keywords found in the "Solicitation:" header. Implementors MAY examine other keywords found in the trace fields.
应注意，跟踪字段中显示的关键字可能与“请求：”标题中的关键字不一致，即使标题不存在，跟踪字段也可能存在。在确定哪些关键字适用于特定的消息交换时，实现者应该检查在“请求：”标题中找到的任何关键字。实现者可以检查跟踪字段中的其他关键字。
The "NO-SOLICITING" service extension, if present, applies to all messages handled by the receiving Message Transfer Agent (MTA), including those messages intended to be relayed to another system.
“禁止请求”服务扩展（如果存在）适用于接收邮件传输代理（MTA）处理的所有邮件，包括打算中继到其他系统的邮件。
Solicitation class keywords supplied by a client on a "SOLICIT" parameter on a "MAIL FROM" command SHOULD be obtained from the "Solicitation:" field in the message header. An SMTP client SHOULD, however, verify that the list of solicitation class keywords obtained from the "Solicitation:" field uses valid syntax before conveying its contents. An SMTP server SHOULD set this parameter after detecting the presence of the "Solicitation:" header field when receiving a message from a non-conforming MTA.
客户机在“邮件发件人”命令的“请求”参数上提供的请求类关键字应从消息头的“请求：”字段中获取。但是，SMTP客户端在传递其内容之前，应验证从“征求：”字段获取的征求类关键字列表是否使用了有效的语法。SMTP服务器在接收来自不一致MTA的邮件时，应在检测到“请求：”标题字段存在后设置此参数。
Implementations of "NO-SOLICITING" service extension SHOULD NOT enable specific solicitation class keywords as a default in their software. There are some indications that some policy makers may view a default filtering in software as a prior restraint on commercial speech. In other words, because the person installing and using the software did not make an explicit choice to enable a certain type of filtering, some might argue that such filtering was not desired.
“无请求”服务扩展的实现不应在其软件中默认启用特定请求类关键字。有一些迹象表明，一些政策制定者可能将软件中的默认过滤视为对商业言论的优先限制。换句话说，因为安装和使用软件的人没有明确选择启用某种类型的过滤，有些人可能会认为不需要这种过滤。
Likewise, it is recommended that a system administrator installing software SHOULD NOT enable additional per-recipient filtering by default for a user. Again, individual users should specifically request any additional solicitation class keywords.
同样，建议安装软件的系统管理员在默认情况下不要为用户启用额外的每个收件人筛选。同样，个人用户应该特别要求任何额外的征求类关键字。
The mechanism for an individual user to communicate their desire to enable certain types of filtering is outside the scope of this document.
单个用户传达其启用某些类型过滤的愿望的机制不在本文档的范围内。
This extension does not provide authentication of senders or other measures intended to promote security measures during the message exchange process.
此扩展不提供发件人身份验证或其他旨在促进邮件交换过程中安全措施的措施。
In particular, this document does not address the circumstances under which a sender of electronic mail should or should not use this extension and does not address the issues of whether consent to send mail has been granted.
特别是，本文件未涉及电子邮件发件人应使用或不应使用此扩展的情况，也未涉及是否同意发送邮件的问题。
This might lead to a scenario in which a sender of electronic mail begins to use this extension well before the majority of end users have begun to use it. In this scenario, the sender might wish to use the absence of the extension on the receiving MTA as an implication of consent to receive mail. Non-use of the "NO-SOLICITING" extension by a receiving MTA SHALL NOT indicate consent.
这可能会导致这样一种情况，即电子邮件发件人在大多数最终用户开始使用此扩展之前就开始使用它。在这种情况下，发件人可能希望将接收MTA上没有扩展名作为同意接收邮件的暗示。接收MTA未使用“禁止拉客”延期不得表示同意。
There are three IANA considerations presented in this document:
本文件中介绍了三个IANA注意事项：
1. Addition of the "NO-SOLICITING" service extension to the Mail Parameters registry.
1. 将“禁止索取”服务扩展添加到邮件参数注册表。
2. Documentation of the use of comments in trace fields.
2. 在跟踪字段中使用注释的文档。
3. Creation of a "Solicitation:" mail header.
3. 创建“邀请：”邮件头。
The IANA Mail Parameters registry documents SMTP service extensions. The "NO-SOLICITATION" service extension has been added to this registry as follows.
IANA邮件参数注册表记录SMTP服务扩展。“禁止邀约”服务扩展已添加到此注册表，如下所示。
Keywords Description Reference
------------ ------------------------------ ---------
NO-SOLICITING Notification of no soliciting. RFC3865
Keywords Description Reference
------------ ------------------------------ ---------
NO-SOLICITING Notification of no soliciting. RFC3865
The parameters subregistry would need to be modified as follows:
子区域的参数需要修改如下：
Service Ext EHLO Keyword Parameters Reference
----------- ------------ ----------- ---------
No Soliciting NO-SOLICITING Solicitation-keywords RFC3865
Service Ext EHLO Keyword Parameters Reference
----------- ------------ ----------- ---------
No Soliciting NO-SOLICITING Solicitation-keywords RFC3865
The maximum length of Solicitation-keywords is 1000 characters. The "SOLICIT=" parameter is defined for use on the MAIL FROM command. The potential length of the MAIL FROM command is thus increased by 1007 characters.
请求关键字的最大长度为1000个字符。“request=”参数定义用于“邮件发件人”命令。因此，MAIL FROM命令的潜在长度增加了1007个字符。
The Mail Parameters registry would need to be modified to note the use of the comment facility in trace fields to indicate Solicitation Class Keywords.
邮件参数注册表需要修改，以注意跟踪字段中注释功能的使用，以指示请求类关键字。
Per [RFC3864], the "Solicitation:" header field is added to the IANA Permanent Message Header Field Registry. The following is the registration template:
根据[RFC3864]，将“请求：”标题字段添加到IANA永久消息标题字段注册表中。以下是注册模板：
o Header field name: Solicitation o Applicable protocol: mail o Status: standard o Author/Change controller: IETF o Specification document(s): RFC3865 o Related information:
o 标题字段名称：征求o适用协议：邮件o状态：标准o作者/变更控制者：IETF o规范文件：RFC3865 o相关信息：
The author would like to thank Rebecca Malamud for many discussions and ideas that led to this proposal and to John C. Klensin and Marshall T. Rose for their extensive input on how it could be properly implemented in SMTP. Eric Allman, Harald Alvestrand, Steven M. Bellovin, Doug Barton, Kent Crispin, Dave Crocker, Ned Freed, Curtis Generous, Arnt Gulbrandsen, John Levine, Keith Moore, Hector Santos, Ted Hardie, Paul Vixie, and Pindar Wong kindly provided reviews of the document and/or suggestions for improvement. Information about soliciting outside the U.S. was received from Rob Blokzijl, Jon Crowcroft, Christian Huitema, Geoff Huston, and Pindar Wong. John Levine pointed out the contrast between this proposal and "do not spam" lists. As always, all errors and omissions are the responsibility of the author.
作者要感谢丽贝卡·马拉默德（Rebecca Malamud）的许多讨论和想法，这些讨论和想法导致了这项提案，并感谢约翰·C·克伦辛（John C.Klensin）和马歇尔·T·罗斯（Marshall T.Rose）就如何在SMTP中正确实施这项提案所作的广泛投入。Eric Allman、Harald Alvestrand、Steven M.Bellovin、Doug Barton、Kent Crispin、Dave Crocker、Ned Freed、Curtis大方、Arnt Gulbrandsen、John Levine、Keith Moore、Hector Santos、Ted Hardie、Paul Vixie和Pindar Wong善意地提供了对文件的审查和/或改进建议。Rob Blokzijl、Jon Crowcroft、Christian Huitema、Geoff Huston和Pindar Wong提供了有关在美国境外拉客的信息。约翰·莱文（John Levine）指出了这一建议与“禁止垃圾邮件”列表之间的对比。一如既往，所有错误和遗漏均由作者负责。
[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月。
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]Klensin，J.，Ed.，“简单邮件传输协议”，RFC 28212001年4月。
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]Resnick，P.，Ed.，“互联网信息格式”，RFC 2822，2001年4月。
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[RFC3463]Vaudreuil，G.，“增强邮件系统状态代码”，RFC 3463，2003年1月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月。
[Assassin] Mason, J., "Spamassassin - Mail Filter to Identify Spam
Using Text Analysis", Version 2.55, May 2003,
<http://www.mirror.ac.uk/sites/spamassassin.taint.org/
spamassassin.org/doc/spamassassin.html>
[Assassin] Mason, J., "Spamassassin - Mail Filter to Identify Spam
Using Text Analysis", Version 2.55, May 2003,
<http://www.mirror.ac.uk/sites/spamassassin.taint.org/
spamassassin.org/doc/spamassassin.html>
[CNET] CNET News.Com, "AOL touts spam-fighting prowess", April 2003, <http://news.com.com/2100-1025-998944.html>.
[CNET]CNET News.Com，“美国在线鼓吹打击垃圾邮件的威力”，2003年4月<http://news.com.com/2100-1025-998944.html>.
[Cantwell] U.S. Supreme Court, "Cantwell v. State of Connecticut",
310 U.S. 296 (1940), May 1940,
<http://caselaw.lp.findlaw.com/scripts/
getcase.pl?court=US&vol=310&invol=296>
[Cantwell] U.S. Supreme Court, "Cantwell v. State of Connecticut",
310 U.S. 296 (1940), May 1940,
<http://caselaw.lp.findlaw.com/scripts/
getcase.pl?court=US&vol=310&invol=296>
[FTC] Federal Trade Commission, "Federal, State, Local Law Enforcers Target Deceptive Spam and Internet Scams", November 2002, <http://www.ftc.gov/opa/2002/11/nenetforcema.htm>.
[FTC]联邦贸易委员会，“联邦、州和地方执法人员打击欺诈性垃圾邮件和互联网欺诈”，2002年11月<http://www.ftc.gov/opa/2002/11/nenetforcema.htm>.
[FTC.TSR] Federal Trade Commission, "Telemarketing Sales Rule", Federal Register Vol. 68, No. 19, January 2003, <http://www.ftc.gov/os/2002/12/tsrfinalrule.pdf>.
[FTC.TSR]联邦贸易委员会，“电话销售规则”，联邦公报第68卷，第19期，2003年1月<http://www.ftc.gov/os/2002/12/tsrfinalrule.pdf>.
[Ferris] Associated Press, "Study: Spam costs businesses $13
billion", January 2003,
<http://www.cnn.com/2003/TECH/biztech/01/03/
spam.costs.ap/index.html>
[Ferris] Associated Press, "Study: Spam costs businesses $13
billion", January 2003,
<http://www.cnn.com/2003/TECH/biztech/01/03/
spam.costs.ap/index.html>
[Habeas] Habeas, Inc., "Habeas Compliance Message", 2004,
<http://www.habeas.com/servicesComplianceStds.html>
[Habeas] Habeas, Inc., "Habeas Compliance Message", 2004,
<http://www.habeas.com/servicesComplianceStds.html>
[crocker-spam-techconsider] Crocker, D., "Technical Considerations for Spam Control Mechanisms", Work in Progress, February 2004.
[crocker垃圾邮件技术考虑]crocker，D.，“垃圾邮件控制机制的技术考虑”，正在进行的工作，2004年2月。
[crouzet-amtp] Crouzet, B., "Authenticated Mail Transfer Protocol", Work in Progress, May 2004.
[crouzet amtp]crouzet，B.，“认证邮件传输协议”，正在进行的工作，2004年5月。
[daboo-sieve-spamtest] Daboo, C., "SIEVE Spamtest and Virustest Extensions", Work in Progress, October 2003.
[daboo sieve spamtest]daboo，C.，“sieve spamtest和Virustest扩展”，正在进行的工作，2003年10月。
[danisch-dns-rr-smtp] Danisch, H., "The RMX DNS RR and method for lightweight SMTP sender authorization", Work in Progress, August 2004.
[danisch dns rr smtp]danisch，H.，“RMX dns rr和轻量级smtp发件人授权方法”，正在进行的工作，2004年8月。
[Levine] Levine, J. and P. Hoffman, "Anti-UBE and Anti-UCE Keywords in SMTP Banners", Revision 1.1, March 1999, <http://www.cauce.org/proposal/smtp-banner-rfc.shtml>.
[Levine]Levine，J.和P.Hoffman，“SMTP横幅中的反UBE和反UCE关键字”，1999年3月第1.1版<http://www.cauce.org/proposal/smtp-banner-rfc.shtml>.
[Malamud] Malamud, C., "An Internet Prayer Wheel", Mappa.Mundi Magazine, August 1999, <http://mappa.mundi.net/cartography/Wheel/>.
[Malamud]Malamud，C.，“互联网祈祷轮”，Mappa.Mundi杂志，1999年8月<http://mappa.mundi.net/cartography/Wheel/>.
[Martin] U.S. Supreme Court, "Martin v. City of Struthers, Ohio",
319 U.S. 141 (1943), May 1943,
<http://caselaw.lp.findlaw.com/scripts/
getcase.pl?court=US&vol=319&invol=141>
[Martin] U.S. Supreme Court, "Martin v. City of Struthers, Ohio",
319 U.S. 141 (1943), May 1943,
<http://caselaw.lp.findlaw.com/scripts/
getcase.pl?court=US&vol=319&invol=141>
[Newbury] The Town of West Newbury, Massachusetts, "Soliciting/
Canvassing By-Law", Chapter 18 Section 10, March 2002,
<http://www.town.west-newbury.ma.us/Public_Documents/
WestNewburyMA_Bylaws/000A1547-70E903AC>
[Newbury] The Town of West Newbury, Massachusetts, "Soliciting/
Canvassing By-Law", Chapter 18 Section 10, March 2002,
<http://www.town.west-newbury.ma.us/Public_Documents/
WestNewburyMA_Bylaws/000A1547-70E903AC>
[Perry] U.S. Supreme Court, "Perry Education Association v.
Perry Local Educators' Association", 460 U.S. 37 (1983),
February 1983, <http://caselaw.lp.findlaw.com/scripts/
getcase.pl?court=US&vol=460&invol=37>
[Perry] U.S. Supreme Court, "Perry Education Association v.
Perry Local Educators' Association", 460 U.S. 37 (1983),
February 1983, <http://caselaw.lp.findlaw.com/scripts/
getcase.pl?court=US&vol=460&invol=37>
[RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP 30, RFC 2505, February 1999.
[RFC2505]Lindberg，G.，“SMTP MTA的反垃圾邮件建议”，BCP 30，RFC 2505，1999年2月。
[ROKSO] Spamhaus.Org, "Register of Known Spam Operations", November 2003, <http://www.spamhaus.org/rokso/index.lasso>.
[ROKSO]Spamhaus.Org，“已知垃圾邮件操作登记册”，2003年11月<http://www.spamhaus.org/rokso/index.lasso>.
[Schumer] Charles, C., "Schumer, Christian Coalition Team Up to Crack Down on Email Spam Pornography", June 2003, <http:// www.senate.gov/~schumer/SchumerWebsite/pressroom/ press_releases/PR01782.html>.
[Schumer]Charles，C.，“Schumer，基督教联盟打击垃圾邮件色情制品小组”，2003年6月，<http://www.senate.gov/~Schumer/SchumerWebsite/pressroom/press_releases/PR01782.html>。
[Watchtower] U.S. Supreme Court, "Watchtower Bible & Tract Society of
New York, Inc., et al. v. Village of Stratton et al.",
122 S.Ct. 2080 (2002), June 2002,
<http://caselaw.lp.findlaw.com/scripts/
getcase.pl?court=US&vol=000&invol=00-1737>
[Watchtower] U.S. Supreme Court, "Watchtower Bible & Tract Society of
New York, Inc., et al. v. Village of Stratton et al.",
122 S.Ct. 2080 (2002), June 2002,
<http://caselaw.lp.findlaw.com/scripts/
getcase.pl?court=US&vol=000&invol=00-1737>
Appendix A. Collected ABNF Descriptions (Normative)
附录A.收集的ABNF说明（规范性）
Solicitation-keywords = word
0*("," word)
; length of this string is limited
; to <= 1000 characters
word = ALPHA 0*(wordchar)
wordchar = ("." / "-" / "_" / ":" / ALPHA / DIGIT)
Solicitation-keywords = word
0*("," word)
; length of this string is limited
; to <= 1000 characters
word = ALPHA 0*(wordchar)
wordchar = ("." / "-" / "_" / ":" / ALPHA / DIGIT)
; used in the initial EHLO exchange No-Soliciting-Service = "NO-SOLICITING" [ SP Solicitation-keywords ]
; 用于初始EHLO交换无请求服务=“无请求”[SP请求关键字]
; used on the Solicitation: message header
Solicitation-header = "Solicitation:" 1*SP Solicitation-keywords
; used on the Solicitation: message header
Solicitation-header = "Solicitation:" 1*SP Solicitation-keywords
; used on the MAIL FROM command and replies,
; and on Received: headers.
Mail-From-Solicit-Parameter =
"SOLICIT" "=" Solicitation-keywords
; Solicitation-keywords, when used in
; the MAIL FROM command MUST be identical
; to those in the Solicitation: header.
; used on the MAIL FROM command and replies,
; and on Received: headers.
Mail-From-Solicit-Parameter =
"SOLICIT" "=" Solicitation-keywords
; Solicitation-keywords, when used in
; the MAIL FROM command MUST be identical
; to those in the Solicitation: header.
; Used on Received: headers
With-Solicit = "WITH" FWS Protocol
"(" [FWS] comment [FWS] ")"
; From RFC 2822
comment = "(" *([FWS] ccontent) [FWS] ")"
ccontent = ctext / quoted-pair /
comment / Mail-From-Solicit-Parameter
; The Mail-From-Solicit-Parameter
; is a restricted form of ctext
; From RFC 2821
With = "WITH" FWS Protocol CFWS
Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
Attdl-Protocol = Atom
; Used on Received: headers
With-Solicit = "WITH" FWS Protocol
"(" [FWS] comment [FWS] ")"
; From RFC 2822
comment = "(" *([FWS] ccontent) [FWS] ")"
ccontent = ctext / quoted-pair /
comment / Mail-From-Solicit-Parameter
; The Mail-From-Solicit-Parameter
; is a restricted form of ctext
; From RFC 2821
With = "WITH" FWS Protocol CFWS
Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
Attdl-Protocol = Atom
Author's Address
作者地址
Carl Malamud Memory Palace Press PO Box 300 Sixes, OR 97476 US
卡尔·马拉默德纪念宫出版社邮政信箱300号，或美国邮政信箱97476号
EMail: carl@media.org
EMail: carl@media.org
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编辑功能的资金目前由互联网协会提供。