[要約] 要約：RFC 4096は、電子メールの件名ヘッダーに「Adv：」などのポリシーによって指定されたラベルを使用することの効果の低さについて述べています。 目的：このRFCの目的は、ポリシーによって指定されたラベルが電子メールのスパムフィルタリングにおいて効果的でないことを明らかにし、より効果的な方法を提案することです。
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).
Copyright（c）The Internet Society（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年の非統合ポルノマーケティング法（2003年缶スパム法）[米国]の攻撃の支配を制定しました。
"[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年[韓国]の情報と通信ネットワークの利用と情報保護の促進に関する法律を制定しました。韓国情報セキュリティ機関が説明したように、法律に基づいて執行機関を持つ政府機関である韓国法は、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）シンボルを含める」または「（アダルト広告）」または「（アダルト広告）」。韓国政府によって提案されている「@」シンボルは、電子メール広告を示すことを目的としています。電子メールは容易に国際的な境界を越えているため、「@」シンボルは広告メールをフィルタリングするためのシンボルとして使用できます。」[キサ]
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： "（The Capitaing" a "、" d "、および" V "など順序、すぐにコロンが続きます）未承諾の商用電子メールメッセージの件名の最初の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
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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.
「件名：」フィールドは最も一般的であり、メッセージのトピックを識別する短い文字列が含まれています。返信で使用する場合、フィールドボディは、文字列「Re：」（ラテン語の「解像度」から、問題に）から始まることがあります。これが行われた場合、他の文字列または複数のインスタンスを使用すると望ましくない結果につながる可能性があるため、リテラル文字列「Re：」の1つのインスタンスのみが使用されるべきです。
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エンコード」と「引用された印刷可能」として知られる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.
o 文字列「b」は、「base64エンコード」が使用される場合、または「引用された印刷可能」エンコードが使用される場合、文字列「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？
o "Subject: =?iso-8859-1?q?This=20is=20an=20ADV:?=" is encoded using Quoted Printable.
o 「件名：=？ISO-8859-1？Q？this = 20IS = 20an = 20ADV：？= "QUOTED Printableを使用してエンコードされます。
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？= "も引用符で描かれた印刷可能ですが、代わりに最後の4文字は16進表現でエンコードされます。
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 the string "*", followed by a valid language indicator. For example, "US-ASCII*EN" indicates the "US-ASCII" character set and the English language.
文字セットとエンコーディングインジケーターの両方が、症例が鈍感であることに注意してください。[RFC2231]および[RFC3066]で指定されているように、文字セット表示に言語仕様を追加することにより、追加の複雑さを導入できます。この言語仕様は文字列「*」で構成され、その後に有効な言語インジケータが続きます。たとえば、「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:
多くの一般的なメッセージユーザーエージェント（MUAS）（例えば、メールリーダー）の2つの特性は注目に値します。
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 John Doe [Doe]は、Dewey、Cheem＆Howe、LLC [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）は、Freedoniaの主権政府[Duck]によって公布された最近のラベル付け要件の実施を委託されています。具体的には、ホタル大統領は、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.
定期的なレビューに基づいて、FTCはより具体的になることを決定し、次のように規制を再農業化しました：「スパムを送信する場合は、件名の_begining_に「スパム：」を入れます。」Freedonian FTCは、シルバニア大使からすぐに訪問を受けました。シルバニア大使は、これがマルクスの教義に基づく彼の国の要件と矛盾していると不満を言いました。件名の先頭に。
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?=
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は主要な思想家のサミットと呼ばれ、規制は「しかし、左から右に右から右に代わりに右から左または上下に行く言語を使用しないでください」と読むように修正されました。言うまでもなく、言語の多様性の防衛のためのフリードニアンリーグからの反応は、その規制を非常に迅速に提案したことを殺しました。
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."
規制の起草は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.
規制は、主題の他の言葉と競合する必要があり、この目的の混合により、マシンがユーザーの方向にメッセージを除外することが非常に困難になります。たとえば、韓国の法律に従って「@」シンボルを探した場合、このシンボルが正当なメッセージの正当な部分ではないことをチェックする必要があります。
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]).
メッセージの送信者のみを考慮したとしても、特定のラベルを特定の場所に配置する抜け穴のない方法を指定することは非常に困難です。そして、送信者が何をするかを制御できたとしても、他のエージェントが件名を変更する可能性があることは、人生の不幸な事実です。たとえば、メーリングリスト管理ソフトウェアや個人のメールフィルタリングシステムでさえ、件名を「Munge」して、メーリングリストの名前や特定のグループからのメッセージが届くという事実などの情報を追加することがよくあります。このような変換は、潜在的に有害であると一般に受け入れられてきました[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]など、他のいくつかのコメンテーターによって注目されています。実際、問題は一般的なものです。キース・ムーアは、「件名」のあらゆる種類のタグが潜在的な問題を抱えているという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].
出典：[Moore-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メールサービスによって輸送される任意のラベルである「Solicitation Class Keyword」を定義します。勧誘クラスのキーワードはドメイン名のようにフォーマットされますが、逆転します。たとえば、「Example.com」の登録者は、「com.example.adv」など、「no-solicit：」ヘッダーまたはトレースフィールドに挿入できる特定の勧誘クラスのキーワードを指定する場合があります。ドメイン名を持つ人なら誰でも勧誘クラスのキーワードを指定でき、メッセージを送信する人は誰でも、自分自身または他の人によって定義された勧誘クラスのキーワードを使用できます。
This memo argues that the "No-Solicit:" approach is either a superior alternative or a necessary complement to "Subject:" field labeling requirements because:
このメモは、「no-solicit：」アプローチは、「件名」に対する優れた代替または必要な補完のいずれかであると主張しています。
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 この目的のために特別に設計された「no-solicit：no-solicit： "ヘッダーを使用して、ラベルがどうあるべきか、どこに行くべきかを非常に正確に指定できます。
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 Direct Market Council」が特定のプラクティスを購読する直接マーケティング担当者の自発的なコンソーシアムを形成したい場合、キーワード（ "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.
ご覧のように、Solicitationクラスのキーワードアプローチは、政府が義務付けているラベル付けやその他の目的のためのツールとしても機能するほど柔軟です。
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」、 "from："、または "subject："など、選択したフィールドでのみフィルタリングを許可する人気のある電子メールリーダーが1つありますが、そのプログラムはルールの例外です。
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.
要約すると、電子メールの送信者と受信者の場合、「no-solicit：」メカニズムの使用は、理解して使用するのが簡単です。政策立案者の場合、Solicitationクラスのキーワードの形式と配置を指定することは非常に簡単です。言うまでもなく、どのクラスのメッセージがそのような要件の対象となるか、それを実施する方法を定義する方法の問題は、この議論の範囲を超えています。
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で表明された広範な懐疑論にもかかわらず、米国および27か国の36を超える州がスパム対策対策に合格しており、その多くはラベル[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にもかかわらず、「サブジェクト：」フィールドにラベルを義務付けるポリシーが採用されている場合、「no-solicit：」を使用するための補完的な要件も追加する必要があります。
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.
著者は、この文書の有益な提案とレビューについて以下に感謝したいと思います：ジョー・イーブリー、ハラルド・アルベスランド、エルウィン・デイビス、アラン・デュランド、フランク・エラーマン、テッド・ハーディ、トニー・ハンセン、スコット・ホレンベック、ピーター・コッホ、ブルース・リリー、キース・ムーア、Pekka Savola、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]ムーア、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] 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 2231、1997年11月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]クレンシン、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年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 Charset登録手順」、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。、「A Staliting Simple Mail Transfer Protocol（SMTP）Service Extension」、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：ラテンアルファベットNo. 1、JTC1/ SC2」、ISO Standard 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 Standard 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>.
[コロラド]コロラド州の60秒の総会、「コロラドジャンクメールロー」、下院法案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/>.
[doe]フランク・カプラ（ディレクター）、「ジョン・ドゥー」、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＆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/editorial/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 Actに基づく議会への報告」、連邦取引委員会、問題No. PO44405、2004年2月、<http://www.ftc.gov/ Reports/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>.
[Moore-1] Moore、K。、「キース・ムーア氏の個別のコメント：電子メールメッセージのラベル」、米国連邦取引委員会、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] Rose、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/>.
[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] 3つのStooges、「Heavenly Daze」、IMDB Movie No. 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年缶スパム法）の攻撃の支配」、公法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：f：publ187.108.pdf>。
Author's Address
著者の連絡先
Carl Malamud Memory Palace Press PO Box 300 Sixes, OR 97476 US
Carl Malamud Memory Palace Press Po Box 300 Sixes、または97476 US
EMail: carl@media.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。