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
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
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年のマーケティング法第11条（2）に必要です（2003年のCAN-SPAM法）[US]、のアサルトを制御制定されています：
"[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ヶ月以内に報告書を、[議会に送ります] 、委員会はそれが委員会を引き起こした文字件名に「ADV」、または他の同等の識別子、または任意の懸念事項の説明の使用は、この計画に反対をお勧めします。」
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年の情報保護[韓国]の促進に関する法律を制定しました。韓国情報セキュリティ庁が説明したように、法の下で執行権限を持つ政府機関は、韓国の法律は6月、2003年のように、それが必須となります：
"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]
「適用などの単語 『（広告）』または 『（アダルト広告）』に加えて、任意の商用電子メールアドレスのタイトル部分（右側）における記号（で） 『@』が含まれています。含めます「@」記号は、韓国政府が提案したように、電子メールは簡単に国境を越えているため、「@」記号は、広告メールをフィルタリングするためのシンボルとして使用することができる。電子メール広告を示すことを意図しています。」 [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]
その中に 『（大文字『A』、『D』、および『V』、：ADV「それは正確な文字を使用するために失敗する迷惑な商用電子メールメッセージを送信するすべての人のために、この記事に違反しなければなりません』注文は、迷惑な商用電子メールメッセージの件名行の最初の4つの文字としてコロン）の直後。」 [コロラド州]
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
件名：ADV：@（広告）法的広告
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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:
3つの非構造化フィールドの件名（：、「コメント：」、および「キーワード：」「件名」）には、標準では、これらは、「メッセージに関する情報を有する唯一の人間が読めるコンテンツを持っていることを意図し。」していることを示していますまた、「件名：」の特定のテーマに関する分野、標準の状態：
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.
「件名：」フィールドには、最も一般的であり、メッセージの話題を識別する短い文字列が含まれています。 （の問題ではラテン語「RES」から）「件名：」の内容に続いて、元のメッセージのフィールドボディ：返信で使用する場合、フィールドボディは「再」の文字列で始まるかもしれません。これは文字列リテラルの行われ、唯一のインスタンスである場合は、「再：」他の文字列の使用または複数のインスタンスから使用されるべきであることは望ましくない結果につながることができます。
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]はで指定されている基本的な7ビットのASCII要件から外れる文字をエンコードするための2つの異なる方法である「Base64でエンコード」および「引用符で囲まれた印刷可能」として知られる、2つのアルゴリズムを使用しコア電子メールの規格。
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.
「Base64でエンコード」が使用される場合、文字列「B」または場合は、文字列「Q」O「引用符で囲まれた印刷可能」エンコーディングが使用されます。
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:
簡単な例では、ASCII文字セットにないアクセントや他の文字が使用されている人気の[8859-1]文字セットを使用することです：
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 VGhpcyBpcyBhbiBBRFY6 =？" はBase64でエンコードされています。
o "Subject: =?iso-8859-1?q?This=20is=20an=20ADV:?=" is encoded using Quoted Printable.
O "件名：？= ISO-8859-1 Qこれ= 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これ= 20is = 20AN = 20 = 41 = 44 = 56 = 3A =？" も引用印刷ページを使用して符号化され、その代わりに最後の4つの文字は、それら進数で符号化されます表現。
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:
このセクションでは、我々は2人のキープレーヤーとの仮定の状況を断定します：
o John Doe [Doe] is an attorney at the firm of Dewey, Cheatem & Howe, LLC [Stooges].
Oジョン・ドウ[ドウ]はデューイ、Cheatem＆ハウの会社で弁護士で、LLC [大将]。
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）は、フリードニア[アヒル]のソブリン政府が公布最近のラベリング要件を、実装を委託されています。具体的には、大統領のホタルは、「『スパム：』誰でもスパムの人々は、シンボルを取得していることを確認してください。件名にと、またはあなたがそれらを見つけることができれば、それらを撃つ」にFTCを指示しました
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.
このディレクティブに基づいて、FTCは読んで非常に単純な規則公布：「法令を遵守してください」をジョン・ドウは、弁護士であること、法律を読んで、そして迅速に進めかなり明白抜け穴を利用して皆をスパムする：彼は彼の件名行が本当に長かったことを確認した、と彼は「スパム：」のようにすべてのものを押し込んだと「@」記号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.
「『スパム：』を入れて、あなたがスパムを送信した場合：件名行の_beginning_で」定期的な見直しに基づき、FTCは、次のように具体的にすることを決めた、と再公布それらの調節Freedonian FTCは、速やかにこの文字列を配置するマルクス主義の下で彼の国の要件と競合があることを訴えシルバニア大使からの訪問を受け、「OUT WATCH！このメッセージの内容が疑わしいです！」件名の先頭にあります。
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.
規制の再公布は、より多くの専門家が呼ばれた、撤回し、新たな規制が発行されました：「することができますように件名の先頭に近いそれを入れて、他の政府によるすべての要件を法。」 「：」MemのアレフPeのSamechジョン・ドウは、彼の頭に傷、およびヘブライ語に設定されたISO [8859-8]の文字を選んで、賢い少しハックを適用し、正式に手紙を綴り、これを見ました。
Subject: =?iso-8859-8?q?=f1=f4=e0=ee=3a?=
件名：？？？？= 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.
FTCは、主要な思想家のサミットと呼ばれ、規制が読むために改正された「が、上下の代わりに、昔ながらの左右に左または右から行くの言語を使用しないでください。」言うまでもなく、言語の多様性の防衛のためのFreedonianリーグからの反応は、規制案本当にすぐに殺されました。
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.
未知の文字セットを使用する、または非常に、非常に長い件名の行のは、人々がラベリング要件を回避しようとすることができる方法のちょうど2つの例があります。曖昧さのない規制を特定するためには、このような抜け穴を避けるために非常に複雑であることが必要です。
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."
規制のDraftingは、問題の1つであるが、別のがあります。件名は以下のように、指定するのに使用されている[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.
いずれの規制は、対象内の他の単語と競合しており、目的のこの混合は、それは非常に困難なマシンは、ユーザーの指示でメッセージをフィルタリングできるようになります。たとえば、1は「@」記号を探している場合、韓国の法律ごとに、チェックがこのシンボルは、正当なメッセージの正当な一部ではないことを行わなければなりません。
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.
複数のラベリング要件は、正当な件名と競合するだけでなく、効果的にメッセージがそれlabel--必要としているかもしれないがthat--受信者に示す他のラベルを挿入するための正当なメッセージの送信者のための簡単な方法はありませんかだけでなく、実際に、ユーザは、例えば、に基づいて、前の関係を見たいかもしれないメッセージです。
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]).
1は、メッセージの送信者だけを考慮したとしても、特定の場所で特定のラベルを置くの抜け穴のない方法を指定することは非常に困難です。そして、我々は、送信者が何をするかを制御できたとしても、他のエージェントも件名を変更することが人生の不幸な事実です。例えば、メーリングリスト管理ソフトウェア、さらには個人の電子メール・フィルタリング・システムは、しばしば「のmunge」件名には、このようなメーリングリストの名前、またはメッセージが人々の特定のグループから来ているという事実などの情報を追加します。そのような変換は長い一般潜在的に有害な[RFC0886]であるとして受け入れられており、本文書の範囲外で継続議論の対象とされてきた（参照[コッホ]と[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:
「件名：」フィールドが現在過負荷になっています。それは情報を挿入しようとする種々の薬剤のための便利な場所となっています。ラベルが「トップに上がる」とのメッセージの読者にあるいはそのメールが調べフィルタリングソフトウェアには明らかになるであろうことはほとんどありませんので、そのためのオーバーロードのために、それは、ラベルの義務的使用を指定するための貧弱な場所ですユーザーの前にメール。追加の手順を取ることなく、件名行のラベルを実装することの難しさは、[ムーア-1]、[レッシグ]、および[レヴァイン]を含むいくつかの他の解説者によって指摘されています。確かに、この問題は一般的なものです。 「件名：」フィールドの潜在的な問題を持っているキース・ムーアはであらゆる種類のタグがなぜ7つの理由を指摘しています：
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]は、「勧誘クラスキーワード」、[RFC2821]で定義されるように、電子メールメッセージに関連付けられ、ESMTPメールサービスによって搬送することができる任意のラベルと関連ドキュメントを定義します。勧誘クラス・キーワードは、ドメイン名のようにフォーマットされたが、逆になっています。ヘッダまたはトレースフィールドに：例えば、「example.com」の登録者が「No-要請」に挿入することができ、このような「com.example.adv」などの特定の要請クラスキーワードを指定するかもしれません。ドメイン名を持つ誰もが勧誘クラスのキーワードを指定することができ、そして誰もがメッセージを送信することによって、自分自身や他の人によって定義されている任意の勧誘クラスのキーワードを使用することができます。
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メッセージの送信者はメッセージを区別しやすくするために、追加の勧誘クラスのキーワードを追加することができます。たとえば「Freedonianダイレクトマーケティング協議会」は、特定の慣行に加入ダイレクトマーケティング担当者の自主的なコンソーシアムを形成することを望むならば、彼らはキーワードを指定することができます（例えば、「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）は、「受信」に勧誘クラスのキーワードを挿入することができます。
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のプログラムは、例えば、移動（ユーザが取るためにメッセージヘッダ、所望の一致（例えば、ワイルドカードまたは正規表現、または単にフレーズ一致する）、およびアクションの名前を指定することができ特定のフォルダへのメッセージ、アラームを鳴らし、あるいは自動的にウイルスなどの有害なコンテンツ）でメッセージを削除します。 、「から：」、または「件名：」、しかし、そのプログラムは、規則の例外です：のみ選択されたフィールド上でフィルタリングを可能にするもので人気の電子メールの読者は、このような「TO」として、があります。
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:
この文書では、3件の勧告を行います。
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カ国は、ラベル[ソーキン]を必要とする多くのそれらのアンチスパム対策を、合格しています。フィールドと指定されたヘッダフィールドに行く必要があります。そのような標識はポイント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.
「件名：」場合は、点1及び2にもかかわらず、でラベルを義務付けるの方針3：も追加しなければならないフィールドが採用され、相補的な要件は、「非要請」を使用しないこと。
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.
著者は彼らの有益な提案や、このドキュメントのレビューのために次のことを感謝したいと思います：ジョー・Abley、ハラルドAlvestrand、エルウィン・デイヴィス、アラン・デュラン、フランクEllermann、テッドハーディー、トニー・ハンセン、スコットホレンベック、ピーター・コッホ、ブルース・リリー、キース・ムーア、ペッカSavola、およびマーク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]ムーア、K.、 "MIME（多目的インターネットメール拡張）パート3：非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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]解放され、N.とK.ムーア、 "MIMEパラメータ値およびエンコードされたWordの機能拡張：文字セット、言語、および継続の"、RFC 2231、1997年11月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821] Klensin、J.、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
[RFC2978]フリード、N.とJ.ポステル、 "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]マラマッド、C.、 "いいえ募集簡易メール転送プロトコル（SMTP）サービスの拡張"、RFC 3865、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-1、1987。
[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-8、1988。
[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>.
[コロラド州]コロラド州の第62総会、「コロラド迷惑メール法」、下院法案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作品番号0033891、1941年、<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の＆スタート= 1＆カウント= 30＆展開= 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.
[コッホ]コッホ、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>.
[レッシグ]レッシグ、L.、 "インターネットをunspamする方法"、フィラデルフィアインクワイア、2003年5月、<http://www.philly.com/ MLD /照会者/ニュース/編集/ 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>.
[レヴァイン]レヴァイン、J.、 "の問題でコメント：CONGRESS基づきTO CAN-SPAM ACT TO REPORT"、米連邦取引委員会、物質号PO44405、2004年2月、<http://www.ftc.gov/レポート/dneregistry/xscripts/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>.
[ムーア-1]ムーア、K.、 "ミスターキース・ムーアのRe個々のコメント：電子メールメッセージのラベル"、米国の連邦取引委員会、NPRMコメントRIN 3084-AA96、2004年2月、<のhttp：// www.ftc.gov/os/comments/adultemaillabeling/ 040216moore.pdf>。
[Moore-2] Moore, K., "E-mail Message to the Author and the IESG", March 2005.
[ムーア-2]ムーア、K.、 "メール本文者とIESGへ"、2005年3月。
[RFC0886] Rose, M., "Proposed standard for message header munging", RFC 886, December 1983.
[RFC0886]ローズ、M.、RFC 886、1983年12月 "メッセージヘッダいじるための提案された標準"。
[RFC3834] Moore, K., "Recommendations for Automatic Responses to Electronic Mail", RFC 3834, August 2004.
[RFC3834]ムーア、K.、 "電子メールへの自動応答のための提言"、RFC 3834、2004年8月。
[Sorkin] Sorkin, D., "http://www.spamlaws.com/", 2005, <http://www.spamlaws.com/>.
【ソーキン]ソーキン、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/>.
【大将】三ばか大将、 "天ダズ"、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>.
[US]米国議会は、「非要請ポルノと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_cong_public_laws＆DOCID = F：？publ187.108.pdf>。
Author's Address
著者のアドレス
Carl Malamud Memory Palace Press PO Box 300 Sixes, OR 97476 US
カール・マラマッドメモリ宮殿を押し私書箱300シックス、OR 97476米国
EMail: carl@media.org
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。