Network Working Group C. Malamud
Request for Comments: 3865 Memory Palace Press
Category: Standards Track September 2004
A No Soliciting Simple Mail Transfer Protocol (SMTP)
Service Extension
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document proposes an extension to Soliciting Simple Mail Transfer Protocol (SMTP) for an electronic mail equivalent to the real-world "No Soliciting" sign. In addition to the service extension, a new message header and extensions to the existing "received" message header are described.
この文書では、実世界への電子メールと同等のための簡易メール転送プロトコル（SMTP）を募集する拡張子「いいえ募集」記号を提案しています。サービス拡張に加えて、既存の「受信」メッセージヘッダに新しいメッセージヘッダ及び拡張が記載されています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Spam Pandemic. . . . . . . . . . . . . . . . . . . . 3
1.2. No Soliciting in the Real World. . . . . . . . . . . . . 4
1.3. No Soliciting and Electronic Mail. . . . . . . . . . . . 5
2. The No-Soliciting SMTP Service Extension . . . . . . . . . . . 6
2.1. The EHLO Exchange. . . . . . . . . . . . . . . . . . . . 7
2.2. Solicitation Class Keywords. . . . . . . . . . . . . . . 7
2.2.1. Note on Choice of Solicitation Class Keywords. . 8
2.3. The MAIL FROM Command. . . . . . . . . . . . . . . . . . 9
2.4. Error Reporting and Enhanced Mail Status Codes . . . . . 10
2.5. Solicitation Mail Header . . . . . . . . . . . . . . . . 10
2.6. Insertion of Solicitation Keywords in Trace Fields . . . 11
2.7. Relay of Messages. . . . . . . . . . . . . . . . . . . . 12
2.8. No Default Solicitation Class. . . . . . . . . . . . . . 12
3. Security Considerations . . . . . . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
4.1. The Mail Parameters Registry . . . . . . . . . . . . . . 13
4.2. Trace Fields . . . . . . . . . . . . . . . . . . . . . . 14
4.3. The Solicitation Mail Header . . . . . . . . . . . . . . 14
5. Author's Acknowledgements . . . . . . . . . . . . . . . . . . 14
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Normative References . . . . . . . . . . . . . . . . . . 15
6.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Collected ABNF Descriptions (Normative) . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 19
Unsolicited Bulk Email (UBE), otherwise known as spam, has become as one of the most pressing issues on the Internet. One oft-quoted study estimated that spam would cost businesses $13 billion in 2003 [Ferris]. In April 2003, AOL reported that it had blocked 2.37 billion pieces of UBE in a single day [CNET]. And, in a sure sign that UBE has become of pressing concern, numerous politicians have begun to issue pronouncements and prescriptions for fighting this epidemic [Schumer][FTC].
そうでない場合はスパムとして知られている迷惑メール（UBE）は、インターネット上で最も差し迫った問題の一つとしてなっています。ワンしばしば引用符で囲まれた研究では、スパムが[観覧] 2003年に企業に$ 13億かかるだろうと推定しています。 2003年4月に、AOLは、それが一日[CNET]でUBEの23.7億部分をブロックしていたことを報告しました。そして、UBEは懸念を押すのとなっている確かな証拠には、数多くの政治家は、この流行[シューマー] [FTC]を戦うために宣告し、処方箋を発行し始めています。
A variety of mechanisms from the technical community have been proposed and/or implemented to fight UBE:
技術的なコミュニティからのさまざまなメカニズムが提案および/またはUBEを戦うために実装されています。
o Whitelists are lists of known non-spammers. For example, Habeas, Inc. maintains a Habeas User List (HUL) of people who have agreed to not spam. By including a haiku in email headers and enforcing copyright on that ditty, they enforce their anti-spamming terms of service [Habeas].
Oホワイトリストは、既知の非スパマーのリストです。例えば、人身保護、Inc.はないスパムに合意している人たちの人身保護ユーザーリスト（HUL）を維持します。電子メールのヘッダに俳句を含めて、その小唄の著作権を強制することで、彼らはサービスの彼らのスパム対策に関して[人身保護]を適用します。
o Blacklists are lists of known spammers or ISPs that allow spam [ROKSO].
Oブラックリストは、スパム[ROKSO]を許可する既知のスパマーかのISPのリストです。
o Spam filters run client-side or server-side to filter out spam based on whitelists, blacklists, and textual and header analysis [Assassin].
Oスパムフィルタは、ホワイトリスト、ブラックリスト、およびテキストおよびヘッダ解析[アサシン]に基づいてスパムをフィルタリングするために、クライアント側またはサーバー側を実行します。
o A large number of documents address the overall technical considerations for the control of UBE [crocker-spam-techconsider], operational considerations for SMTP agents [RFC2505], and various extensions to the protocols to support UBE identification and filtering [danisch-dns-rr-smtp][daboo-sieve-spamtest][crouzet-amtp].
Oドキュメント多数のUBE識別とフィルタリング[デンマークの特許-dns-をサポートするプロトコルにUBE [クロッカースパム-techconsider]、SMTP剤[RFC2505]のための操作の考慮事項、および様々な拡張を制御するための全体的な技術的考慮事項に取り組みますRR-SMTP] [daboo-篩はspamtest] [メーカーCrouzet-amtp]。
o Various proposals have been advanced for "do not spam" lists, akin to the Federal Trade Commission's "Do Not Call" list for telemarketers [FTC.TSR].
O様々な提案は、連邦取引委員会のテレマーケティング[FTC.TSR]用リスト「をコールしない」に似リスト、「スパムにはない」のために進められています。
Terminology
用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。
Municipalities frequently require solicitors to register with the town government. And, in many cases, the municipalities prohibit soliciting in residences where the occupant has posted a sign. The town of West Newbury, Massachusetts, for example, requires:
自治体は、頻繁に町の政府に登録する弁護士が必要です。そして、多くの場合、自治体は乗員が看板を掲載している住宅に勧誘は禁止されています。西ニューベリー、マサチューセッツ州の町は、例えば、必要があります。
"It shall be unlawful for any canvasser or solicitor to enter the premises of a resident or business who has displayed a 'No Trespassing' or 'No Soliciting' sign or poster. Further, it shall be unlawful for canvassers or solicitors to ignore a resident or business person's no solicitation directive or remain on private property after its owner has indicated that the canvasser or solicitor is not welcome" [Newbury].
任意の勧誘員や弁護士が、 『立ち入り禁止』または 『いいえ募集』記号やポスターを表示していない居住者やビジネスの敷地内に入るようにするためにそれは違法なものでなければならない。さらにcanvassersや弁護士が常駐を無視するために」、それは違法なものでなければなりませんまたは事業者のいない勧誘ディレクティブまたはその所有者が[ニューベリー]「勧誘員や弁護士は歓迎ではないことが示された後、私有地に残ります。
Registration requirements for solicitors, particularly those soliciting for political or religious reasons, have been the subject of a long string of court cases. However, the courts have generally recognized that individuals may post "No Soliciting" signs and the government may enforce the citizen's desire. In a recent case where Jehovah's Witnesses challenged a registration requirement in the city of Stratton, Connecticut, saying they derived their authority from the Scriptures, not the city. However, the court noted:
事務弁護士の登録要件、政治的または宗教上の理由のために勧誘特には、裁判例、長い文字列の対象とされてきました。しかし、裁判所は、一般的に個人が「いいえ募集」の標識を掲示しないことがあり、政府は市民の願いを強制することを認識しています。エホバの証人は、彼らが聖書から彼らの権威ではなく、街を導出言って、ストラットン、コネチカット市の登録要件に挑戦最近のケースで。しかし、裁判所は指摘します：
"A section of the ordinance that petitioners do not challenge establishes a procedure by which a resident may prohibit solicitation even by holders of permits. If the resident files a 'No Solicitation Registration Form' with the mayor, and also posts a 'No Solicitation' sign on his property, no uninvited canvassers may enter his property... " [Watchtower].
「請願者が挑戦をしません条例のセクションでは、居住者が市長と 『ノー要請登録フォーム』をファイルしない場合。居住者にも許可の保有者による勧誘を禁止することができるする手順を確立し、また 『いいえ勧誘』を投稿しません彼の財産に署名し、何も招かれざるcanvassersは彼の財産に入らないことがあります... "[望楼]。
Even government, which has a duty to promote free expression, may restrict the use of soliciting on government property. In one case, for example, a school district was allowed to give access to its internal electronic mail system to the union that was representing teachers, but was not required to do so to a rival union that was attempting to gain the right to represent the teachers. The court held that where property is not a traditional public forum "and the Government has not dedicated its property to First Amendment activity, such regulation is examined only for reasonableness" [Perry].
無料の発現を促進する義務を有していても、政府は、政府の財産上の勧誘の使用を制限することができます。あるケースでは、例えば、学区が教師を代表して労働組合にその内部の電子メールシステムへのアクセス権を与えることを許されましたが、代表権を獲得しようとしていたライバル組合にそうするように要求されていませんでした教師。裁判所は、[ペリー]プロパティは、伝統的なパブリックフォーラムではないです「と政府は憲法修正第一条の活動にその財産を捧げていない、そのような規制が唯一の合理性について検査される」と判示しました。
The courts have consistently held that the state has a compelling public safety reason for regulating solicitation. In Cantwell v. Connecticut, the Supreme Court held that "a State may protect its citizens from fraudulent solicitation by requiring a stranger in the community, before permitting him publicly to solicit funds for any purpose, to establish his identity and his authority to act for the cause which he purports to represent" [Cantwell]. And, in Martin v. City of Struthers, the court noted that "burglars frequently pose as canvassers, either in order that they may have a pretense to discover whether a house is empty and hence ripe for burglary, or for the purpose of spying out the premises in order that they may return later" [Martin]. The public safety issue applies very much to email, where viruses can easily be delivered, in contrast to telephone solicitations where public safety is not nearly as much an issue.
裁判所は一貫状態は勧誘を規制するための魅力的な公共の安全の理由があると判示しています。キャントウェル対コネチカットでは、最高裁判所は、州は彼が公に彼のアイデンティティとのために行動する彼の権威を確立するために、どのような目的のための資金を募集することを可能にする前に、コミュニティで見知らぬ人に要求することによって、不正な勧誘から市民を保護することができる」と判示しました彼は[キャントウェル]「を表現することを目的としている原因。そして、StruthersのマーティンV。市では、裁判所は、強盗が頻繁にcanvassersとして提起する」と述べ、どちらか彼らは家が空と強盗のために、またはアウトスパイ行為を目的としたので、熟しているかどうかを発見するふりを有することができるようにするために彼らは「後で[マーチン]を返すようにするためで施設。ウイルスは簡単に公共の安全性がほぼ同じくらいの問題ではありません、電話勧誘とは対照的に、配信することができる場所公共の安全性の問題は、電子メールに非常に適用されます。
This analysis is U.S.-centric, which is partly due to the background of the author. However, the concept of prohibiting unwanted solicitation does carry over to other countries:
この分析は、部分的に作者の背景によるものである米国中心の、です。しかし、不要な勧誘を禁止するという概念は、他の国に持ち越しません。
o In Hong Kong, offices frequently post "no soliciting" signs.
O香港では、オフィスは、しばしば「無勧誘」の兆候を投稿していません。
o In the United Kingdom, where door-to-door peddlers are fairly common, "no soliciting" signs are also common.
Oドア・ツー・ドアの行商人はかなり共通している英国では、「何の勧誘」の兆候も一般的ではありません。
o In Australia, where door-to-door does not appear to be a pressing social problem, there was legislation passed which outlawed the practice of placing ads under wipers of parked cars.
Oドア・ツー・ドアは押し社会問題であるようには見えないオーストラリアでは、駐車した車のワイパーの下に広告を置くことの練習を不法と合格法律がありました。
o In France, which has a long tradition of door-to-door solicitation, apartment buildings often use trespass laws to enforce "no solicitation" policies.
ドア・ツー・ドア勧誘の長い伝統を持っているフランス、中のO、アパートの建物は、多くの場合、「ノー勧誘」ポリシーを施行するためにトレスパス法律を使用しています。
o In the Netherlands, where door-to-door solicitation is not a pressing issue, there is a practice of depositing free publications in mailboxes. The postal equivalent of "no spam" signs are quite prevalent and serve notice that the publications are not desired.
Oドア・ツー・ドアの勧誘が喫緊の課題ではないオランダでは、メールボックス内の無料出版物を堆積させるの練習があります。 「いいえスパム」の標識の郵便同等はかなり普及していると出版物を希望されていないという通知を提供しています。
Many of the anti-spam proposals that have been advanced have great merit, however none of them give notice to an SMTP agent in the process of delivering mail that the receiver does not wish to receive solicitations. Such a virtual sign would serve two purposes:
進められているアンチスパム提案の多くは、しかし、それらのどれもが、受信機が勧誘を受信したくないメールを配信するプロセスでSMTPエージェントに通知していない、大きなメリットがあります。このような仮想看板には2つの目的があります：
o It would allow the receiving system to "serve notice" that a certain class of electronic mail is not desired.
Oこれは、受信システムは、電子メールの特定のクラスが望まれていないことに「気づく仕える」ことが可能になります。
o If a message is properly identified as belonging to a certain class and that class of messages is not desired, transfer of the message can be eliminated. Rather than filtering after delivery, elimination of the message transfer can save network bandwidth, disk space, and processing power.
メッセージが適切に望まれていない特定のクラスとメッセージのそのクラスに属するものとして識別される場合、O、メッセージの転送をなくすことができます。むしろ納入後のフィルタリングよりも、メッセージ転送の排除は、ネットワーク帯域幅、ディスク容量、および処理能力を節約することができます。
This memo details a series of extensions to SMTP that have the following characteristics:
このメモは、次のような特徴を持っているSMTPの拡張機能のシリーズを詳しく説明します。
o A service extension is described that allows a receiving Mail Transport Agent (MTA) to signal the sending MTA that no soliciting is in effect.
Oサービス拡張は、受信メール転送エージェント（MTA）がNO勧誘が有効でないことを送信側MTAを通知することを可能にすることが記載されています。
o A header field for the sender of the message is defined that allows the sender to flag a message as conforming to a certain class.
Oメッセージの送信者のためのヘッダフィールドはフラグを送信者特定のクラスに準拠したメッセージを可能にするように定義されています。
o Trace fields for intermediate MTAs are extended to allow the intermediate MTA to signal that a message is in a certain class.
中間MTAのOトレースフィールドは、中間MTAは、メッセージが特定のクラスにあることを知らせることができるように拡張されます。
Allowing the sender of a message to tag a message as being, for example, unsolicited commercial email with adult content, allows "good" spammers to conform to legal content labelling requirements by governmental authorities, license agreements with service providers, or conventions imposed by "whitelist" services. For senders of mail who choose not to abide by these conventions, the intermediate trace fields defined here allow the destination MTAs to perform appropriate dispositions on the received message.
例えば、あるとしてメッセージにタグを付けるために、メッセージの送信者を許可すると、アダルトコンテンツを迷惑な商用電子メールは、「「良い」スパマーはによって課される法的なコンテンツラベリング政府当局による要件、サービスプロバイダとのライセンス契約、または規則に準拠することができますホワイトリスト」サービス。これらの規則を遵守しないことを選択したメールの送信者のために、ここで定義された中間トレースフィールドは、先のMTAは、受信したメッセージに適切な処分を行うことを可能にします。
This extension provides a simple mean for senders, MTAs, and receivers to assert keywords. This extension does not deal with any issues of authentication or consent.
この拡張には、送信者、MTAは、キーワードを主張するために受信機のための単純平均を提供します。この拡張は、認証や同意のいずれかの問題に対処しません。
Per [RFC2821], a "NO-SOLICITING" SMTP service extension is defined. The service extension is declared during the initial "EHLO" SMTP exchange. The extension has one optional parameter, consisting of zero or more solicitation class keywords. Using the notation as described in the Augmented BNF [RFC2234], the syntax is:
[RFC2821]、 "NO-勧誘" SMTPサービス拡張が定義されています。サービス拡張は、最初の「EHLO」SMTP交換中に宣言されています。拡張子は、ゼロ以上の勧誘クラスのキーワードからなる、1つのオプションのパラメータがあります。増補BNF [RFC2234]に記載されているように表記法を使用して、構文は次のとおりです。
No-Soliciting-Service = "NO-SOLICITING" [ SP Solicitation-keywords ]
無勧誘ん-サービス= "NO-勧誘" [SP要請-キーワード]
As will be further described below, the "Solicitation-keywords" construct is used to indicate which classes of messages are not desired. A keyword that is presented during the initial "EHLO" exchange applies to all messages exchanged in this session. As will also be further described below, additional keywords may be specified on a per-recipient basis as part of the response to a "RCPT TO" command.
さらに後述するように、「勧誘・キーワード」構築物は、メッセージのクラスが望まれていないかを示すために使用されます。最初の「EHLO」交換時に提示されたキーワードは、このセッションで交換されるすべてのメッセージに適用されます。また、さらに後述するように、追加キーワードは、「RCPT TO」コマンドへの応答の一部として受信者ごとに指定することができます。
Keywords presented during the initial exchange indicate that no soliciting in the named classes is in effect for all messages delivered to this system. It is equivalent to the sign on the door of an office building announcing a company-wide policy. For example:
最初の交換時に提示キーワードは何という名前のクラスで勧誘がこのシステムに配信されるすべてのメッセージのために有効にされていないことを示しています。これは、全社的な方針を発表するオフィスビルのドアサインオンと同じです。例えば：
R: <wait for connection on TCP port 25> S: <open connection to server> R: 220 trusted.example.com SMTP service ready S: EHLO untrusted.example.com R: 250-trusted.example.com says hello R: 250-ENHANCEDSTATUSCODES R: 250-NO-SOLICITING net.example:ADV R: 250 SIZE 20480000
R：<TCPポート25で接続を待つ> S：<サーバーへのオープン接続> R：220 trusted.example.com SMTPサービス準備S：EHLO untrusted.example.com R：250-trusted.example.com R挨拶：250 ENHANCEDSTATUSCODES R：250-NO-勧誘net.example：ADVのR：250 SIZE2048万
The "net.example:ADV" parameter to the "NO-SOLICITING" extension is an example of a solicitation class keyword, the syntax of which is described in the following section.
：「NO-勧誘」拡張子を「net.example ADV」パラメータは勧誘クラスキーワードの一例である、の構文は、次のセクションで説明されています。
Historical Note:
ヒストリカルノート：
A similar proposal was advanced in 1999 by John Levine and Paul Hoffman. This proposal used the SMTP greeting banner to specify that unsolicited bulk email is prohibited on a particular system through the use of the "NO UCE" keyword [Levine]. As the authors note, their proposal has the potential of overloading the semantics of the greeting banner, which may also be used for other purposes (see, e.g., [Malamud]).
同様の提案はジョン・レヴァインとポール・ホフマンによって1999年に進められました。この提案は、迷惑メールが「NO UCE」キーワード[レビン]を使用して、特定のシステム上禁止されていることを指定するには、SMTPグリーティングバナーを使用しました。著者が注意されるように、それらの提案は、他の目的（例えば、[マラマッド]）に使用することができるグリーティングバナーのセマンティクスを過負荷の可能性を有します。
The "NO-SOLICITING" service extension uses solicitation class keywords to signify classes of solicitations that are not accepted. Solicitation class keywords are separated by commas.
「NO-勧誘」サービス拡張は受け付けておりません勧誘のクラスを表すために勧誘クラスのキーワードを使用しています。勧誘クラスのキーワードはカンマで区切られています。
There is no default solicitation class keyword for the service. In other words, the following example is a "no-op":
サービスにはデフォルトの勧誘クラス・キーワードはありません。つまり、次の例では、「無操作」ではありません。
R : 250-NO-SOLICITING
R：250-NO-勧誘
While the above example is a "no-op" it is useful for an MTA that wishes to pass along all messages, but would also like to pass along "SOLICIT=" parameters on a message-by-message basis. The above example invokes the use of the extension but does not signal any restrictions by class of message.
上記の例が「NO-OP」でない間は、すべてのメッセージに沿って通過したいMTAのために有用であるだけでなく、メッセージごとにパラメータ「=を求める」に沿って通過したいです。上記の例では、拡張の使用を呼び出すが、メッセージのクラスによって何ら制限を通知しません。
The initial set of solicitation class keywords all begin with a domain name with the labels reversed, followed by a colon. For example, the domain name "example.com" could be used to form the beginning of a solicitation class keyword of "com.example:". The solicitation class keyword is then followed by an arbitrary set of characters drawn from the following construct:
勧誘クラスの初期セットは、すべてのコロン逆転したラベルを持つドメイン名、で始まるキーワード。たとえば、ドメイン名「example.comは、」の勧誘クラス・キーワードの先頭に形成するために使用することができ、「com.exampleを：」。勧誘クラスキーワードは、その後、以下の構築物から引き出された文字の任意のセットが続きます。
Solicitation-keywords = word 0*("," word) ; length of this string is limited ; to <= 1000 characters word = ALPHA 0*(wordchar) wordchar = ("." / "-" / "_" / ":" / ALPHA / DIGIT)
勧誘-キーワード=ワード0 *（ "" 言葉）。この文字列の長さが限られています。 （ "" - "：" / ALPHA / DIGIT "" / "_" / /）<= 1000文字・ワード= ALPHA 0 *（wordchar）wordchar =へ
A solicitation class keyword MUST be less than 1000 characters. Note however that a set of keywords used in the operations defined in this document must also be less than 1000 characters. Implementors are thus advised to keep their solicitation class keywords brief.
勧誘クラス・キーワードは、1000文字未満でなければなりません。この文書で定義された操作に使用するキーワードのセットも1000文字未満でなければならないことに注意してください。実装者は、このように簡単に彼らの勧誘クラスのキーワードを維持することをお勧めします。
Any registrant of a domain name may define a solicitation class keyword. Discovery of solicitation class keywords is outside the scope of this document. However, those registrants defining keywords are advised to place a definition of their solicitation class keywords on a prominent URL under their control such that search engines and other discovery mechanisms can find them.
ドメイン名のいずれかの登録者が勧誘クラスのキーワードを定義することもできます。勧誘のクラス・キーワードの発見は、この文書の範囲外です。しかし、キーワードを定義し、それらの登録者は、検索エンジンや他の検出メカニズムがそれらを見つけることができるように、それらの制御下で、著名なURLに自分の勧誘クラスのキーワードの定義を配置することをお勧めします。
While this document defines solicitation class keywords as beginning with a reversed domain name followed by a colon (":"), future RFCs may define additional mechanisms that do not conflict with this naming scheme.
この文書はコロン逆ドメイン名（「：」）で始まるよう勧誘クラスのキーワードを定義する一方、将来のRFCは、この命名方式と競合しない追加的なメカニズムを定義することができます。
This document does not specify which solicitation class keywords shall or shall not be used on a particular message. The requirement to use a particular keyword is a policy decision well outside the scope of this document. It is expected that relevant policy bodies (e.g., governments, ISPs, developers, or others) will specify appropriate keywords, the definition of the meaning of those keywords, and any other policy requirements, such as a requirement to use or not use this extension in particular circumstances.
この文書では、クラスのキーワードがまたは特定のメッセージに使用してはならないものとする勧誘指定されていません。特定のキーワードを使用するための要件はよく、このドキュメントの範囲外の政策決定です。関連するポリシー体（例えば、政府、ISPは、開発者、または他の人が）この拡張機能を使用するように使用するための要件として、適切なキーワード、これらのキーワードの意味の定義、およびその他のポリシー要件を、指定したりしないことが予想されます特定の状況インチ
During discussions of this proposal, there were several suggestions to do away with the solicitation class keywords altogether and replace the mechanism with a simple boolean (e.g., "NO-SOLICITING YES" or "ADV" or "UBE"). Under a boolean mechanism, this extension would have to adopt a single definition of what "YES" or other label means. By using the solicitation class keywords approach, the mail infrastructure remains a neutral mechanism, allowing different definitions to co-exist.
この提案の議論の中で、完全に勧誘クラスのキーワードを廃止し、簡単なブール（例えば、「YES NO-勧誘」または「ADV」または「UBE」）とのメカニズムを交換するには、いくつかの提案がありました。ブールのメカニズムの下では、この拡張機能は、「YES」または他の標識が何を意味するのかの単一の定義を採用する必要があります。勧誘クラス・キーワードのアプローチを使用することにより、メールインフラストラクチャは、さまざまな定義が共存できるように、中立のメカニズムのまま。
"SOLICIT" is defined as a parameter for the "MAIL FROM" command. The "SOLICIT" parameter is followed by an equal sign and a comma separated list of solicitation class keywords. The syntax for this parameter is:
「SOLICITは」コマンド「FROM MAIL」のパラメータとして定義されます。 「SOLICIT」パラメータは、等号と勧誘クラスキーワードのコンマ区切りのリストが続きます。このパラメータの構文は次のとおりです。
Mail-From-Solicit-Parameter = "SOLICIT" "=" Solicitation-keywords ; Solicitation-keywords, when used in MAIL FROM command ; MUST be identical to those in the Solicitation: header.
メール-から-要請-パラメータ= "SOLICIT" "=" 勧誘-キーワード。勧誘-キーワード、MAIL FROMコマンドで使用された場合、ヘッダ：勧誘のものと同一でなければなりません。
Note that white space is not permitted in this production.
ホワイトスペースは、この生産に許可されていないことに注意してください。
As an informational message, the "550" or "250" replies to the "RCPT TO" command may also contain the "SOLICIT" parameter. If a message is being rejected due to a solicitation class keyword match, implementations SHOULD echo which solicitation classes are in effect. See Section 2.4 for more on error reporting.
情報メッセージとして、「550」や「250」コマンドが「SOLICIT」パラメータをも含むことができ、「TO RCPT」に応答します。メッセージが原因勧誘クラスのキーワードマッチに拒否されている場合、実装は、クラスが有効である勧誘エコーすべきです。エラー報告の詳細については2.4節を参照してください。
The receiving system may decide on a per-message basis the appropriate disposition of messages:
受信システムは、メッセージごとにメッセージの適切な配置を決定することができます。
R: <wait for connection on TCP port 25> S: <open connection to server> R: 220 trusted.example.com SMTP service ready S: EHLO untrusted.example.com R: 250-trusted.example.com says hello R: 250-NO-SOLICITING net.example:ADV S: MAIL FROM:<save@example.com> SOLICIT=org.example:ADV:ADLT S: RCPT TO:<coupon_clipper@moonlink.example.com> R: 250 <coupon_clipper@moonlink.example.com>... Recipient ok S: RCPT TO:<grumpy_old_boy@example.net> R: 550 <grumpy_old_boy@example.net> SOLICIT=org.example:ADV:ADLT
R：<TCPポート25で接続を待つ> S：<サーバーへのオープン接続> R：220 trusted.example.com SMTPサービス準備S：EHLO untrusted.example.com R：250-trusted.example.com R挨拶：250-NO-勧誘net.example：ADV S：MAIL FROM：<save@example.com> SOLICIT = org.example：ADV：ADLT S：RCPT TO：<coupon_clipper@moonlink.example.com> R：250 < coupon_clipper@moonlink.example.com> ...受信者OK S：RCPT TO：<grumpy_old_boy@example.net> R：550 <grumpy_old_boy@example.net> SOLICIT = org.example：ADV：ADLT
In the previous example, the receiving MTA returned a "550" status code, indicating that one message was being rejected. The implementation also echoes back the currently set keywords for that user on the "550" status message. The solicitation class keyword which is echoed back is "org.example:ADV:ADLT" which illustrates how this per-recipient solicitation class keyword has supplemented the base "net.example:ADV" class declared in the "EHLO" exchange.
前の例では、受信MTAは、一つのメッセージが拒否されたことを示し、「550」のステータスコードを返し。実装は、「550」のステータスメッセージに、そのユーザーの現在設定されているキーワードをエコーバック。 「EHLO」と引き換えに宣言されたクラス：この受信者ごとの勧誘クラス・キーワードがベース「ADV net.example」を補完している様子を示している「ADLT：ADV org.example」エコーバックされる勧誘クラスのキーワードがあります。
It is the responsibility of a receiving MTA to maintain a consistent policy. If the receiving MTA will reject a message because of solicitation class keywords, the MTA SHOULD declare those keywords either in the initial "EHLO" exchange or on a per-recipient basis. Likewise, a receiving MTA SHOULD NOT deliver a message where the "Solicitation:" matches a solicitation class keyword that was presented during the initial "EHLO" exchange or on a per-recipient basis.
一貫したポリシーを維持するために、受信MTAの責任です。受信側MTAが原因勧誘クラス・キーワードのメッセージを拒否する場合は、MTAは、最初の「EHLO」と引き換えに、または受信者ごとにどちらかのこれらのキーワードを宣言する必要があります。最初の「EHLO」交換中または受信者ごとに提示された勧誘クラスのキーワードに一致します。同様に、受信側MTAは「勧誘」のメッセージを届けるべきではありません。
Developers should also note that the source of the solicitation class keywords used in the "MAIL FROM" command MUST be the "Solicitation:" header described in Section 2.5 and MUST NOT be supplemented by additional solicitation class keywords derived from the "Received:" header trace fields which are described in Section 2.6.
ヘッダは、セクション2.5に記載さに由来する追加の要請クラスキーワードによって補完されてはいけません「受付：」ヘッダ：開発者は、コマンド「FROM MAIL」で使用勧誘クラスキーワードのソースが「勧誘」である必要があることに注意すべきですセクション2.6で説明されているフィールドをトレースします。
If a session between two MTAs is using both the "NO-SOLICITING" extension and the Enhanced Mail Status Codes as defined in [RFC3463] and a message is rejected based on the presence of a "SOLICIT" parameter, the correct error message to return will usually be "5.7.1", defined as "the sender is not authorized to send to the destination... (because) of per-host or per-recipient filtering."
[RFC3463]で定義されるように2つのMTA間のセッションは、「NO-勧誘」拡張と拡張メールステータスコードの両方を使用して、メッセージが「SOLICIT」パラメータの存在に基づいて拒否され、正しいエラーメッセージを返すようにした場合通常、「送信者が（理由）ホストごとまたは受信者ごとのフィルタリングの...宛先に送信することを許可されていません。」と定義し、「5.7.1」になります
Other codes, including temporary status codes, may be more appropriate in some circumstances and developers should look to [RFC3463] on this subject. An example of such a situation might be the use of quotas or size restrictions on messages by class. An implementation MAY impose limits such as message size restrictions based on solicitation classes, and when such limits are exceed they SHOULD be reported using whatever status code is appropriate for that limit.
この主題に[RFC3463]になります一時的なステータスコードを含む他のコードは、いくつかの状況と開発者がより適切かもしれません。このような状況の例としては、クォータやクラスによってメッセージのサイズ制限を使用するかもしれません。実装は、勧誘クラスに基づいてそのようなメッセージサイズの制限などの制限を課すことができ、このような限界を超えているときには、ステータスコードがその限界に適したどのような使用して報告されるべきです。
In all cases, an implementation SHOULD include a "Mail-From-Solicit-Parameter" on a "550" or other reply that rejects message delivery. The parameter SHOULD includes the solicitation class keyword(s) that matched. In addition to the solicitation class keyword(s) that matched, an implementation MAY include additional solicitation class keywords that are in effect.
全ての場合において、インプリメンテーションは、「メールから-要請-パラメータ」メッセージの配信を拒否し、「550」または他の応答にを含むべきです。パラメータSHOULDは一致勧誘クラスのキーワード（s）などがあります。マッチした勧誘クラスのキーワード（複数可）に加えて、実装が有効になっている追加の勧誘クラスのキーワードを含むかもしれません。
Per [RFC2822], a new "Solicitation:" header field is defined which contains one or more solicitation class keywords.
パー[RFC2822]、新しい「勧誘：」ヘッダフィールドは、一つ以上の勧誘クラスのキーワードを含む定義されています。
Solicitation-header = "Solicitation:" 1*SP Solicitation-keywords
勧誘ヘッダ=「勧誘：」1 *のSP要請 - キーワード
An example of this header follows:
このヘッダーの例は次のとおり
To: Coupon Clipper <coupon_clipper@moonlink.example.com> From: Spam King <save@burntmail.example.com> Solicitation: net.example:ADV,org.example:ADV:ADLT
To：クーポンクリッパー<coupon_clipper@moonlink.example.com>から：スパム王<save@burntmail.example.com>勧誘：net.example：ADV、org.example：ADV：ADLT
Several proposals, particularly legal ones, have suggested requiring the use of keywords in the "Subject:" header. While embedding information in the "Subject:" header may provide visual cues to end users, it does not provide a straightforward set of cues for computer programs such as mail transfer agents. As with embedding a "no solicitation" message in a greeting banner, this overloads the semantics of the "Subject:" header. Of course, there is no reason why both mechanisms can't be used, and in any case the "Solicitation:" header could be automatically inserted by the sender's Mail User Agent (MUA) based on the contents of the subject line.
ヘッダ：いくつかの提案、特に法的なものは、「件名」のキーワードの使用を必要と示唆しています。情報埋め込みながら、「件名：」ヘッダは、そのようなメール転送エージェントのコンピュータプログラムのための手がかりの簡単なセットを提供しない、エンドユーザに視覚的な手がかりを提供してもよいです。ヘッダ：グリーティングバナーで「NO要請」メッセージを埋め込むことと同様に、これは「件名」のセマンティクスをオーバーロード。もちろん、両方のメカニズムを使用することができない理由、およびいずれの場合にも存在しない「勧誘は：」ヘッダが自動的に件名の内容に基づいて、送信者のメールユーザエージェント（MUA）によって挿入することができます。
The "Solicitation:" mail header is only available to the sending client. RFCs 2821 and 2822 are quite specific that intermediate MTAs shall not change message headers, with the sole exception of the "Received:" trace field. Since many current systems use an intermediate relay to detect unsolicited mail, an addition to the "Received:" header is described.
「勧誘：」メールヘッダを送信するクライアントにのみ使用可能です。トレースフィールド：のRFC 2821および2822は、中間MTAが「受信」の唯一の例外を除いて、メッセージヘッダを変更してはならないということは非常に固有のものです。多くの現在のシステムは、迷惑メールを検出するために、中間中継を使用するので、「受付：」に加えヘッダが記述されています。
[RFC2821] documents the following productions for the "Received:" header in a mail message:
メールメッセージのヘッダー：[RFC2821]は「受信」については、次の制作を文書：
; From RFC 2821 With = "WITH" FWS Protocol CFWS Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
; / Attdl-プロトコルFWSプロトコルCFWSプロトコル= "ESMTP" / "SMTP" "WITH" =とRFC 2821から
Additionally, [RFC2822] defines a comment field as follows:
次のように加えて、[RFC2822]はコメントフィールドを定義しています。
; From RFC 2822 comment = "(" *([FWS] ccontent) [FWS] ")" ccontent = ctext / quoted-pair / comment
; RFC 2822コメント= "（" *（[FWS] CCONTENT）[FWS] "）" CCONTENT = CTEXT /引用されたペア/コメントから
The "Mail-From-Solicit-Parameter" defined in Section 2.3 above is a restricted form of ctext, yielding the following production:
「メール-から-要請-パラメータ」上記セクション2.3で定義されているが、次の生産をもたらす、CTEXTの制限された形です。
With-Solicit = "WITH" FWS Protocol "(" [FWS] comment [FWS] ")" comment = "(" *([FWS] ccontent) [FWS] ")" ccontent = ctext / quoted-pair / comment / Mail-From-Solicit-Parameter
FWSプロトコル "（" [FWS]コメント[FWS] "）" コメント= "（" *（[FWS] CCONTENT）[FWS] "）" CCONTENT = CTEXT /引用されたペア/コメント/ "WITH" =-要請してメール-から-要請-パラメータ
; The Mail-From-Solicit-Parameter
; is a restricted form of ctext
An example of a Received: header from a conforming MTA is as follows:
受信の例：次のように準拠したMTAからヘッダがあります。
Received: by foo-mta.example.com with ESMTP (SOLICIT=net.example:ADV,org.example:ADV:ADLT) ; Sat, 9 Aug 2003 16:54:42 -0700 (PDT)
受信された：（：ADV、org.example：ADV：SOLICIT = net.example ADLT）foo-mta.example.com ESMTPとすることにより、土、2003年8月9日夜04時54分42秒-0700（PDT）
It should be noted that keywords presented in trace fields may not agree with those found in the "Solicitation:" header and trace fields may exist even if the header is not present. When determining which keywords are applicable to a particular exchange of messages, implementors SHOULD examine any keywords found in the "Solicitation:" header. Implementors MAY examine other keywords found in the trace fields.
「勧誘：」ヘッダおよびトレースフィールドは、ヘッダーが存在しない場合であっても存在する可能性があることは、トレースフィールドに提示したキーワードがで見つかったものと一致しないことに留意すべきです。ヘッダ：キーワードは、メッセージの特定の交換に適用可能であるかを決定する場合、実装は、「勧誘」に見出される任意のキーワードを調べる必要があります。実装者は、トレースフィールドで見つかった他のキーワードを調べることができます。
The "NO-SOLICITING" service extension, if present, applies to all messages handled by the receiving Message Transfer Agent (MTA), including those messages intended to be relayed to another system.
「NO-勧誘」サービス拡張は、存在する場合、別のシステムに中継されることを意図し、それらのメッセージを含む受信メッセージ転送エージェント（MTA）によって処理されるすべてのメッセージに適用されます。
Solicitation class keywords supplied by a client on a "SOLICIT" parameter on a "MAIL FROM" command SHOULD be obtained from the "Solicitation:" field in the message header. An SMTP client SHOULD, however, verify that the list of solicitation class keywords obtained from the "Solicitation:" field uses valid syntax before conveying its contents. An SMTP server SHOULD set this parameter after detecting the presence of the "Solicitation:" header field when receiving a message from a non-conforming MTA.
メッセージヘッダ内のフィールド：コマンド「FROM MAIL」の「SOLICIT」パラメータにクライアントによって供給された勧誘クラスキーワードは、「勧誘」から得られるべきです。フィールドには、その内容を伝える前に、有効な構文を使用します。SMTPクライアントが、しかし、勧誘クラスのキーワードのリストは、「勧誘」から得たことを確認する必要があります。不適合MTAからメッセージを受信するヘッダフィールド：SMTPサーバは「勧誘」の存在を検出した後、このパラメータを設定する必要があります。
Implementations of "NO-SOLICITING" service extension SHOULD NOT enable specific solicitation class keywords as a default in their software. There are some indications that some policy makers may view a default filtering in software as a prior restraint on commercial speech. In other words, because the person installing and using the software did not make an explicit choice to enable a certain type of filtering, some might argue that such filtering was not desired.
「NO-勧誘」サービス拡張の実装は、ソフトウェアでデフォルトとして特定の勧誘クラスのキーワードを有効にしないでください。いくつかの政策立案者は、商業スピーチの事前抑制のようなソフトウェアでは、デフォルトのフィルタリングを見ることができるいくつかの兆候があります。ソフトウェアのインストールと使用者がフィルタリングの特定のタイプを有効にするには、明示的な選択をしていなかったので、他の言葉では、いくつかは、そのようなフィルタリングが希望されなかったことを主張するかもしれません。
Likewise, it is recommended that a system administrator installing software SHOULD NOT enable additional per-recipient filtering by default for a user. Again, individual users should specifically request any additional solicitation class keywords.
同様に、ソフトウェアをインストールするシステム管理者はユーザーのデフォルトによる追加受信者ごとのフィルタリングを有効にしないことをお勧めします。ここでも、個々のユーザーは、特に追加の勧誘クラスのキーワードを要求しなければなりません。
The mechanism for an individual user to communicate their desire to enable certain types of filtering is outside the scope of this document.
フィルタリングの特定のタイプを有効にする意欲を通信するために、個々のユーザのための機構は、この文書の範囲外です。
This extension does not provide authentication of senders or other measures intended to promote security measures during the message exchange process.
この拡張は、送信者やメッセージ交換プロセス中にセキュリティ対策を推進することを目的とその他の措置の認証を提供しません。
In particular, this document does not address the circumstances under which a sender of electronic mail should or should not use this extension and does not address the issues of whether consent to send mail has been granted.
特に、この文書は、電子メールの送信者がまたはこの拡張機能を使用すべきでないとメールを送信するための同意が付与されたかどうかの問題に対処していないれる状況には対応していません。
This might lead to a scenario in which a sender of electronic mail begins to use this extension well before the majority of end users have begun to use it. In this scenario, the sender might wish to use the absence of the extension on the receiving MTA as an implication of consent to receive mail. Non-use of the "NO-SOLICITING" extension by a receiving MTA SHALL NOT indicate consent.
これは、電子メールの送信者がエンドユーザーの大多数がそれを使用し始めているだけでなく前に、この拡張機能を使用し始めているシナリオにつながる可能性があります。このシナリオでは、送信者がメールを受信するために同意の意味合いとして受信MTAの延長の不在を使用したい場合があります。受信側MTAによる「NO-勧誘」拡張子の不使用は、同意を示すないものとします。
There are three IANA considerations presented in this document:
この文書の3つのIANAの考慮事項があります。
1. Addition of the "NO-SOLICITING" service extension to the Mail Parameters registry.
メールのパラメータレジストリに「NO-勧誘」サービス拡張の1.追加。
The IANA Mail Parameters registry documents SMTP service extensions. The "NO-SOLICITATION" service extension has been added to this registry as follows.
IANAメールパラメータのレジストリ文書のSMTPサービス拡張。以下のように「NO-勧誘」サービス拡張は、このレジストリに追加されました。
Keywords Description Reference
------------ ------------------------------ ---------
NO-SOLICITING Notification of no soliciting. RFC3865
The parameters subregistry would need to be modified as follows:
以下のようなパラメータは、副登録を変更する必要があります：
Service Ext EHLO Keyword Parameters Reference
----------- ------------ ----------- ---------
No Soliciting NO-SOLICITING Solicitation-keywords RFC3865
The maximum length of Solicitation-keywords is 1000 characters. The "SOLICIT=" parameter is defined for use on the MAIL FROM command. The potential length of the MAIL FROM command is thus increased by 1007 characters.
勧誘-キーワードの最大長は1000文字です。 「SOLICIT =」パラメータはMAIL FROMコマンドで使用するために定義されています。 MAIL FROMコマンドの潜在的な長さは、このように1007の文字によって増加します。
The Mail Parameters registry would need to be modified to note the use of the comment facility in trace fields to indicate Solicitation Class Keywords.
メールパラメータレジストリは要請クラスのキーワードを示すためのトレースフィールドでのコメント機能の使用を注意するように変更する必要があります。
Per [RFC3864], the "Solicitation:" header field is added to the IANA Permanent Message Header Field Registry. The following is the registration template:
[RFC3864]、「勧誘：」ヘッダフィールドはIANA永久メッセージヘッダフィールドのレジストリに追加されます。以下は、登録テンプレートです：
o Header field name: Solicitation o Applicable protocol: mail o Status: standard o Author/Change controller: IETF o Specification document(s): RFC3865 o Related information:
Oヘッダフィールド名：該当プロトコルO勧誘：メールOステータス：標準のO作者/変更コントローラ：IETF O仕様文書（S）：関連情報O RFC3865：
The author would like to thank Rebecca Malamud for many discussions and ideas that led to this proposal and to John C. Klensin and Marshall T. Rose for their extensive input on how it could be properly implemented in SMTP. Eric Allman, Harald Alvestrand, Steven M. Bellovin, Doug Barton, Kent Crispin, Dave Crocker, Ned Freed, Curtis Generous, Arnt Gulbrandsen, John Levine, Keith Moore, Hector Santos, Ted Hardie, Paul Vixie, and Pindar Wong kindly provided reviews of the document and/or suggestions for improvement. Information about soliciting outside the U.S. was received from Rob Blokzijl, Jon Crowcroft, Christian Huitema, Geoff Huston, and Pindar Wong. John Levine pointed out the contrast between this proposal and "do not spam" lists. As always, all errors and omissions are the responsibility of the author.
著者は、それが適切にSMTPで実施することができる方法についての彼らの豊富な入力のために、この提案に、ジョンC. KlensinとマーシャルT.ローズにつながった多くの議論やアイデアのためのレベッカマラマッドに感謝したいと思います。エリック・オールマン、ハラルドAlvestrand、スティーブンM. Bellovin氏、ダグ・バートン、ケントクリスピン、デイブ・クロッカー、ネッドフリード、カーティスは、寛大な、ARNT Gulbrandsenの、ジョン・レヴァイン、キースムーア、ヘクターサントス、テッドハーディー、ポール・ヴィクシー、およびピンダロスウォンは親切にレビューを提供しました文書および/または改善のための提案。米国外の勧誘に関する情報はロブ・ブロックゼヒ、ジョンクロウクロフト、クリスチャンのHuitema、ジェフ・ヒューストン、およびピンダロスウォンから受信しました。ジョン・レヴァインは、この提案の間のコントラストを指摘し、「ないスパム」のリスト。いつものように、すべてのエラーや脱落は、著者の責任です。
[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月。
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821] Klensin、J.、エド。、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[RFC3463]ヴォードルイユ、G.、 "強化されたメールシステムステータスコード"、RFC 3463、2003年1月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864] Klyne、G.、ノッティンガム、M.、およびJ.モーグル、BCP 90、RFC 3864、2004年9月 "メッセージヘッダフィールドの登録手順"。
[Assassin] Mason, J., "Spamassassin - Mail Filter to Identify Spam Using Text Analysis", Version 2.55, May 2003, <http://www.mirror.ac.uk/sites/spamassassin.taint.org/ spamassassin.org/doc/spamassassin.html>
[アサシン]メイソン、J.、 "Spamassassinが - テキスト分析を使用してスパムを識別するために、メールフィルタ"、バージョン2.55、2003年5月、<http://www.mirror.ac.uk/sites/spamassassin.taint.org/ spamassassinの。 ORG / DOC / spamassassin.html>
[CNET] CNET News.Com, "AOL touts spam-fighting prowess", April 2003, <http://news.com.com/2100-1025-998944.html>.
[CNET] CNET News.Com、 "AOLは、スパムの戦いの腕前を売り込んで" 2003年4月、<http://news.com.com/2100-1025-998944.html>。
[Cantwell] U.S. Supreme Court, "Cantwell v. State of Connecticut", 310 U.S. 296 (1940), May 1940, <http://caselaw.lp.findlaw.com/scripts/ getcase.pl?court=US&vol=310&invol=296>
[キャントウェル】米国最高裁判所、 "コネチカットのキャントウェル対国家"、310米国296（1940）、1940年5月、<http://caselaw.lp.findlaw.com/scripts/ getcase.pl?court=US&vol=310&invol = 296>
[FTC] Federal Trade Commission, "Federal, State, Local Law Enforcers Target Deceptive Spam and Internet Scams", November 2002, <http://www.ftc.gov/opa/2002/11/nenetforcema.htm>.
[FTC]米連邦取引委員会、「連邦、州、地方の法律エンフォーサターゲット欺瞞スパムやインターネット詐欺」、2002年11月、<http://www.ftc.gov/opa/2002/11/nenetforcema.htm>。
[FTC.TSR] Federal Trade Commission, "Telemarketing Sales Rule", Federal Register Vol. 68, No. 19, January 2003, <http://www.ftc.gov/os/2002/12/tsrfinalrule.pdf>.
[FTC.TSR]米連邦取引委員会、「電話勧誘販売ルール」、官報巻。 68、第19号、2003年1月、<http://www.ftc.gov/os/2002/12/tsrfinalrule.pdf>。
[Ferris] Associated Press, "Study: Spam costs businesses $13 billion", January 2003, <http://www.cnn.com/2003/TECH/biztech/01/03/ spam.costs.ap/index.html>
[観覧] AP通信、 "スタディ：迷惑メールが企業に$ 13億のコスト"、2003年1月、<http://www.cnn.com/2003/TECH/biztech/01/03/ spam.costs.ap / index.htmlを>
[Habeas] Habeas, Inc., "Habeas Compliance Message", 2004, <http://www.habeas.com/servicesComplianceStds.html>
[人身保護]人身保護、株式会社、 "人身保護コンプライアンス・メッセージ"、2004年、<http://www.habeas.com/servicesComplianceStds.html>
[crocker-spam-techconsider] Crocker, D., "Technical Considerations for Spam Control Mechanisms", Work in Progress, February 2004.
[クロッカースパム-techconsider]クロッカー、D.、「スパム制御機構のための技術的考察」、進歩、2004年2月に作業。
[crouzet-amtp] Crouzet, B., "Authenticated Mail Transfer Protocol", Work in Progress, May 2004.
[メーカーCrouzet-amtp]メーカーCrouzet、B.、 "認証メール転送プロトコル"、進歩、2004年5月での作業。
[daboo-sieve-spamtest] Daboo, C., "SIEVE Spamtest and Virustest Extensions", Work in Progress, October 2003.
[daboo-ふるい-はspamtest] Daboo、C.、 "SIEVEはspamtestとVirustest拡張機能"、進歩、2003年10月に作業。
[danisch-dns-rr-smtp] Danisch, H., "The RMX DNS RR and method for lightweight SMTP sender authorization", Work in Progress, August 2004.
[デンマークの特許-DNS-RR-SMTP]デンマークの特許、H.、 "RMX DNS RRと軽量SMTP送信者認証のための方法"、進歩、2004年8月の作業は。
[Levine] Levine, J. and P. Hoffman, "Anti-UBE and Anti-UCE Keywords in SMTP Banners", Revision 1.1, March 1999, <http://www.cauce.org/proposal/smtp-banner-rfc.shtml>.
[レヴァイン]レヴァイン、J.および "SMTPバナーにおける抗UBEやアンチUCEキーワード" P.ホフマン、リビジョン1.1、1999年3月、<http://www.cauce.org/proposal/smtp-banner-rfc .shtmlの>。
[Malamud] Malamud, C., "An Internet Prayer Wheel", Mappa.Mundi Magazine, August 1999, <http://mappa.mundi.net/cartography/Wheel/>.
[マラマッド]マラマッド、C.、 "インターネットの祈りの輪"、ppa.Mundi誌、1999年8月、<http://mappa.mundi.net/cartography/Wheel/>。
[Martin] U.S. Supreme Court, "Martin v. City of Struthers, Ohio", 319 U.S. 141 (1943), May 1943, <http://caselaw.lp.findlaw.com/scripts/ getcase.pl?court=US&vol=319&invol=141>
[マーチン]米国最高裁判所、 "Struthers、オハイオ州のマーティンV。市"、319米国141（1943）、1943年5月、<http://caselaw.lp.findlaw.com/scripts/ getcase.pl?court=US&vol = 319＆invol = 141>
[Newbury] The Town of West Newbury, Massachusetts, "Soliciting/ Canvassing By-Law", Chapter 18 Section 10, March 2002, <http://www.town.west-newbury.ma.us/Public_Documents/ WestNewburyMA_Bylaws/000A1547-70E903AC>
[ニューベリー]ウェスト・ニューベリー、マサチューセッツ州、 "条例募集/遊説" の町、第18章10節、2002年3月、<http://www.town.west-newbury.ma.us/Public_Documents/ WestNewburyMA_Bylaws / 000A1547 -70E903AC>
[Perry] U.S. Supreme Court, "Perry Education Association v. Perry Local Educators' Association", 460 U.S. 37 (1983), February 1983, <http://caselaw.lp.findlaw.com/scripts/ getcase.pl?court=US&vol=460&invol=37>
[ペリー】米国最高裁判所、「ペリー教育協会の対ペリー地方教育協会」、460米国37（1983）、1983年2月、<http://caselaw.lp.findlaw.com/scripts/ getcase.pl?court = US＆巻= 460＆invol = 37>
[RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP 30, RFC 2505, February 1999.
[RFC2505]リンドバーグ、G.、 "SMTP MTAのアンチスパムの提言"、BCP 30、RFC 2505、1999年2月。
[ROKSO] Spamhaus.Org, "Register of Known Spam Operations", November 2003, <http://www.spamhaus.org/rokso/index.lasso>.
[ROKSO] Spamhaus.Org、 "既知のスパム事業の登録"、2003年11月、<http://www.spamhaus.org/rokso/index.lasso>。
[Schumer] Charles, C., "Schumer, Christian Coalition Team Up to Crack Down on Email Spam Pornography", June 2003, <http:// www.senate.gov/~schumer/SchumerWebsite/pressroom/ press_releases/PR01782.html>.
[シューマー]チャールズ、C.、 "シューマー、キリスト教の連合チームアップは、電子メールのスパムポルノを取り締まるために"、2003年6月、<のhttp：// www.senate.gov/~schumer/SchumerWebsite/pressroom/ press_releases / PR01782.html >。
[Watchtower] U.S. Supreme Court, "Watchtower Bible & Tract Society of New York, Inc., et al. v. Village of Stratton et al.", 122 S.Ct. 2080 (2002), June 2002, <http://caselaw.lp.findlaw.com/scripts/ getcase.pl?court=US&vol=000&invol=00-1737>
[ものみの塔]米国最高裁判所、「ニューヨーク社、ストラットンらのらV。村のものみの塔聖書＆トラクト社会」、122 S.Ct. 2080（2002）、2002年6月、<http://caselaw.lp.findlaw.com/scripts/ getcase.pl?court=US&vol=000&invol=00-1737>
Appendix A. Collected ABNF Descriptions (Normative)
付録A.収集ABNFの説明（規範）
Solicitation-keywords = word 0*("," word) ; length of this string is limited ; to <= 1000 characters word = ALPHA 0*(wordchar) wordchar = ("." / "-" / "_" / ":" / ALPHA / DIGIT)
勧誘-キーワード=ワード0 *（ "" 言葉）。この文字列の長さが限られています。 （ "" - "：" / ALPHA / DIGIT "" / "_" / /）<= 1000文字・ワード= ALPHA 0 *（wordchar）wordchar =へ
; used in the initial EHLO exchange No-Soliciting-Service = "NO-SOLICITING" [ SP Solicitation-keywords ]
;初期EHLO交換に使用される無募集・サービス= "NO-勧誘" [SP要請-キーワード]
; used on the Solicitation: message header Solicitation-header = "Solicitation:" 1*SP Solicitation-keywords
;メッセージヘッダ要請ヘッダー=「要請：」1 * SPの要請-キーワード勧誘に使用
; used on the MAIL FROM command and replies, ; and on Received: headers. Mail-From-Solicit-Parameter = "SOLICIT" "=" Solicitation-keywords ; Solicitation-keywords, when used in ; the MAIL FROM command MUST be identical ; to those in the Solicitation: header.
;コマンドと応答、FROM MAILで使用されます。とに受付：ヘッダを。メール-から-要請-パラメータ= "SOLICIT" "=" 勧誘-キーワード。で使用勧誘-キーワード; MAIL FROMコマンドは同じでなければなりません。ヘッダ：勧誘のものと。
; Used on Received: headers With-Solicit = "WITH" FWS Protocol "(" [FWS] comment [FWS] ")" ; From RFC 2822 comment = "(" *([FWS] ccontent) [FWS] ")" ccontent = ctext / quoted-pair / comment / Mail-From-Solicit-Parameter ; The Mail-From-Solicit-Parameter ; is a restricted form of ctext ; From RFC 2821 With = "WITH" FWS Protocol CFWS Protocol = "ESMTP" / "SMTP" / Attdl-Protocol Attdl-Protocol = Atom
;受信に使用される：FWSプロトコル "（" [FWS] [FWS]コメント "）" "WITH" =-要請によるヘッダー。 RFC 2822からのコメント= "（" *（[FWS] CCONTENT）[FWS] "）" CCONTENT = CTEXT /引用対/コメント/メール-から-要請-パラメータ;メール-から-要請 - パラメータ; CTEXTの制限された形です。 FWSプロトコルCFWSプロトコル= "ESMTP" / "SMTP" / Attdl-プロトコルAttdl-プロトコル=アトム "WITH" =とRFC 2821から
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 (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎と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機能のための基金は現在、インターネット協会によって提供されます。