Network Working Group C. Malamud
Request for Comments: 4096 Memory Palace Press
Category: Informational May 2005
Network Working Group C. Malamud
Request for Comments: 4096 Memory Palace Press
Category: Informational May 2005
Policy-Mandated Labels Such as "Adv:" in Email Subject Headers Considered Ineffective At Best
策略强制使用的标签，如电子邮件主题标题中的“Adv:”，充其量被认为无效
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This memo discusses policies that require certain labels to be inserted in the "Subject:" header of a mail message. Such policies are difficult to specify accurately while remaining compliant with key RFCs and are likely to be ineffective at best. This memo discusses an alternate, standards-compliant approach that is significantly simpler to specify and is somewhat less likely to be ineffective.
本备忘录讨论了要求在邮件“主题：”标题中插入特定标签的策略。这样的政策很难准确地指定，同时仍符合关键的RFC，充其量也可能无效。本备忘录讨论了一种替代的、符合标准的方法，该方法更易于指定，并且不太可能无效。
Table of Contents
目录
1. Labeling Requirements ...........................................2
1.1. Terminology ................................................3
2. Subject Line Encoding ...........................................3
3. Implementing a Labeling Requirement .............................5
4. Subjects are For Humans, Not Labels .............................6
5. Solicitation Class Keywords .....................................8
6. Security Considerations ........................................10
7. Recommendations ................................................10
8. Acknowledgements ...............................................10
9. References .....................................................11
9.1. Normative References ......................................11
9.2. Informative References ....................................11
1. Labeling Requirements ...........................................2
1.1. Terminology ................................................3
2. Subject Line Encoding ...........................................3
3. Implementing a Labeling Requirement .............................5
4. Subjects are For Humans, Not Labels .............................6
5. Solicitation Class Keywords .....................................8
6. Security Considerations ........................................10
7. Recommendations ................................................10
8. Acknowledgements ...............................................10
9. References .....................................................11
9.1. Normative References ......................................11
9.2. Informative References ....................................11
The U.S. Congress and President have enacted the Controlling the Assault of Non-Solicited Pornography and Marketing Act of 2003 (CAN-SPAM Act of 2003) [US], which requires in Section 11(2) that the Federal Trade Commission:
美国国会和总统已经颁布了《2003年控制攻击非招揽色情和营销法案》（2003年CAN-SPAM法案）[US]，该法案第11（2）节要求联邦贸易委员会：
"[transmit to the Congress] a report, within 18 months after the date of enactment of this Act, that sets forth a plan for requiring commercial electronic mail to be identifiable from its subject line, by means of compliance with Internet Engineering Task Force Standards, the use of the characters "ADV" in the subject line, or other comparable identifier, or an explanation of any concerns the Commission has that cause the Commission to recommend against this plan."
“[向国会提交]一份报告，在本法案颁布之日起18个月内，该报告规定了一项计划，要求商业电子邮件通过遵守互联网工程工作队标准，使用字符，从其主题行进行识别。”“在主题行中，或在其他可比较的标识符中，或在委员会对导致委员会反对本计划的任何问题的解释中。”
The Korean Government has enacted the Act on Promotion of Information and Communication and Communications Network Utilization and Information Protection of 2001 [Korea]. As explained by the Korea Information Security Agency, the government body with enforcement authority under the act, Korean law makes it mandatory as of June, 2003 to:
韩国政府颁布了2001年《促进信息和通信及通信网络利用和信息保护法》[Korea]。正如韩国信息安全局（韩国信息安全局）解释的那样，韩国法律规定，自2003年6月起，必须：
"include the '@' (at) symbol in the title portion (right-side) of any commercial e-mail address, in addition to the words '(Advertisement)' or '(Adult Advertisement)' as applicable. The inclusion of the '@' symbol, as proposed by the Korean government, is intended to indicate an e-mail advertisement. Because e-mails easily cross international borders, the '@' symbol may be used as a symbol for filtering advertisement mails." [KISA]
“在任何商业电子邮件地址的标题部分（右侧）包括“@”（at）符号，以及“（广告）”或“（成人广告）字样。”“如适用。韩国政府建议使用“@”符号表示电子邮件广告。由于电子邮件很容易跨越国际边界，因此“@”符号可用作过滤广告邮件的符号。”[KISA]
The State of Colorado has enacted the Colorado Junk Email Law, which states:
科罗拉多州颁布了《科罗拉多垃圾邮件法》，其中规定：
"It shall be a violation of this article for any person that sends an unsolicited commercial electronic mail message to fail to use the exact characters "ADV:" (the capital letters "A", "D", and "V", in that order, followed immediately by a colon) as the first four characters in the subject line of an unsolicited commercial electronic mail message." [Colorado]
“任何发送未经请求的商业电子邮件的人未使用“ADV:”（大写字母“a”、“D”和“V”按顺序排列，后跟冒号）的确切字符，即违反本条规定。”作为未经请求的商业电子邮件主题行的前四个字符。“[科罗拉多州]
The Rules of Professional Conduct of the Florida Bar require, in Rule 4-7.6(c)(3) states:
佛罗里达律师协会的职业行为规则要求，在规则4-7.6（c）（3）中规定：
"A lawyer shall not send, or knowingly permit to be sent, on the lawyer's behalf or on behalf of the lawyer's firm or partner, an associate, or any other lawyer affiliated with the lawyer or the lawyer's firm, an unsolicited electronic mail communication
“律师不得代表律师或律师事务所或合伙人、合伙人或与律师或律师事务所有关联的任何其他律师发送或明知而允许发送未经请求的电子邮件通信
directly or indirectly to a prospective client for the purpose of obtaining professional employment unless ... the subject line of the communication states 'legal advertisement.'" [Florida]
为获得专业就业而直接或间接向潜在客户提供服务，除非。。。通讯的主题是“法律广告”。“[佛罗里达州]
A subject line that complies with the above requirements might read as follows:
符合上述要求的主题行可以如下所示：
Subject: ADV: @ (Advertisement) legal advertisement
Subject: ADV: @ (Advertisement) legal advertisement
A more comprehensive survey of applicable laws would, no doubt, lengthen the above example considerably.
毫无疑问，对适用法律进行更全面的调查将大大延长上述例子。
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, [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、[RFC2119]中所述进行解释。
The basic definition of the "Subject:" of an electronic mail message is contained in [RFC2822]. The normative requirements that apply to all headers are:
[RFC2822]中包含了电子邮件“主题：”的基本定义。适用于所有标题的规范性要求包括：
o The maximum length of the header field is 998 characters.
o 标题字段的最大长度为998个字符。
o Each line must be no longer than 78 characters.
o 每行长度不得超过78个字符。
A multi-line subject field is indicated by the presence of a carriage return and white space, as follows:
多行主题字段由回车符和空白表示，如下所示：
Subject: This is a test
主题：这是一个测试
On the subject of the three unstructured fields ( "Subject:", "Comments:", and "Keywords:"), the standard indicates that these are "intended to have only human-readable content with information about the message." In addition, on the specific subject of the "Subject:" field, the standard states:
关于三个非结构化字段（“主题：”、“注释：”、“关键字：”）的主题，本标准指出，这些字段“旨在仅包含人类可读的内容以及有关消息的信息”。此外，关于“主题：”字段的特定主题，本标准规定：
The "Subject:" field is the most common and contains a short string identifying the topic of the message. When used in a reply, the field body MAY start with the string "Re: " (from the Latin "res", in the matter of) followed by the contents of the "Subject:" field body of the original message. If this is done, only one instance of the literal string "Re: " ought to be used since use of other strings or more than one instance can lead to undesirable consequences.
“主题：”字段是最常见的字段，它包含一个识别消息主题的短字符串。当在回复中使用时，字段正文可以以字符串“Re:”（从拉丁语“res”，在of中）开头，然后是原始消息的“Subject:”字段正文的内容。如果这样做，则只应使用文字字符串“Re:”的一个实例，因为使用其他字符串或多个实例可能会导致不良后果。
Further guidance on the structure of the "Subject:" field is contained in [RFC2047], which species the mechanisms for character set encoding in mail headers. [RFC2978] specifies a mechanism for registering different character sets with the [IANA].
[RFC2047]中包含了关于“主题：”字段结构的进一步指导，它对邮件头中的字符集编码机制进行了分类。[RFC2978]指定向[IANA]注册不同字符集的机制。
In addition to choosing a character set, [RFC2047] uses two algorithms, known as "Base64 Encoding" and "Quoted Printable", which are two different methods for encoding characters that fall outside the basic 7-bit ASCII requirements that are specified in the core electronic mail standards.
除了选择字符集外，[RFC2047]还使用两种算法，称为“Base64编码”和“引用可打印”，这是两种不同的方法，用于编码不符合核心电子邮件标准中规定的基本7位ASCII要求的字符。
Thus, an encoded piece of text consists of the following components:
因此，编码文本由以下组件组成：
o The string "=?", which signifies the beginning of encoded text.
o 字符串“=？”，表示编码文本的开头。
o A valid character set indicator.
o 有效的字符集指示符。
o The string "?", which is a delimiter.
o 字符串“？”，它是一个分隔符。
o The string "b" if "Base64 Encoding" is used or the string "q" if "Quoted Printable" encoding is used.
o 如果使用“Base64编码”，则为字符串“b”；如果使用“引用的可打印”编码，则为字符串“q”。
o The string "?", which is a delimiter.
o 字符串“？”，它是一个分隔符。
o The text, which has been properly encoded.
o 已正确编码的文本。
o The string "?=", which signifies the ending of the encoded text.
o 字符串“？=”，表示编码文本的结束。
A simple example would be to use the popular [8859-1] character set, which has accents and other characters not found in the ASCII character set:
一个简单的例子是使用流行的[8859-1]字符集，该字符集包含ASCII字符集中没有的重音符号和其他字符：
o "Subject: This is an ADV:" is an unencoded header.
o 主题：这是一个ADV:“是一个未编码的标题。
o "Subject: =?iso-8859-1?b?VGhpcyBpcyBhbiBBRFY6?=" is encoded using Base64.
o “主题：=？iso-8859-1？b？VGHPCYBPCYBBRBFY6？=”使用Base64编码。
o "Subject: =?iso-8859-1?q?This=20is=20an=20ADV:?=" is encoded using Quoted Printable.
o “主题：=？iso-8859-1？q？This=20is=20an=20ADV:？=”使用引用的可打印文件进行编码。
o "Subject: =?iso-8859-1?q?This=20is=20an=20=41=44=56=3A?=" is also encoded using Quoted Printable, but instead the last four characters are encoded with their hexadecimal representations.
o “主题：=？iso-8859-1？q？This=20is=20an=20=41=44=56=3A？=”也使用带引号的可打印字符进行编码，但最后四个字符使用其十六进制表示进行编码。
Note that both character set and encoding indicators are case insensitive. Additional complexity can be introduced by appending a language specification to the character set indication, as specified in [RFC2231] and [RFC3066]. This language specification consists of
请注意，字符集和编码指示符都不区分大小写。如[RFC2231]和[RFC3066]中所述，通过在字符集指示后附加语言规范，可以增加复杂性。此语言规范包括
the string "*", followed by a valid language indicator. For example, "US-ASCII*EN" indicates the "US-ASCII" character set and the English language.
字符串“*”，后跟有效的语言指示符。例如，“US-ASCII*EN”表示“US-ASCII”字符集和英语。
When a message is read, the "Subject:" field is decoded, with appropriate characters from the character set displayed to the user. Section 7 (Conformance) of [RFC2047] specifies that a conforming mail reading program must perform the following tasks:
读取消息时，“主题：”字段被解码，并向用户显示字符集中的适当字符。[RFC2047]第7节（一致性）规定，一致性邮件阅读程序必须执行以下任务：
"The program must be able to display the unencoded text if the character set is "US-ASCII". For the ISO-8859-* character sets, the mail reading program must at least be able to display the characters which are also in the ASCII set."
如果字符集为“US-ASCII”，则程序必须能够显示未编码文本。对于ISO-8859-*字符集，邮件阅读程序必须至少能够显示ASCII集中的字符
However, there is no requirement for every system to have every character set. Mail readers that are unable to display a particular set of characters resort to a variety of strategies, including silently ignoring the unknown text, or generating an error or warning message.
然而，并不要求每个系统都有每个字符集。无法显示特定字符集的邮件阅读器采用多种策略，包括默默忽略未知文本，或生成错误或警告消息。
Two characteristics of many common Message User Agents (MUAs) (e.g., mail readers) are worth noting:
许多常见消息用户代理（MUA）（例如邮件阅读器）的两个特征值得注意：
o Although the subject line is, in theory, of unlimited length, many mail readers only show the reader the first few dozen characters.
o 虽然从理论上讲，主题行的长度是无限的，但许多邮件阅读器只向读者显示前几十个字符。
o Electronic mail is often transmitted through gateways, reaching pagers or cell phones with SMS capability. Those systems typically require short subject lines.
o 电子邮件通常通过网关、传呼机或具有SMS功能的手机进行传输。这些系统通常需要较短的主题行。
In this section, we posit a hypothetical situation with two key players:
在本节中，我们假设有两个关键参与者：
o John Doe [Doe] is an attorney at the firm of Dewey, Cheatem & Howe, LLC [Stooges].
o John Doe[Doe]是杜威、契特姆和豪有限责任公司[Stooges]的律师。
o The Federal Trust Commission (FTC) has been entrusted with implementing a recent labeling requirement, promulgated by the Sovereign Government of Freedonia [Duck]. Specifically, President Firefly directed the FTC to "make sure that anybody spamming folks get the symbol 'spam:' in the subject line and or shoot them, if you can find them."
o 联邦信托委员会（FTC）受委托执行弗里多尼亚主权政府[Duck]最近颁布的标签要求。具体来说，Firefly总统指示联邦贸易委员会“确保任何发送垃圾邮件的人都能在主题行中得到“垃圾邮件”的符号，如果你能找到他们，就开枪打死他们。”
Based on this directive, the FTC promulgated a very simple regulation which read: "Please obey the law." John Doe, being a lawyer, read the law, and promptly proceeded to spam everybody using a fairly
根据这一指令，联邦贸易委员会颁布了一项非常简单的规定：“请遵守法律。”身为律师的约翰·多伊阅读了法律，并立即开始使用公平的电子邮件向所有人发送垃圾邮件
obvious loophole: he made sure his subject line was really long, and he shoved all the stuff like "spam:" and the "@" symbol and other verbiage near the end of the 998 allowed characters. He was complying with the law, but of course, nobody saw the labels in their reader.
明显的漏洞：他确保自己的主题行很长，并在998个允许字符的结尾处添加了所有类似“垃圾邮件：”和“@”符号等字眼。他遵守了法律，但当然，没有人在他们的阅读器上看到标签。
Based on a periodic review, the FTC decided to be more specific, and re-promulgated their regulation as follows: "If you send spam, put 'spam:' at the _beginning_ of the subject line." The Freedonian FTC promptly received a visit from the Sylvanian Ambassador, who complained that this conflicted with his country's requirements under the Marx Doctrine to place the string "WATCH OUT! THE CONTENTS OF THIS MESSAGE ARE SUSPECT!" at the beginning of the subject line.
在定期审查的基础上，联邦贸易委员会决定更加具体，并重新颁布了如下规定：“如果你发送垃圾邮件，请在主题行的开头写上‘垃圾邮件’。”，他抱怨说，这与他的国家在马克思主义下的要求相冲突，即在主题行的开头加上“小心！这条消息的内容可疑！”。
The re-promulgation of the regulation was rescinded, more experts were called in, and a new regulation was issued: "Put it as close to the beginning of the subject line as you can, modulo any requirements by other governments." John Doe looked at this, scratched his head, and applied a clever little hack, picking the ISO [8859-8] character set for Hebrew, and duly spelling out the letters ":" Mem Alef Pe Samech.
该法规的重新发布被撤销，更多的专家被召集进来，发布了一项新的法规：“尽可能地将其放在主题行的开头，以其他政府的任何要求为模板。”约翰·多伊看着这一点，挠头，并应用了一个聪明的小技巧，选择了ISO[8859-8]希伯来语字符集，并正确拼写字母：“Mem Alef Pe Samech。
Subject: =?iso-8859-8?q?=f1=f4=e0=ee=3a?=
Subject: =?iso-8859-8?q?=f1=f4=e0=ee=3a?=
Some receivers of this message get an error message because they don't have Hebrew installed on their systems. Others get some cryptic indicator of a missing character set, such as "[?iso-8859-8?]".
此消息的某些接收者收到错误消息，因为他们的系统上没有安装希伯来语。其他人会得到一些缺少字符集的隐晦指示符，比如“[？iso-8859-8？]”。
The FTC called a summit of leading thinkers, and the regulation was amended to read "but don't use languages that go from right to left or up and down instead of plain old left to right." Needless to say, the reaction from the Freedonian League for the Defense of Linguistic Diversity killed that proposed regulation really quickly.
联邦贸易委员会召集了一次主要思想家峰会，该法规被修改为“但不要使用从右到左或上下的语言，而不是简单的从左到右的语言。”不用说，弗里多尼亚捍卫语言多样性联盟的反应真的很快扼杀了该拟议法规。
The commission continued the cycle of re-promulgation and refinement, but ultimately, the regulations continued to contain either a loophole, objectionable requirements, or violations of the relevant RFCs.
委员会继续进行重新颁布和完善的循环，但最终，法规仍然存在漏洞、令人反感的要求或违反相关RFC。
The use of an unknown character set, or of a very, very long subject line are just two examples of how people can try to get around labeling requirements. In order to specify a regulation without ambiguity, it would need to be extremely complex in order to avoid loopholes such as these.
使用未知字符集或非常非常长的主题行只是两个例子，说明人们可以如何绕过标签要求。为了明确规定一项不含糊的规定，它需要极其复杂，以避免此类漏洞。
Drafting of regulations is one issue, but there is another. Subject lines are used to specify, as [RFC2822] says, a "short string identifying the topic of the message."
法规的起草是一个问题，但还有另一个问题。正如[RFC2822]所说，主题行用于指定“识别消息主题的短字符串”
Any regulation has to compete with the other words in the subject, and this mixing of purposes makes it very difficult for a machine to filter out messages at the direction of the user. For example, if one looks for the "@" symbol, per the Korean law, checks have to be made that this symbol is not a legitimate part of a legitimate message.
任何规则都必须与主题中的其他词竞争，这种目的的混合使得机器很难根据用户的指示过滤掉消息。例如，如果根据韩国法律查找“@”符号，则必须检查该符号是否为合法消息的合法部分。
Not only do multiple labeling requirements compete with legitimate subject lines, but also there is no easy way for the sender of a legitimate message to effectively insert other labels that indicate to the recipient that-- although the message may have a required label-- it is actually a message the user might want to see, based on, for example, a prior relationship.
不仅多种标签要求与合法的主题行相竞争，而且合法邮件的发件人也无法轻松有效地插入其他标签，向收件人表明——尽管邮件可能有必要的标签——实际上是用户可能希望看到的邮件，例如，先前的关系。
Even if one considers only the sender of the message, it is very difficult to specify a loophole-free way of putting a specific label in a specific place. And, even if we could control what the sender does, it is an unfortunate fact of life that other agents may also alter the subject line. For example, mailing list management software and even personal email filtering systems will often "munge" the subject line to add information such as the name of a mailing list, or the fact that a message comes from a certain group of people. Such transformations have long been generally accepted as being potentially harmful [RFC0886], and are the subject of continued discussions, which are outside the scope of the present document (see [Koch] and [RFC3834]).
即使只考虑消息的发送者，也很难指定一种无漏洞的方式将特定标签放置在特定位置。而且，即使我们可以控制发送者的行为，但不幸的是，其他代理也可能改变主题行。例如，邮件列表管理软件甚至个人电子邮件过滤系统通常会“咀嚼”主题行，以添加信息，例如邮件列表的名称，或者邮件来自某一特定人群的事实。此类转换长期以来被普遍认为是潜在有害的[RFC0886]，并且是持续讨论的主题，不在本文件的范围内（见[Koch]和[RFC3834]）。
The "Subject:" field is currently overloaded; it has become a handy place for a variety of agents to attempt to insert information. Because of that overloading, it is a poor location for specifying mandatory use of a label, because it is unlikely that label will "rise to the top" and become apparent to the reader of a message or even to the mail-filtering software that examines the mail before the user. The difficulty of implementing subject line labeling, without taking additional steps, has been noted by several other commentators, including [Moore-1], [Lessig], and [Levine]. Indeed, the problem is a general one. Keith Moore has pointed out seven good reasons why tags of any sort in the "Subject:" field have potential problems:
“主题：”字段当前过载；它已成为各种代理尝试插入信息的便捷场所。由于过载，它不是指定强制使用标签的好位置，因为标签不太可能“上升到顶部”，并对邮件读者，甚至对在用户面前检查邮件的邮件过滤软件变得明显。其他几位评论员，包括[Moore-1]、[Lessig]和[Levine]，已经注意到在不采取额外步骤的情况下实施主题行标记的困难。事实上，这是一个普遍的问题。基思·摩尔（Keith Moore）指出了“主题：”字段中任何类型的标签都有潜在问题的七个充分理由：
1. The "Subject:" field space is not strictly limited and long fields can be folded.
1. “主题：”字段空间没有严格限制，长字段可以折叠。
2. PDAs, phones, and other devices and software have only a limited space to display the "Subject:" field.
2. PDA、手机和其他设备和软件显示“主题：”字段的空间有限。
3. A variety of different kinds of labels such as "ADV:" and "[Mailing List Name]" compete for scarce display space.
3. 各种不同种类的标签，如“ADV:”和“[邮件列表名称]”争夺稀缺的显示空间。
4. There are conflicting legal requirements from different jurisdictions.
4. 不同司法管辖区的法律要求相互冲突。
5. There is a conflict between human use of the "Subject:" field and use of that field for filtering and filing:
5. 人类使用“主题：”字段与使用该字段进行过滤和归档之间存在冲突：
* Machine-readable tokens interfere with human readability.
* 机器可读标记会干扰人类可读性。
* Representation of human-readable text was not designed with machine interpretation in mind and, thus, does not have a canonical form.
* 人类可读文本的表示在设计时没有考虑机器解释，因此没有标准形式。
6. Lack of support in a few existing mail readers for displaying information from elsewhere in the message header (e.g., from newly-defined fields), along with familiarity, motivates additional uses of the "Subject:", further compounding the problem.
6. 一些现有的邮件阅读器不支持在邮件头中显示来自其他地方的信息（例如，来自新定义的字段），再加上熟悉程度，导致“主题：”的额外使用，进一步加剧了问题。
7. Any text-based tags added or imposed by outside parties (i.e., those that are not the sender or recipient of the message) will not be reliably meaningful in the recipient's language.
7. 外部各方（即非邮件发送方或接收方）添加或施加的任何基于文本的标记在收件人的语言中都不会有可靠的意义。
Source: [Moore-2].
资料来源：[摩尔-2]。
[RFC3865] defines the "solicitation class keyword", an arbitrary label that can be associated with an electronic mail message and transported by the ESMTP mail service, as defined in [RFC2821] and related documents. Solicitation class keywords are formatted like domain names, but reversed. For example, the registrant of "example.com" might specify a particular solicitation class keyword such as "com.example.adv" that could be inserted in a "No-Solicit:" header or in a trace field. Anybody with a domain name can specify a solicitation class keyword, and anybody sending a message can use any solicitation class keyword that has been defined by themselves or by others.
[RFC3865]定义了“征求类关键字”，这是一个任意标签，可与电子邮件关联并由ESMTP邮件服务传输，如[RFC2821]和相关文档中所定义。请求类关键字的格式类似于域名，但格式相反。例如，“example.com”的注册人可能会指定一个特定的请求类关键字，例如“com.example.adv”，该关键字可以插入到“No-request:”标题或跟踪字段中。任何拥有域名的人都可以指定请求类关键字，任何发送邮件的人都可以使用自己或他人定义的任何请求类关键字。
This memo argues that the "No-Solicit:" approach is either a superior alternative or a necessary complement to "Subject:" field labeling requirements because:
本备忘录认为，“无邀约：”方法是“主题：”字段标签要求的一种更好的替代方法或必要的补充，因为：
o One can specify very precisely what a label should be and where it should go using the "No-Solicit:" header, which is designed specifically for this purpose.
o 可以使用专门为此目的设计的“无请求：”标题非常精确地指定标签应该是什么以及标签应该放在哪里。
o The sender of a message can add additional solicitation class keywords to help distinguish the message. For example, if the "Freedonian Direct Marketing Council" wished to form a voluntary consortium of direct marketers who subscribe to certain practices, they could specify a keyword (e.g., "org.example.freedonia.good.spam") and educate the public to set their filters to receive these types of messages.
o 邮件的发件人可以添加其他请求类关键字以帮助区分邮件。例如，如果“弗里多尼亚直销委员会”希望成立一个自愿的直销商联合会，他们可以指定一个关键字（例如，“org.example.freedonia.good.spam”），并教育公众设置他们的过滤器以接收这些类型的信息。
o Message Transfer Agents (MTAs) may insert solicitation class keywords in the "received:" trace fields, thus providing additional tools for recipients to use for filtering messages.
o 邮件传输代理（MTA）可以在“received:”跟踪字段中插入请求类关键字，从而为收件人提供用于筛选邮件的附加工具。
o A recipient can also define a solicitation class keyword, a tool that allows them to give friends and correspondents a "pass key" so the recipient's mail filtering software always passes through messages containing that keyword.
o 收件人还可以定义一个请求类关键字，这是一个允许他们给朋友和通讯员一个“传递键”的工具，因此收件人的邮件过滤软件总是通过包含该关键字的邮件。
As can be seen, the solicitation class keyword approach is flexible enough to serve as a tool for government-mandated labeling and for other purposes as well.
可以看出，征求类关键字方法足够灵活，可以作为政府授权的标记工具，也可以用于其他目的。
Most modern email software gives users a variety of filtering tools. For example, the popular Eudora program allows a user to specify the name of a message header, the desired match (e.g., a wild card or regular expression, or simply a phrase to match), and an action to take (e.g., moving the message to a particular folder, sounding an alarm, or even automatically deleting messages with harmful content such as viruses). There is one popular email reader that only allows filtering on selected fields, such as "To:", "From:", or "Subject:", but that program is the exception to the rule.
大多数现代电子邮件软件为用户提供了各种过滤工具。例如，流行的Eudora程序允许用户指定消息头的名称、所需的匹配项（例如，通配符或正则表达式，或只是要匹配的短语）和要采取的操作（例如，将邮件移动到特定文件夹、发出警报，甚至自动删除包含有害内容（如病毒）的邮件）。有一种流行的电子邮件阅读器，只允许对选定字段进行过滤，如“收件人”、“发件人”或“主题”，但该程序是该规则的例外。
In summary, for senders and receivers of email, use of the "No-Solicit:" mechanism would be simple to understand and use. For policy makers, it would be extremely simple to specify the format and placement of the solicitation class keyword. Needless to say, the issue of how to define what classes of messages are subject to such a requirement, and how to enforce it, are beyond the scope of this discussion.
总之，对于电子邮件的发送者和接收者，使用“无请求：”机制将很容易理解和使用。对于决策者来说，指定征求类关键字的格式和位置将非常简单。不用说，如何定义哪些类别的消息符合这样的要求，以及如何实施这样的要求，超出了本文讨论的范围。
The use of labels in the "Subject:" field gives users and policy makers an unwarranted illusion that certain classes of messages will be "flagged" correctly by the MUA of the recipient. The difficulty in specifying requirements for labels in the "Subject:" field in a precise, unambiguous manner makes it difficult for the MUA to systematically identify messages that are labeled; this leads to both false positive and false negative indications.
在“主题：”字段中使用标签会让用户和决策者产生一种不必要的错觉，即收件人的MUA会正确地“标记”某些类别的邮件。在“主题：”字段中以精确、明确的方式指定标签要求的困难使得MUA难以系统地识别已标记的消息；这会导致假阳性和假阴性指示。
In addition, conflicting labeling requirements by policy makers, as well as other current practices that use the "Subject:" for a variety of purposes, make that field "overloaded." In order to meet these conflicting requirements, software designers and bulk mail senders resort to a variety of tactics, some of which may violate fundamental requirements of the mail standards, such as the practice of an intermediate MTA inserting various labels into the "Subject:" field. Such practices increase the likelihood of non-compliant mail messages and, thus, threaten interoperability between implementations.
此外，政策制定者相互冲突的标签要求，以及出于各种目的使用“主题：”的其他现行做法，使该领域“过载”。为了满足这些相互冲突的要求，软件设计师和批量邮件发送者采取了各种策略，其中一些可能违反邮件标准的基本要求，例如中间MTA在“主题：”字段中插入各种标签的做法。这种做法增加了不符合要求的邮件消息的可能性，从而威胁到实现之间的互操作性。
This document makes three recommendations:
本文件提出三项建议：
1. There is widespread skepticism in the technical community that labels of any sort will be effective. Such labels should probably be avoided as ineffective at best.
1. 技术界普遍怀疑任何类型的标签是否有效。这样的标签最好是避免无效的。
2. Despite the widespread skepticism expressed in point 1, over 36 states in the U.S. and 27 countries have passed anti-spam measures, many of which require labels [Sorkin]. If such labels are to be used, despite the widespread skepticism expressed in point 1, there is a fairly broad consensus in the technical community that such labels should not be put in the "Subject:" field and should go in a designated header field.
2. 尽管第1点中表达了广泛的怀疑，但美国超过36个州和27个国家已经通过了反垃圾邮件措施，其中许多要求贴标签[Sorkin]。如果要使用此类标签，尽管第1点中表达了广泛的怀疑，但技术界有一个相当广泛的共识，即此类标签不应放在“主题：”字段中，而应放在指定的标题字段中。
3. If, despite points 1 and 2, a policy of mandating labels in the "Subject:" field is adopted, a complementary requirement to use the "No-Solicit:" should also be added.
3. 尽管有第1点和第2点的规定，如果采用了强制在“主题：”字段中添加标签的政策，则还应添加使用“禁止征集：”的补充要求。
The author would like to thank the following for their helpful suggestions and reviews of this document: Joe Abley, Harald Alvestrand, Elwyn Davies, Alain Durand, Frank Ellermann, Ted Hardie, Tony Hansen, Scott Hollenbeck, Peter Koch, Bruce Lilly, Keith Moore, Pekka Savola, and Mark Townsley.
作者感谢以下人士对本文件提出的有益建议和评论：乔·艾布利、哈拉尔·阿尔维斯特兰、埃尔温·戴维斯、阿兰·杜兰德、弗兰克·埃勒曼、特德·哈迪、托尼·汉森、斯科特·霍伦贝克、彼得·科赫、布鲁斯·莉莉、基思·摩尔、佩卡·萨沃拉和马克·汤斯利。
[IANA] IANA, "Registry of Official Names for Character Sets That May Be Used on the Internet", February 2004, <http://www.iana.org/assignments/character-sets>.
[IANA]IANA，“可在互联网上使用的字符集官方名称登记册”，2004年2月<http://www.iana.org/assignments/character-sets>.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[RFC2231]Freed，N.和K.Moore，“MIME参数值和编码字扩展：字符集、语言和连续体”，RFC 22311997年11月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]Klensin，J.，“简单邮件传输协议”，RFC 28212001年4月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
[RFC2978]Freed，N.和J.Postel，“IANA字符集注册程序”，BCP 19，RFC 2978，2000年10月。
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[RFC3066]Alvestrand，H.，“语言识别标签”，BCP 47，RFC 3066，2001年1月。
[RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension", RFC 3865, September 2004.
[RFC3865]Malamud，C.，“一个无请求的简单邮件传输协议（SMTP）服务扩展”，RFC3865，2004年9月。
[8859-1] International Organization for Standardization, "Information technology - 8-bit single byte coded graphic - character sets - Part 1: Latin alphabet No. 1, JTC1/ SC2", ISO Standard 8859-1, 1987.
[8859-1]国际标准化组织，“信息技术-8位单字节编码图形-字符集-第1部分：第1号拉丁字母JTC1/SC2”，ISO标准8859-11987。
[8859-8] International Organization for Standardization, "Information Processing - 8-bit Single-Byte Coded Graphic Character Sets, Part 8: Latin/Hebrew alphabet", ISO Standard 8859-8, 1988.
[8859-8]国际标准化组织，“信息处理-8位单字节编码图形字符集，第8部分：拉丁/希伯来字母”，ISO标准8859-81988。
[Colorado] Sixty-Second General Assembly of the State of Colorado, "Colorado Junk Email Law", House Bill 1309, June 2000, <http://www.spamlaws.com/state/co.html>.
[科罗拉多州]科罗拉多州第六十二届大会，“科罗拉多州垃圾邮件法”，众议院法案1309，2000年6月<http://www.spamlaws.com/state/co.html>.
[Doe] Frank Capra (Director), "Meet John Doe", IMDB Movie No. 0033891, 1941, <http://us.imdb.com/title/tt0033891/>.
弗兰克·卡普拉（导演），《遇见约翰·多伊》，IMDB电影编号00338911941<http://us.imdb.com/title/tt0033891/>.
[Duck] The Mark Brothers, "Duck Soup", IMDB Movie No. 0023969, 1933, <http://us.imdb.com/title/tt0023969/>.
[鸭子]马克兄弟，“鸭子汤”，IMDB电影编号0023969，1933年<http://us.imdb.com/title/tt0023969/>.
[Florida] The Florida Bar, "Rules of Professional Conduct", 2005, <http://www.flabar.org/divexe/rrtfb.nsf/ WContents?OpenView&Start=1&Count=30&Expand=4.8#4.8>.
[佛罗里达州]佛罗里达律师协会，“职业行为规则”，2005年<http://www.flabar.org/divexe/rrtfb.nsf/ WContents？OpenView&Start=1&Count=30&Expand=4.8#4.8>。
[KISA] Korea Information Security Agency, "Korea Spam Response Center -- Legislation for Anti-Spam Regulations: Mandatory Indication of Advertisement", 2003, <http://www.spamcop.or.kr/eng/m_2.html>.
[KISA]韩国信息安全局，“韩国垃圾邮件响应中心——反垃圾邮件法规立法：广告的强制性指示”，2003年<http://www.spamcop.or.kr/eng/m_2.html>.
[Koch] Koch, P., "Subject: [tags] Considered Harmful", Work in Progress, November 2004.
[Koch]Koch，P.，“主题：[标签]被认为有害”，正在进行的工作，2004年11月。
[Korea] National Assembly of the Republic of Korea, "Act on Promotion of Information and Communication and Communications Network Utilization and Information Protection of 2001", 2001, <http://www.mic.go.kr/eng/res/ res_pub_db/res_pub_mic_wp/2003/whitepaper2003/in3_7.htm>.
[韩国]大韩民国国民议会，“2001年促进信息和通信及通信网络利用和信息保护法”，2001年<http://www.mic.go.kr/eng/res/ res_pub_db/res_pub_mic_wp/2003/whitepaper2003/in3_7.htm>。
[Lessig] Lessig, L., "How to unspam the Internet", The Philadelphia Inquirer, May 2003, <http://www.philly.com/ mld/inquirer/news/editorial/5778539.htm?1c>.
[Lessig]Lessig，L.，“如何使用互联网”，费城询问报，2003年5月<http://www.philly.com/ mld/inquirer/news/editor/5778539.htm？1c>。
[Levine] Levine, J., "Comments In the Matter of: REPORT TO CONGRESS PURSUANT TO CAN-SPAM ACT", Federal Trade Commission, Matter No. PO44405, February 2004, <http://www.ftc.gov/ reports/dneregistry/xscripts/dne040226pm.pdf>.
[Levine]Levine，J.，“对以下事项的评论：根据CAN-SPAM法案向国会提交报告”，联邦贸易委员会，第PO44405号事项，2004年2月<http://www.ftc.gov/ reports/dneregistry/xscript/dne040226pm.pdf>。
[Moore-1] Moore, K., "Individual Comment of Mr. Keith Moore Re: Label for E-mail Messages", Federal Trade Commission of the U.S., NPRM Comment RIN 3084-AA96, February 2004, <http ://www.ftc.gov/os/comments/adultemaillabeling/ 040216moore.pdf>.
[Moore-1]Moore，K.，“Keith Moore先生关于电子邮件标签的个人评论”，美国联邦贸易委员会，NPRM评论RIN 3084-AA96，2004年2月，<http://www.ftc.gov/os/comments/adultemaillabeling/040216 Moore.pdf>。
[Moore-2] Moore, K., "E-mail Message to the Author and the IESG", March 2005.
[Moore-2]Moore，K.，“给作者和IESG的电子邮件”，2005年3月。
[RFC0886] Rose, M., "Proposed standard for message header munging", RFC 886, December 1983.
[RFC0886]Rose，M.，“消息头扫描的拟议标准”，RFC 886，1983年12月。
[RFC3834] Moore, K., "Recommendations for Automatic Responses to Electronic Mail", RFC 3834, August 2004.
[RFC3834]Moore，K.，“自动回复电子邮件的建议”，RFC 38342004年8月。
[Sorkin] Sorkin, D., "http://www.spamlaws.com/", 2005, <http://www.spamlaws.com/>.
[Sorkin]Sorkin，D.，”http://www.spamlaws.com/", 2005, <http://www.spamlaws.com/>.
[Stooges] The Three Stooges, "Heavenly Daze", IMDB Movie No. 0040429, 1948, <http://us.imdb.com/title/tt0040429/>.
[Stooges]三个Stooges，“天堂的大泽”，IMDB电影编号0040429，1948<http://us.imdb.com/title/tt0040429/>.
[US] United States Congress, "The Controlling the Assault of Non-Solicited Pornography and Marketing Act of 2003 (CAN-SPAM Act of 2003)", Public Law 108-187, 117 STAT. 2699, 15 USC 7701, December 2003, <http://frwebgate.access.gpo.gov/ cgi-bin/getdoc.cgi?dbname=108_cong_public_laws &docid=f:publ187.108.pdf>.
[美国]美国国会，“2003年控制攻击非邀约色情和营销法案（2003年CAN-SPAM法案）”，公法108-187，117 STAT.2699，15 USC 7701，2003年12月<http://frwebgate.access.gpo.gov/ cgi-bin/getdoc.cgi？dbname=108\u cong\u public\u laws&docid=f:publ187.108.pdf>。
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 (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。