[要約] RFC 3865は、SMTPサービスの拡張である「No Soliciting」についての要約と目的を提供します。この拡張は、不要な広告メールの受信を制限するために使用されます。
Network Working Group C. Malamud
Request for Comments: 3865 Memory Palace Press
Category: Standards Track September 2004
A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension
勧誘されない簡単なメール転送プロトコル（SMTP）サービス拡張機能
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（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.
このドキュメントは、実世界の「勧誘なし」サインに相当する電子メールのために、Simple Mail Transfer Protocol（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）は、インターネット上で最も差し迫った問題の1つになりました。1つのOFT引用研究では、SPAMには2003年に130億ドルの費用がかかると推定されました[フェリス]。2003年4月、AOLは、1日で23億7000万枚のUBEをブロックしたと報告しました[CNET]。そして、Ubeが差し迫った懸念になったという確かな兆候の中で、多くの政治家がこの流行と戦うために宣言と処方箋を発行し始めました[Schumer] [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 ホワイトリストは、既知の非スパンマーのリストです。たとえば、Habeas、Inc。は、スパムをしないことに同意した人のHabeasユーザーリスト（HUL）を維持しています。俳句を電子メールヘッダーに含め、そのDittyに著作権を実施することにより、彼らはアンチスパムサービスの利用規約[Habeas]を実施します。
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 スパムフィルターは、クライアント側またはサーバー側を実行して、ホワイトリスト、ブラックリスト、テキストおよびヘッダー分析[Assassin]に基づいてスパムをフィルタリングします。
o A large number of documents address the overall technical considerations for the control of UBE [crocker-spam-techconsider], operational considerations for SMTP agents [RFC2505], and various extensions to the protocols to support UBE identification and filtering [danisch-dns-rr-smtp][daboo-sieve-spamtest][crouzet-amtp].
o 多数のドキュメントが、UBE [Crocker-Spam-Techconsider]の制御に関する全体的な技術的考慮事項、SMTPエージェントの運用上の考慮事項[RFC2505]、およびUBEの識別とフィルタリングをサポートするプロトコルのさまざまな拡張に取り組んでいます[Danisch-DNS-RRR-smtp] [daboo-sieve-spamtest] [crouzet-amtp]。
o Various proposals have been advanced for "do not spam" lists, akin to the Federal Trade Commission's "Do Not Call" list for telemarketers [FTC.TSR].
o 連邦取引委員会の「Do n't Call」リスト[FTC.TSR]に似た「Do Not Spam」リストについては、さまざまな提案が進められています。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [RFC2119]に記載されているように解釈される。
Municipalities frequently require solicitors to register with the town government. And, in many cases, the municipalities prohibit soliciting in residences where the occupant has posted a sign. The town of West Newbury, Massachusetts, for example, requires:
自治体は、町政府に登録するために弁護士を頻繁に要求します。そして、多くの場合、自治体は、居住者がサインを投稿した住居での勧誘を禁止しています。たとえば、マサチューセッツ州ウェストニューベリーの町には次のことが必要です。
"It shall be unlawful for any canvasser or solicitor to enter the premises of a resident or business who has displayed a 'No Trespassing' or 'No Soliciting' sign or poster. Further, it shall be unlawful for canvassers or solicitors to ignore a resident or business person's no solicitation directive or remain on private property after its owner has indicated that the canvasser or solicitor is not welcome" [Newbury].
「キャンバスターまたは弁護士が、「不法侵入」または「勧誘なし」のサインやポスターを表示した居住者またはビジネスの施設に入ることは違法です。さらに、居住者を無視することは違法です。または、所有者がキャンバスまたは弁護士が歓迎されていないことを示した後、ビジネス担当者の勧誘指令なしまたは私有財産のままです」[Newbury]。
Registration requirements for solicitors, particularly those soliciting for political or religious reasons, have been the subject of a long string of court cases. However, the courts have generally recognized that individuals may post "No Soliciting" signs and the government may enforce the citizen's desire. In a recent case where Jehovah's Witnesses challenged a registration requirement in the city of Stratton, Connecticut, saying they derived their authority from the Scriptures, not the city. However, the court noted:
弁護士の登録要件、特に政治的または宗教的な理由で勧誘する要件は、一連の訴訟の主題でした。しかし、裁判所は一般に、個人が「勧誘」の兆候を投稿しないことを認識しており、政府は市民の欲求を執行することができます。エホバの証人がコネチカット州ストラットン市での登録要件に異議を唱えた最近のケースでは、彼らは都市ではなく聖書から権威を引き出したと言った。しかし、裁判所は次のように述べています。
"A section of the ordinance that petitioners do not challenge establishes a procedure by which a resident may prohibit solicitation even by holders of permits. If the resident files a 'No Solicitation Registration Form' with the mayor, and also posts a 'No Solicitation' sign on his property, no uninvited canvassers may enter his property... " [Watchtower].
「請願者が異議を唱えないという条例のセクションは、居住者が許可証の所有者によってさえ勧誘を禁止する手続きを確立します。居住者が市長に「勧誘登録フォーム」を提出し、「勧誘なし」を投稿する場合彼の財産に署名すると、招待されていないキャンバスが彼の財産に入ることはできません...」[監視塔]。
Even government, which has a duty to promote free expression, may restrict the use of soliciting on government property. In one case, for example, a school district was allowed to give access to its internal electronic mail system to the union that was representing teachers, but was not required to do so to a rival union that was attempting to gain the right to represent the teachers. The court held that where property is not a traditional public forum "and the Government has not dedicated its property to First Amendment activity, such regulation is examined only for reasonableness" [Perry].
自由な表現を促進する義務がある政府でさえ、政府の財産に対する勧誘の使用を制限する可能性があります。たとえば、学区は、教師を代表している組合に内部の電子メールシステムにアクセスできるようにすることが許可されていましたが、それを行う必要はありませんでした。教師。裁判所は、財産が伝統的な公共フォーラムではない場合、政府はその財産を修正第1条の活動に捧げていないと判断したが、そのような規制は合理的でのみ検討されている」[ペリー]。
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.
裁判所は、州が勧誘を規制する説得力のある公共安全理由を持っていると一貫して判断しました。Cantwellv。Connecticutで、最高裁判所は、「国家はコミュニティで見知らぬ人を要求することにより、市民を詐欺的な勧誘から保護することができると判断した。彼が「[Cantwell]」を表すと主張する原因。そして、Martinv。Cityof Struthersで、裁判所は、「強盗は、家が空であるため、強盗のために熟しているか、スパイする目的のために、家が空いているかどうかを発見するふりをするために、キャンバスとして頻繁にポーズをとることが多いと述べました。後で戻ることができるために施設は[Martin]。公共安全の問題は、公共の安全がそれほど問題ではない電話勧誘とは対照的に、ウイルスを簡単に配信できる電子メールに非常に適用されます。
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）が送信MTAに勧誘が有効でないことを信号を送ることができるサービス拡張機能が記載されています。
o A header field for the sender of the message is defined that allows the sender to flag a message as conforming to a certain class.
o メッセージの送信者のヘッダーフィールドが定義されており、送信者が特定のクラスに準拠しているとしてメッセージにフラグを立てることができます。
o Trace fields for intermediate MTAs are extended to allow the intermediate MTA to signal that a message is in a certain class.
o 中間MTAのトレースフィールドは拡張され、中間MTAがメッセージが特定のクラスにあることを示すことができます。
Allowing the sender of a message to tag a message as being, for example, unsolicited commercial email with adult content, allows "good" spammers to conform to legal content labelling requirements by governmental authorities, license agreements with service providers, or conventions imposed by "whitelist" services. For senders of mail who choose not to abide by these conventions, the intermediate trace fields defined here allow the destination MTAs to perform appropriate dispositions on the received message.
メッセージの送信者が、たとえば、アダルトコンテンツを含む未承諾の商用電子メールとしてメッセージをタグ付けすることを許可すると、「良い」スパマーが政府当局による法的コンテンツのラベル付け要件、サービスプロバイダーとのライセンス契約、または課せられた慣習に準拠することができます」ホワイトリスト "サービス。これらの規則を順守しないことを選択したメールの送信者の場合、ここで定義されている中間トレースフィールドにより、宛先MTAが受信したメッセージで適切な処分を実行できます。
This extension provides a simple mean for senders, MTAs, and receivers to assert keywords. This extension does not deal with any issues of authentication or consent.
この拡張機能は、送信者、MTA、および受信機がキーワードを主張するための単純な平均を提供します。この拡張機能は、認証や同意の問題を扱っていません。
Per [RFC2821], a "NO-SOLICITING" SMTP service extension is defined. The service extension is declared during the initial "EHLO" SMTP exchange. The extension has one optional parameter, consisting of zero or more solicitation class keywords. Using the notation as described in the Augmented BNF [RFC2234], the syntax is:
[RFC2821]に従って、「清算なし」SMTPサービス拡張機能が定義されています。サービス拡張機能は、最初の「EHLO」SMTP Exchangeで宣言されます。拡張機能には、ゼロ以上の勧誘クラスのキーワードで構成される1つのオプションのパラメーターがあります。拡張されたBNF [RFC2234]で説明されている表記法を使用すると、構文は次のとおりです。
No-Soliciting-Service = "NO-SOLICITING" [ SP Solicitation-keywords ]
非清涼服装= "lo-soliciting" [SP Solicitation-Keywords]
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.
以下にさらに説明するように、「Solicitation-Keywords」構成は、どのクラスのメッセージが望まれていないかを示すために使用されます。このセッションで交換されたすべてのメッセージに最初の「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
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.
「net.example：adv」パラメーターへの「lo-solicating」拡張機能は、勧誘クラスのキーワードの例であり、その構文は次のセクションで説明します。
Historical Note:
歴史的メモ：
A similar proposal was advanced in 1999 by John Levine and Paul Hoffman. This proposal used the SMTP greeting banner to specify that unsolicited bulk email is prohibited on a particular system through the use of the "NO UCE" keyword [Levine]. As the authors note, their proposal has the potential of overloading the semantics of the greeting banner, which may also be used for other purposes (see, e.g., [Malamud]).
1999年にジョン・レヴァインとポール・ホフマンによって同様の提案が進められました。この提案では、SMTPグリーティングバナーを使用して、「uce no uce」キーワード[Levine]を使用して、特定のシステムで未承諾のバルクメールが禁止されていることを指定しました。著者が指摘しているように、彼らの提案には、グリーティングバナーのセマンティクスを過負荷にする可能性があります。
The "NO-SOLICITING" service extension uses solicitation class keywords to signify classes of solicitations that are not accepted. Solicitation class keywords are separated by commas.
「継続なし」のサービス拡張機能は、勧誘クラスのキーワードを使用して、受け入れられていない勧誘のクラスを意味します。勧誘クラスのキーワードは、コンマで区切られています。
There is no default solicitation class keyword for the service. In other words, the following example is a "no-op":
サービスにデフォルトの勧誘クラスのキーワードはありません。言い換えれば、次の例は「No-op」です。
R : 250-NO-SOLICITING
R：250-No-Soliciting
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」ですが、すべてのメッセージを渡したいが、メッセージごとに「Solict =」パラメーターを渡したい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)
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.
この提案の議論の中で、勧誘クラスのキーワードを完全に廃止し、メカニズムを単純なブール（例：「lo-soliciting yes」または「adv」または「ube」）に置き換えるためのいくつかの提案がありました。ブールメカニズムの下では、この拡張機能は、「はい」または他のラベルの意味の単一の定義を採用する必要があります。Solicitationクラスのキーワードアプローチを使用することにより、メールインフラストラクチャは中立メカニズムのままであり、異なる定義が共存できるようにします。
"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:
「Solict」は、「Mail from」コマンドのパラメーターとして定義されます。「勧誘」パラメーターの後には、等しいサインと勧誘クラスのキーワードのコンマ分離リストが続きます。このパラメーターの構文は次のとおりです。
Mail-From-Solicit-Parameter = "SOLICIT" "=" Solicitation-keywords ; Solicitation-keywords, when used in MAIL FROM command ; MUST be identical to those in the Solicitation: header.
mail-from-solicit-parameter = "Solict" "=" Solicitation-Keywords;solication-keywords、コマンドからメールで使用する場合。勧誘のあるものと同じでなければなりません：ヘッダー。
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」は「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
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」ステータスコードを返し、1つのメッセージが拒否されていることを示しています。また、この実装は、「550」ステータスメッセージでそのユーザーの現在設定されているキーワードを反映しています。バックに反映される勧誘クラスのキーワードは、「org.example：adlt」です。これは、このレシピエントスレイテーションクラスのキーワードが「net.example：adv "クラスが「ehlo」取引所で宣言されたベースを補足した方法を示しています。
It is the responsibility of a receiving MTA to maintain a consistent policy. If the receiving MTA will reject a message because of solicitation class keywords, the MTA SHOULD declare those keywords either in the initial "EHLO" exchange or on a per-recipient basis. Likewise, a receiving MTA SHOULD NOT deliver a message where the "Solicitation:" matches a solicitation class keyword that was presented during the initial "EHLO" exchange or on a per-recipient basis.
一貫したポリシーを維持することは、MTAを受け取る責任です。受信MTAが勧誘クラスのキーワードのためにメッセージを拒否した場合、MTAはこれらのキーワードを最初の「Ehlo」交換で、またはレシピエントごとに宣言する必要があります。同様に、受信MTAは、「Solicitation：」が最初の「Ehlo」交換中またはレシピエントごとに提示された勧誘クラスのキーワードと一致するメッセージを配信してはなりません。
Developers should also note that the source of the solicitation class keywords used in the "MAIL FROM" command MUST be the "Solicitation:" header described in Section 2.5 and MUST NOT be supplemented by additional solicitation class keywords derived from the "Received:" header trace fields which are described in Section 2.6.
また、開発者は、「メールからのメール」コマンドで使用されている勧誘クラスのキーワードのソースは、セクション2.5で説明されているヘッダーである必要があり、「受信」から派生した追加の勧誘クラスのキーワードで補足されないことに注意する必要があります。セクション2.6で説明されているトレースフィールド。
If a session between two MTAs is using both the "NO-SOLICITING" extension and the Enhanced Mail Status Codes as defined in [RFC3463] and a message is rejected based on the presence of a "SOLICIT" parameter, the correct error message to return will usually be "5.7.1", defined as "the sender is not authorized to send to the destination... (because) of per-host or per-recipient filtering."
2つのMTA間のセッションが[RFC3463]で定義されている「要請なし」拡張機能と拡張されたメールステータスコードの両方を使用している場合、「勧誘」パラメーターの存在に基づいてメッセージが拒否された場合、正しいエラーメッセージを返すための正しいエラーメッセージは通常、「5.7.1」であり、「送信者は目的地に送信することは許可されていません...（なぜなら）（なぜなら）（なぜなら）、宿主または相当のフィルタリングのフィルタリング。
Other codes, including temporary status codes, may be more appropriate in some circumstances and developers should look to [RFC3463] on this subject. An example of such a situation might be the use of quotas or size restrictions on messages by class. An implementation MAY impose limits such as message size restrictions based on solicitation classes, and when such limits are exceed they SHOULD be reported using whatever status code is appropriate for that limit.
一時的なステータスコードを含む他のコードは、状況によってはより適切である場合があり、開発者はこの主題について[RFC3463]を検討する必要があります。このような状況の例は、クラスごとのメッセージに対するクォータまたはサイズの制限の使用です。実装は、勧誘クラスに基づいたメッセージサイズの制限などの制限を課す場合があり、そのような制限を超える場合は、その制限に適したステータスコードを使用して報告する必要があります。
In all cases, an implementation SHOULD include a "Mail-From-Solicit-Parameter" on a "550" or other reply that rejects message delivery. The parameter SHOULD includes the solicitation class keyword(s) that matched. In addition to the solicitation class keyword(s) that matched, an implementation MAY include additional solicitation class keywords that are in effect.
すべての場合において、実装には、「550」に「Mail-From-Solicit-Parameter」またはメッセージ配信を拒否するその他の返信を含める必要があります。パラメーターには、一致する勧誘クラスキーワードを含める必要があります。一致する勧誘クラスのキーワードに加えて、実装には、有効な追加の勧誘クラスのキーワードが含まれる場合があります。
Per [RFC2822], a new "Solicitation:" header field is defined which contains one or more solicitation class keywords.
[RFC2822]によると、新しい「勧誘：」ヘッダーフィールドが定義されており、1つ以上の勧誘クラスのキーワードが含まれています。
Solicitation-header = "Solicitation:" 1*SP Solicitation-keywords
An example of this header follows:
このヘッダーの例は次のとおりです。
To: Coupon Clipper <coupon_clipper@moonlink.example.com>
From: Spam King <save@burntmail.example.com>
Solicitation: net.example:ADV,org.example:ADV:ADLT
Several proposals, particularly legal ones, have suggested requiring the use of keywords in the "Subject:" header. While embedding information in the "Subject:" header may provide visual cues to end users, it does not provide a straightforward set of cues for computer programs such as mail transfer agents. As with embedding a "no solicitation" message in a greeting banner, this overloads the semantics of the "Subject:" header. Of course, there is no reason why both mechanisms can't be used, and in any case the "Solicitation:" header could be automatically inserted by the sender's Mail User Agent (MUA) based on the contents of the subject line.
いくつかの提案、特に合法的な提案は、「主題：」ヘッダーでキーワードを使用することを要求することを提案しています。「サブジェクト：」ヘッダーに情報を埋め込むことは、エンドユーザーに視覚的なキューを提供する場合がありますが、メール転送エージェントなどのコンピュータープログラムに簡単なキューセットを提供しません。グリーティングバナーに「勧誘なし」メッセージを組み込むことと同様に、これは「件名：」ヘッダーのセマンティクスを過負荷します。もちろん、両方のメカニズムを使用できない理由はありません。いずれにしても、「勧誘：」ヘッダーは、件名の内容に基づいて送信者のメールユーザーエージェント（MUA）によって自動的に挿入される可能性があります。
The "Solicitation:" mail header is only available to the sending client. RFCs 2821 and 2822 are quite specific that intermediate MTAs shall not change message headers, with the sole exception of the "Received:" trace field. Since many current systems use an intermediate relay to detect unsolicited mail, an addition to the "Received:" header is described.
「勧誘：」メールヘッダーは、送信クライアントのみが利用できます。RFCS 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
Additionally, [RFC2822] defines a comment field as follows:
さらに、[RFC2822]は次のようにコメントフィールドを定義します。
; From RFC 2822
comment = "(" *([FWS] ccontent) [FWS] ")"
ccontent = ctext / quoted-pair / comment
The "Mail-From-Solicit-Parameter" defined in Section 2.3 above is a restricted form of ctext, yielding the following production:
上記のセクション2.3で定義されている「Mail-From-Solicit-Parameter」は、CTextの制限された形式であり、次の生産を生成します。
With-Solicit = "WITH" FWS Protocol
"(" [FWS] comment [FWS] ")"
comment = "(" *([FWS] ccontent) [FWS] ")"
ccontent = ctext / quoted-pair /
comment / Mail-From-Solicit-Parameter
; The Mail-From-Solicit-Parameter ; is a restricted form of ctext
;Mail-From-Solicit-Parameter;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)
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.
Traceフィールドで提示されたキーワードは、「勧誘：」に見られるものに同意しない可能性があることに注意する必要があります。ヘッダーが存在しなくても、ヘッダーとトレースフィールドが存在する可能性があります。どのキーワードがメッセージの特定の交換に適用可能であるかを決定する場合、実装者は「勧誘」にあるキーワード：ヘッダーを調べる必要があります。実装者は、トレースフィールドにある他のキーワードを調べることができます。
The "NO-SOLICITING" service extension, if present, applies to all messages handled by the receiving Message Transfer Agent (MTA), including those messages intended to be relayed to another system.
存在する場合は、「解決なし」サービス拡張機能は、受信メッセージ転送エージェント（MTA）によって処理されたすべてのメッセージに適用されます。
Solicitation class keywords supplied by a client on a "SOLICIT" parameter on a "MAIL FROM" command SHOULD be obtained from the "Solicitation:" field in the message header. An SMTP client SHOULD, however, verify that the list of solicitation class keywords obtained from the "Solicitation:" field uses valid syntax before conveying its contents. An SMTP server SHOULD set this parameter after detecting the presence of the "Solicitation:" header field when receiving a message from a non-conforming MTA.
勧誘クラスのキーワードは、「solicitation： "solicitation："メッセージヘッダーのフィールドから「メール」コマンドの「勧誘」パラメーターでクライアントが提供するキーワードを取得する必要があります。ただし、SMTPクライアントは、「Solicitation：」から得られたSolicitationクラスのキーワードのリストが、コンテンツを伝える前に有効な構文を使用することを確認する必要があります。SMTPサーバーは、「勧誘」の存在を検出した後、このパラメーターを設定する必要があります：非不適合MTAからメッセージを受信したときにヘッダーフィールド。
Implementations of "NO-SOLICITING" service extension SHOULD NOT enable specific solicitation class keywords as a default in their software. There are some indications that some policy makers may view a default filtering in software as a prior restraint on commercial speech. In other words, because the person installing and using the software did not make an explicit choice to enable a certain type of filtering, some might argue that such filtering was not desired.
「解決策」サービス拡張機能の実装は、ソフトウェアのデフォルトとして特定の勧誘クラスのキーワードを有効にしてはなりません。一部の政策立案者は、ソフトウェアのデフォルトのフィルタリングを商業的なスピーチの以前の制限と見なすことができるという兆候がいくつかあります。言い換えれば、ソフトウェアをインストールして使用する人は、特定のタイプのフィルタリングを有効にするために明示的な選択をしなかったため、そのようなフィルタリングは望ましくないと主張する人もいるかもしれません。
Likewise, it is recommended that a system administrator installing software SHOULD NOT enable additional per-recipient filtering by default for a user. Again, individual users should specifically request any additional solicitation class keywords.
同様に、ソフトウェアをインストールするシステム管理者は、ユーザーのデフォルトで追加のレシピエントごとのフィルタリングを有効にしないようにすることをお勧めします。繰り返しますが、個々のユーザーは、追加の勧誘クラスのキーワードを具体的に要求する必要があります。
The mechanism for an individual user to communicate their desire to enable certain types of filtering is outside the scope of this document.
個々のユーザーが特定の種類のフィルタリングを有効にしたいという欲求を伝えるメカニズムは、このドキュメントの範囲外です。
This extension does not provide authentication of senders or other measures intended to promote security measures during the message exchange process.
この拡張機能は、メッセージ交換プロセス中にセキュリティ対策を促進することを目的とした送信者またはその他の測定値の認証を提供しません。
In particular, this document does not address the circumstances under which a sender of electronic mail should or should not use this extension and does not address the issues of whether consent to send mail has been granted.
特に、このドキュメントは、電子メールの送信者がこの拡張機能を使用すべきであるか、または使用すべきではない状況に対処しておらず、メールの送信の同意が許可されているかどうかの問題に対処していない。
This might lead to a scenario in which a sender of electronic mail begins to use this extension well before the majority of end users have begun to use it. In this scenario, the sender might wish to use the absence of the extension on the receiving MTA as an implication of consent to receive mail. Non-use of the "NO-SOLICITING" extension by a receiving MTA SHALL NOT indicate consent.
これにより、エンドユーザーの大部分がそれを使用し始めた前に、電子メールの送信者がこの拡張機能を使用し始めるシナリオにつながる可能性があります。このシナリオでは、送信者は、メールを受信するための同意の意味として、受信MTAに拡張機能の欠如を使用したい場合があります。受信MTAによる「希釈なし」拡張の不使用は、同意を示すものではありません。
There are three IANA considerations presented in this document:
このドキュメントには、3つのIANAの考慮事項が表示されています。
1. Addition of the "NO-SOLICITING" service extension to the Mail Parameters registry.
1. メールパラメーターレジストリに「清算なし」サービス拡張機能を追加します。
2. Documentation of the use of comments in trace fields.
2. トレースフィールドでのコメントの使用のドキュメント。
3. Creation of a "Solicitation:" mail header.
3. 「勧誘」の作成：メールヘッダー。
The IANA Mail Parameters registry documents SMTP service extensions. The "NO-SOLICITATION" service extension has been added to this registry as follows.
IANA Mail ParametersレジストリドキュメントSMTPサービス拡張機能。次のように、このレジストリに「清算なし」サービス拡張機能が追加されました。
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.
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.
Mail Parametersレジストリは、勧誘クラスのキーワードを示すために、Traceフィールドでのコメント機能の使用に注意するために変更する必要があります。
Per [RFC3864], the "Solicitation:" header field is added to the IANA Permanent Message Header Field Registry. The following is the registration template:
[RFC3864]に従って、「勧誘：」ヘッダーフィールドがIANAパーマネントメッセージヘッダーフィールドレジストリに追加されます。以下は登録テンプレートです。
o Header field name: Solicitation o Applicable protocol: mail o Status: standard o Author/Change controller: IETF o Specification document(s): RFC3865 o Related information:
o ヘッダーフィールド名：勧誘o適用可能なプロトコル：メールoステータス：標準o著者/変更コントローラー：ietf o仕様文書：RFC3865 o関連情報：
The author would like to thank Rebecca Malamud for many discussions and ideas that led to this proposal and to John C. Klensin and Marshall T. Rose for their extensive input on how it could be properly implemented in SMTP. Eric Allman, Harald Alvestrand, Steven M. Bellovin, Doug Barton, Kent Crispin, Dave Crocker, Ned Freed, Curtis Generous, Arnt Gulbrandsen, John Levine, Keith Moore, Hector Santos, Ted Hardie, Paul Vixie, and Pindar Wong kindly provided reviews of the document and/or suggestions for improvement. Information about soliciting outside the U.S. was received from Rob Blokzijl, Jon Crowcroft, Christian Huitema, Geoff Huston, and Pindar Wong. John Levine pointed out the contrast between this proposal and "do not spam" lists. As always, all errors and omissions are the responsibility of the author.
著者は、この提案につながった多くの議論とアイデアについて、レベッカ・マラマドに感謝し、ジョン・C・クレンシンとマーシャル・T・ローズにSMTPで適切に実装される方法についての広範なインプットについて。エリック・オールマン、ハラルド・アルベスランド、スティーブン・M・ベロヴィン、ダグ・バートン、ケント・クリスピン、デイブ・クロッカー、ネッド・フリード、カーティス、寛大、アルント・ガルブランドセン、ジョン・レバイン、キース・ムーア、ヘクター・サントス、テッド・ハーディ、ポール・ヴィクシー、ピンダー・ウォンはレビューのレビューを提供しました改善のためのドキュメントおよび/または提案の。米国外での勧誘に関する情報は、ロブ・ブロクジル、ジョン・クロウクロフト、クリスチャン・フイテマ、ジェフ・ヒューストン、ピンダー・ウォンから受け取られました。ジョン・レバインは、この提案と「Do not Spam」リストとのコントラストを指摘しました。いつものように、すべてのエラーと省略は著者の責任です。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234] Crocker、D.、ed。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821] Klensin、J.、ed。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[RFC2822] Resnick、P.、ed。、「インターネットメッセージフォーマット」、RFC 2822、2001年4月。
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[RFC3463] Vaudreuil、G。、「Enhanced Mail System Status Codes」、RFC 3463、2003年1月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864] Klyne、G.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、BCP 90、RFC 3864、2004年9月。
[Assassin] Mason, J., "Spamassassin - Mail Filter to Identify Spam Using Text Analysis", Version 2.55, May 2003, <http://www.mirror.ac.uk/sites/spamassassin.taint.org/ spamassassin.org/doc/spamassassin.html>
[Assassin] Mason、J。、「Spamassassin-テキスト分析を使用してスパムを識別するメールフィルター」、バージョン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 Touts Spam-Fighting Prowess」、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>
[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]連邦取引委員会、「連邦、州、地方の法執行機関は、欺cept的なスパムとインターネット詐欺をターゲットにしている」、2002年11月、<http://www.ftc.gov/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]連邦取引委員会、「テレマーケティング販売規則」、連邦登録簿Vol。68、No。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通信、「調査：スパムコスト事業者130億ドル」、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>
[Habeas] Habeas、Inc。、「Habeas Compliance Message」、2004、<http://www.habeas.com/servicescompliancestds.html>
[crocker-spam-techconsider] Crocker, D., "Technical Considerations for Spam Control Mechanisms", Work in Progress, February 2004.
[Crocker-Spam-Techconsider] Crocker、D。、「スパム制御メカニズムに関する技術的な考慮事項」、2004年2月の作業。
[crouzet-amtp] Crouzet, B., "Authenticated Mail Transfer Protocol", Work in Progress, May 2004.
[Crouzet-Amtp] Crouzet、B。、「認証されたメール転送プロトコル」、2004年5月、進行中の作業。
[daboo-sieve-spamtest] Daboo, C., "SIEVE Spamtest and Virustest Extensions", Work in Progress, October 2003.
[Daboo-Sieve-Spamtest] Daboo、C。、「Sieve Spamtest and Virustest Extensions」、2003年10月の作業。
[danisch-dns-rr-smtp] Danisch, H., "The RMX DNS RR and method for lightweight SMTP sender authorization", Work in Progress, August 2004.
[Danisch-DNS-RR-SMTP] Danisch、H。、「RMX DNS RRおよび軽量SMTP送信者認証の方法」、2004年8月、作業進行中。
[Levine] Levine, J. and P. Hoffman, "Anti-UBE and Anti-UCE Keywords in SMTP Banners", Revision 1.1, March 1999, <http://www.cauce.org/proposal/smtp-banner-rfc.shtml>.
[Levine] Levine、J。and P. Hoffman、「SMTPバナーのアンチューブおよびアンチウースキーワード」、1999年3月、改訂1.1、<http://www.cauce.org/proposal/smtp-banner-rfc.shtml>。
[Malamud] Malamud, C., "An Internet Prayer Wheel", Mappa.Mundi Magazine, August 1999, <http://mappa.mundi.net/cartography/Wheel/>.
[Malamud] Malamud、C。、「インターネットの祈りの輪」、Mappa.Mundi Magazine、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>
[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/000A154747474747474747474747-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>
[RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP 30, RFC 2505, February 1999.
[RFC2505] Lindberg、G。、「SMTP MTASのアンチスパム推奨」、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.htmll>。
[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。ストラットンet al。」、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)
; used in the initial EHLO exchange No-Soliciting-Service = "NO-SOLICITING" [ SP Solicitation-keywords ]
;最初のEhlo Exchange No-Soliciting-Service = "No-Soliciting" [SP Solicitation-Keywords]で使用
; used on the Solicitation: message header
Solicitation-header = "Solicitation:" 1*SP Solicitation-keywords
; used on the MAIL FROM command and replies,
; and on Received: headers.
Mail-From-Solicit-Parameter =
"SOLICIT" "=" Solicitation-keywords
; Solicitation-keywords, when used in
; the MAIL FROM command MUST be identical
; to those in the Solicitation: header.
; Used on Received: headers
With-Solicit = "WITH" FWS Protocol
"(" [FWS] comment [FWS] ")"
; From RFC 2822
comment = "(" *([FWS] ccontent) [FWS] ")"
ccontent = ctext / quoted-pair /
comment / Mail-From-Solicit-Parameter
; The Mail-From-Solicit-Parameter
; is a restricted form of ctext
; From RFC 2821
With = "WITH" FWS Protocol CFWS
Protocol = "ESMTP" / "SMTP" / Attdl-Protocol
Attdl-Protocol = Atom
Author's Address
著者の連絡先
Carl Malamud Memory Palace Press PO Box 300 Sixes, OR 97476 US
Carl Malamud Memory Palace Press Po Box 300 Sixes、または97476 US
EMail: carl@media.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われた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エディター機能の資金は現在、インターネット協会によって提供されています。