RFC3865 日本語訳
3865 A No Soliciting Simple Mail Transfer Protocol (SMTP) ServiceExtension. C. Malamud. September 2004. (Format: TXT=40717 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Malamud Request for Comments: 3865 Memory Palace Press Category: Standards Track September 2004
コメントを求めるワーキンググループC.マラマッド要求をネットワークでつないでください: 3865年のメモリ宮殿プレスカテゴリ: 標準化過程2004年9月
A No Soliciting Simple Mail Transfer Protocol (SMTP)
Service Extension
請求していないシンプルメールトランスファプロトコル(SMTP)サービス拡大
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(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.
このドキュメントは本当の世界の「請求していない」サインに同等な電子メールのためにSolicitingシンプルメールトランスファプロトコル(SMTP)に拡大を提案します。 サービス拡大に加えて、新しいメッセージヘッダーと拡大は既存の「受け取られていている」メッセージヘッダーに説明されます。
Malamud Standards Track [Page 1] RFC 3865 No Soliciting September 2004
2004年9月に請求しないマラマッド標準化過程[1ページ]RFC3865
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 スパム世界的流行病。 . . . . . . . . . . . . . . . . . . . 3 1.2. 本当の世界で請求しないこと。 . . . . . . . . . . . . 4 1.3. 請求と電子メールがありません。 . . . . . . . . . . . 5 2. 請求していないSMTPは拡大. . . . . . . . . . . 6 2.1を修理します。 EHLO交換。 . . . . . . . . . . . . . . . . . . . 7 2.2. 懇願クラスキーワード。 . . . . . . . . . . . . . . 7 2.2.1. 懇願のクラスの選択のときに、キーワードに注意してください。 . 8 2.3. コマンドからのメール。 . . . . . . . . . . . . . . . . . 9 2.4. 誤り報告と高められたメール状態は.102.5をコード化します。 懇願メールヘッダ. . . . . . . . . . . . . . . . 10 2.6。 跡の分野. . . 11 2.7への懇願キーワードの挿入。 メッセージのリレー。 . . . . . . . . . . . . . . . . . . . 12 2.8. デフォルト懇願のクラスがありません。 . . . . . . . . . . . . . 12 3. セキュリティ問題. . . . . . . . . . . . . . . . . . . 13 4。 IANA問題. . . . . . . . . . . . . . . . . . . . . 13 4.1。 メールパラメタ登録. . . . . . . . . . . . . . 13 4.2 野原. . . . . . . . . . . . . . . . . . . . . . 14 4.3をたどってください。 懇願メールヘッダ. . . . . . . . . . . . . . 14 5。 作者の承認. . . . . . . . . . . . . . . . . . 14 6。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1。 引用規格. . . . . . . . . . . . . . . . . . 15 6.2。 有益な参照. . . . . . . . . . . . . . . . . 15付録A.はABNF記述(標準の).18作者のアドレスの.18の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 19を集めました。
Malamud Standards Track [Page 2] RFC 3865 No Soliciting September 2004
2004年9月に請求しないマラマッド標準化過程[2ページ]RFC3865
1. Introduction
1. 序論
1.1. The Spam Pandemic
1.1. スパム世界的流行病
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].
別の方法でスパムとして知られている求められていないBulkメール(UBE)はインターネットの最も多くの差し迫った問題の1つとしてなりました。 ビジネスは2003年[フェリー]にしばしば引用された研究がそのスパムであると見積もっていたものに130億ドルを費やすでしょう。 2003年4月に、AOLは、1日[CNET]でUBEの23億7000万の断片を妨げたと報告しました。 そして、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 Whitelistsは知られている非スパマーのリストです。 例えば、Habeas Inc.はばらまかないのに同意した人々のHabeas User List(HUL)を維持します。 メールヘッダーで俳句を含めて、著作権にその小唄に押しつけることによって、彼らは自分達の反のばらまく利用規約[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 スパムフィルターがクライアント側を走らせるか、または無視するサーバ側はwhitelists、ブラックリスト、および原文とヘッダー分析[暗殺者]に基づいてばらまきます。
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のコントロール[医者スパムtechconsider]、SMTPエージェントのための操作上の問題[RFC2505]、およびプロトコルへの様々な拡大のためにサポートUBE識別と[danisch-dns-rr-smtp]をフィルターにかけるのに[crouzet- amtp][最もspamtestにふるいをdabooしている]総合的な技術的な問題を記述します。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることであるべきです。
Malamud Standards Track [Page 3] RFC 3865 No Soliciting September 2004
2004年9月に請求しないマラマッド標準化過程[3ページ]RFC3865
1.2. No Soliciting in the Real World
1.2. 本当の世界で請求しないこと
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].
「どんな外交員や事務弁護士も'Trespassingがありません'か'Solicitingがありません'サインかポスターを表した居住者か企業の構内に入るのは、不法でしょう。」 「所有者が、外交員か事務弁護士を歓迎しないのを示した後に、さらに、外交員か事務弁護士が居住者を無視するように不法であるかビジネス人が懇願指示でないということであるか私財に残っているものとする」[ニューベリー]。
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].
「嘆願者が挑戦しない法令のセクションは居住者が許可証の所有者さえによる懇願を禁止するかもしれない手順を確立します。」 市長がいる'いいえSolicitation Registration Form'をファイルして、また、居住者は彼の所有地、押しかけの外交員の上の'Solicitationがありません'サインがそうするポストをファイルするなら、彼の所有地に入ってください… 「[見張り搭]。」
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
法廷は、州には懇願を規制する無視できない公安理由があるのを一貫して保持しました。 キャントウェルvで。 コネチカット、最高裁判所がそれを保持した、「公的に彼を可能にする前の共同体の見知らぬ人がどんな目的のためにも資金を募集するのを必要とすることによって州が代理をする彼のアイデンティティと彼の権威を証明するために詐欺的な懇願から市民を保護するかもしれない、」
Malamud Standards Track [Page 4] RFC 3865 No Soliciting September 2004
2004年9月に請求しないマラマッド標準化過程[4ページ]RFC3865
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.
「彼が表すことを意味する原因。」[キャントウェル] そして、マーチンvで。 ストルーザーズの市、「強盗は彼らにはしたがって、家が人影がなくて、強盗にとって、熟しているか否かに関係なく、発見する見せかけがあるかもしれないか、またはそれらが後で戻ることができるように構内をかぎ出す目的のために頻繁に外交員のふりをします。」と、法廷は述べました[マーチン]。 公安問題は、対照的に、公安が決して同じくらい多くでない懇願に問題に電話をするために容易にウイルスを渡すことができるところにメールするのにたいへん当てはまります。
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 オランダに、メールボックスに無料の刊行物を預ける習慣があります。そこでは、戸別の懇願が差し迫った問題ではありません。 「スパムがありません」サインの郵便の同等物は、かなり一般的であり、刊行物が望まれていないことに通知します。
1.3. No Soliciting and Electronic Mail
1.3. 請求と電子メールがありません。
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 メッセージが、あるクラスに属すとして適切に特定されて、そのクラスに関するメッセージが望まれていないなら、メッセージの転送を排除できます。 配送の後のフィルタリングよりむしろ、メッセージ転送の除去はネットワーク回線容量、椎間腔、および処理能力を節約できます。
Malamud Standards Track [Page 5] RFC 3865 No Soliciting September 2004
2004年9月に請求しないマラマッド標準化過程[5ページ]RFC3865
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 受信メールTransportエージェント(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 中間的MTAsのための跡の分野は、中間的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.
存在としてメッセージにタグ付けをするメッセージの送付者を許容して、「良い」スパマーは政府の権威、サービスプロバイダーとの許諾契約、または"whitelist"サービスで課されたコンベンションで要件をラベルする法的な内容に従うことができます例えば、アダルト向けの内容があるお節介なコマーシャルメールで。 これらのコンベンションを守らないのを選ぶメールの送付者に関しては、ここで定義された中間的跡の分野で、目的地MTAsは受信されたメッセージに適切な気質を実行できます。
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.
この拡大は、キーワードについて断言するために送付者、MTAs、および受信機に簡単な平均を供給します。 この拡大は認証か同意のどんな問題にも対処しません。
2. The No-Soliciting SMTP Service Extension
2. 請求がないSMTPサービス拡張子
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交換の間、宣言されます。 拡大には、1つの任意のパラメタがあって、ゼロか以上の成るのは懇願クラスキーワードです。 Augmented BNF[RFC2234]で説明されるように記法を使用して、構文は以下の通りです。
No-Soliciting-Service = "NO-SOLICITING"
[ SP Solicitation-keywords ]
サービスに請求するのは「請求がないこと」と等しくはありません。[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"交換の間に提示されるキーワードはこのセッションのときに交換されたすべてのメッセージに適用されます。 追加キーワードがまた、以下でさらに説明されるようにaへの応答の一部として1受取人あたり1個のベースで指定されるかもしれない、「」 コマンドへのRCPT。
Malamud Standards Track [Page 6] RFC 3865 No Soliciting September 2004
2004年9月に請求しないマラマッド標準化過程[6ページ]RFC3865
2.1. The EHLO Exchange
2.1. EHLO交換
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いいえ請求net.example: ADV R: 250 サイズ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」パラメタは懇願クラスキーワードに関する例です。その構文は以下のセクションで説明されます。
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年にジョン・レヴィンとポール・ホフマンによって進められました。 この提案は、求められていない大量のメールが特定のシステムの上で「UCEがありません」キーワード[レヴィン]の使用で禁止されていると指定するのにSMTP挨拶バナーを使用しました。 作者が注意するように、彼らの提案には挨拶バナーの意味論を積みすぎる可能性があります(見てください、例えば、[マラマッド])。また、バナーは他の目的に使用されるかもしれません。
2.2. Solicitation Class Keywords
2.2. 懇願クラスキーワード
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":
サービスのためのデフォルト懇願クラスキーワードが全くありません。 言い換えれば、以下の例は「オプアートがありません」です:
R : 250-NO-SOLICITING
R: 250いいえ請求
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.
上記の例は「オプアートがありません」ですが、それはすべてのメッセージを伝えることを願っていますが、またずっとメッセージごとのベースに関するパラメタを「=に請求してください」に通過したがっているMTAの役に立ちます。 上記の例は、拡張子の使用を呼び出しますが、メッセージのクラスによる少しの制限も示しません。
Malamud Standards Track [Page 7] RFC 3865 No Soliciting September 2004
2004年9月に請求しないマラマッド標準化過程[7ページ]RFC3865
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)
懇願キーワードがWord0*と等しい、(「」、単語)、。 このストリングの長さは限られています。 アルファー0*(wordchar)1000のキャラクタが言い表す<==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未満のキャラクタであるに違いありません。 しかしながら、また、本書では定義された操作に使用される1セットのキーワードが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.
このドキュメントがコロンが逆にされたドメイン名のあとに続いていて始まると懇願クラスキーワードを定義する、(「:」、)、将来のRFCsはこの命名計画と衝突しない追加メカニズムを定義するかもしれません。
2.2.1. Note on Choice of Solicitation Class Keywords
2.2.1. 懇願クラスキーワードの選択に関する注
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
この提案の議論の間、全体で懇願クラスキーワードを片づけて、メカニズムを簡単な論理演算子(例えば、「請求がないはい」、"ADV"または「宇部」)に取り替えるために、いくつかの提案がありました。 論理演算子メカニズムの下では、この拡張子はどんな「はい」か他のラベルのただ一つの定義を採用しなければならないだろうか。
Malamud Standards Track [Page 8] RFC 3865 No Soliciting September 2004
2004年9月に請求しないマラマッド標準化過程[8ページ]RFC3865
means. By using the solicitation class keywords approach, the mail infrastructure remains a neutral mechanism, allowing different definitions to co-exist.
意味します。 懇願クラスキーワードアプローチを使用することによって、異なった定義が共存するのを許容して、メールインフラストラクチャは中立メカニズムのままで残っています。
2.3. The MAIL FROM Command
2.3. コマンドからのメール
"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"がパラメタと定義される、「」 コマンドからのメール。 懇願クラスキーワードの等号とコンマの切り離されたリストは「請求してください」というパラメタのあとに続いています。 このパラメタのための構文は以下の通りです。
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コマンドに使用されるいつ。 Solicitationのそれらと同じでなければなりません: ヘッダー。
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は「請求してください」というパラメタを含むかもしれません。 メッセージが懇願クラスキーワードマッチのため拒絶されているなら、懇願が分類する実現SHOULDエコーは有効です。 詳しい情報については、誤り報告にセクション2.4を見てください。
The receiving system may decide on a per-message basis the appropriate disposition of messages:
受電方式は1メッセージあたり1個のベースでメッセージの適切な気質について決めるかもしれません:
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いいえ請求net.example: ADV S: FROM:<save@example.com に郵送してください、gt;、=org.example:ADV:ADLT Sに請求してください: RCPT TO:<coupon_clipper@moonlink.example.com 、gt;、R: 250 <coupon_clipper@moonlink.example.com 、gt;、… 受取人OK S: RCPT TO:<grumpy_old_boy@example.net 、gt;、R: 550 <grumpy_old_boy@example.net 、gt;、=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.
前の例では、1つのメッセージが拒絶されていたのを示して、受信MTAは「550」ステータスコードを返しました。 また、実現は「550」ステータスメッセージでそのユーザへの現在設定されたキーワードをecho backです。 echo backである懇願クラスキーワードはこの1受取人あたりの懇願クラスキーワードがどう"EHLO"交換で宣言されたベース「net.example: ADV」のクラスを補ったかを例証する「org.example:ADV:ADLT」です。
Malamud Standards Track [Page 9] RFC 3865 No Soliciting September 2004
2004年9月に請求しないマラマッド標準化過程[9ページ]RFC3865
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 SHOULDは初期の"EHLO"交換か1受取人あたり1個のベースの上でそれらのキーワードを宣言します。 同様に、a受信MTA SHOULD NOTがどこをメッセージに渡すか、「懇願:」 初期の"EHLO"交換か1受取人あたり1個のベースの上に提示された懇願クラスキーワードを合わせます。
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で説明されるヘッダー跡の分野。
2.4. Error Reporting and Enhanced Mail Status Codes
2.4. 誤り報告と高められたメールステータスコード
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."
2MTAsの間のセッションが[RFC3463]で定義されるように「請求がない」拡大と高められたメールステータスコードの両方を使用していて、メッセージが「請求してください」というパラメタの存在に基づいて拒絶されると、通常、返す正しいエラーメッセージがある、「5.7、「送付者が目的地に…発信するのに権限を与えられない」と定義された0.1インチ (because) 「ホストか受取人あたりのフィルタリング。」
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]を当てにするべきです。 そのような状況に関する例はクラスによるメッセージにおける割当てかサイズ制限の使用であるかもしれません。 実現が懇願のクラスとそのような限界がいつであるかに基づくメッセージサイズ制限などの限界を課すかもしれない、超過、それら、SHOULDは報告された使用がステータスコードのように何であるかならそれのために限界を当てます。
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.
全部で、ケース、実現SHOULDがaを含んでいる、「郵送、-、パラメタに請求する、」 「550」か他の回答のときに、それはメッセージ配送を拒絶します。 パラメタSHOULDは合っていた懇願クラスキーワードを含んでいます。 合っていた懇願クラスキーワードに加えて、実現は有効な追加懇願クラスキーワードを含むかもしれません。
2.5. Solicitation Mail Header
2.5. 懇願メールヘッダ
Per [RFC2822], a new "Solicitation:" header field is defined which contains one or more solicitation class keywords.
新しい、[RFC2822]、aあたり「懇願:」 ヘッダーフィールドは定義されます(1つ以上の懇願クラスキーワードを含んでいます)。
Solicitation-header = "Solicitation:" 1*SP Solicitation-keywords
懇願ヘッダー=、「懇願:」 1*SP懇願キーワード
Malamud Standards Track [Page 10] RFC 3865 No Soliciting September 2004
2004年9月に請求しないマラマッド標準化過程[10ページ]RFC3865
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: クーポン Clipper <coupon_clipper@moonlink.example.com 、gt;、From: King <save@burntmail.example.com をばらまいてください、gt;、懇願: 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.
いくつかの提案(特に法的なもの)が、「Subject:」におけるキーワードの使用を必要とするのを示しました。 ヘッダー。 「Subject:」で埋め込み情報をゆったり過ごしてください。 ヘッダーは視覚的な合図をエンドユーザに提供するかもしれなくて、それはメール転送エージェントなどのコンピュータ・プログラムのための簡単なセットの手がかりを提供しません。 これが「Subject:」の意味論を積みすぎるので「懇願がありません」メッセージを挨拶バナーに埋め込むのに ヘッダー。 もちろん、両方のメカニズムを使用できない理由が全くなくて、どんな場合でも「懇願:」 ヘッダーは件名のコンテンツに基づく送付者のメール・ユーザー・エージェント(MUA)によって自動的に挿入されるかもしれません。
2.6. Insertion of Solicitation Keywords in Trace Fields
2.6. 跡の分野への懇願キーワードの挿入
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.
「懇願:」 送付クライアントだけに、メールヘッダは利用可能です。 RFCs2821と2822はかなり特定のそんなに中間的なMTAsがメッセージヘッダーを変えないものとします、「受け取った」唯一の例外でことです。 野原をたどってください。 以来、多くの現在のシステムが、迷惑メール、「受け取ったこと」への添加を検出するのに中間的リレーを使用します。 ヘッダーは説明されます。
[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=“WITH" FWSプロトコルCFWSプロトコル="ESMTP"/"SMTP"/プロトコルがあるRFC2821から
Additionally, [RFC2822] defines a comment field as follows:
さらに、[RFC2822]は以下の注釈欄を定義します:
; From RFC 2822
comment = "(" *([FWS] ccontent) [FWS] ")"
ccontent = ctext / quoted-pair / comment
; 引用された「(「*([FWS]ccontent)[FWS]」)」というRFC2822コメント=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]はccontentします)[FWS]」)」という「(「[FWS]コメント[FWS]」)」という“WITH" FWSプロトコルコメント=ccontentが引用されたctext/組の/コメント/と等しい、メール、パラメタに請求してください。
Malamud Standards Track [Page 11] RFC 3865 No Soliciting September 2004
2004年9月に請求しないマラマッド標準化過程[11ページ]RFC3865
; The Mail-From-Solicit-Parameter
; is a restricted form of ctext
; メール、パラメタに請求してください、。 ctextが制限されたフォームがありますか?
An example of a Received: header from a conforming MTA is as follows:
Receivedに関する例: 従う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)
受け取られている: ESMTP(SOLICIT=net.example: ADV、org.example:ADV:ADLT)とfoo-mta.example.com。 土曜日、2003年8月9日16:54:42 -0700(太平洋夏時間)です。
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.
中のものが見つけられていた状態で跡の分野に提示されたキーワードが同意しないかもしれないことに注意されるべきである、「懇願:」 ヘッダーが出席していなくても、ヘッダーと跡の分野はいるかもしれません。 どのキーワードがメッセージの特定の交換に適切であるかを決定するとき、作成者SHOULDが見つけられたどんなキーワードも試験する、「懇願:」 ヘッダー。 作成者は跡の野原で発見される他のキーワードを調べるかもしれません。
2.7. Relay of Messages
2.7. メッセージのリレー
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.
懇願クラスキーワードが「請求してください」というaに関するパラメタでクライアントから供給した、「」 コマンドからのメールを得るべきである、「懇願:」 メッセージヘッダーでは、さばきます。 しかしながら、SMTPクライアントSHOULDが、懇願のリストが得られたキーワードを分類することを確かめる、「懇願:」 コンテンツを伝える前に、分野は有効な構文を使用します。 SMTPサーバーSHOULDがこのパラメタに存在を後に検出させた、「懇願:」 ヘッダーは、非の従うMTAからメッセージを受け取りながら、いつをさばくか。
2.8. No Default Solicitation Class
2.8. デフォルト懇願のクラスがありません。
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.
同様に、ソフトウェアSHOULD NOTをインストールしているシステム管理者がユーザのためにデフォルトで1受取人あたりの追加フィルタリングを可能にするのは、お勧めです。 一方、個々のユーザは明確にどんな追加懇願クラスキーワードも要求するべきです。
Malamud Standards Track [Page 12] RFC 3865 No Soliciting September 2004
2004年9月に請求しないマラマッド標準化過程[12ページ]RFC3865
The mechanism for an individual user to communicate their desire to enable certain types of filtering is outside the scope of this document.
このドキュメントの範囲の外に個々のユーザが、あるタイプのフィルタリングを可能にする彼らの願望を伝えるメカニズムがあります。
3. Security Considerations
3. セキュリティ問題
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による「請求がない」拡張子の非使用は同意について簡単に述べないものとします。
4. IANA Considerations
4. IANA問題
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. aの創造、「懇願:」 メールヘッダ。
4.1. The Mail Parameters Registry
4.1. メールパラメタ登録
The IANA Mail Parameters registry documents SMTP service extensions. The "NO-SOLICITATION" service extension has been added to this registry as follows.
IANAメールParameters登録はSMTPサービス拡張子を記録します。 「懇願がありません」サービス拡大は以下のこの登録に加えられます。
Keywords Description Reference ------------ ------------------------------ --------- NO-SOLICITING Notification of no soliciting. RFC3865
キーワード記述参照------------ ------------------------------ --------- 請求でないののSOLICITING Notificationがありません。 RFC3865
The parameters subregistry would need to be modified as follows:
副登録が以下の通り変更されるために必要とするパラメタ:
Service Ext EHLO Keyword Parameters Reference ----------- ------------ ----------- --------- No Soliciting NO-SOLICITING Solicitation-keywords RFC3865
サービスExt EHLOキーワード・パラメータ参照----------- ------------ ----------- --------- 請求がない懇願キーワードRFC3865に請求しないこと。
Malamud Standards Track [Page 13] RFC 3865 No Soliciting September 2004
2004年9月に請求しないマラマッド標準化過程[13ページ]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.
最大の長さに関するSolicitation-キーワードは1000のキャラクタです。 「=に請求してください」というパラメタはメールにおける使用のためにコマンドから定義されます。 1007のキャラクタがMAIL FROMコマンドの潜在的長さをこのようにして増加させます。
4.2. Trace Fields
4.2. 跡の分野
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.
メールParameters登録は、Solicitation Class Keywordsを示すために跡の分野でのコメント施設の使用に注意するように変更される必要があるでしょう。
4.3. The Solicitation Mail Header
4.3. 懇願メールヘッダ
Per [RFC3864], the "Solicitation:" header field is added to the IANA Permanent Message Header Field Registry. The following is the registration template:
[RFC3864]単位で「懇願:」 ヘッダーフィールドはIANA Permanent Message Header Field Registryに加えられます。 ↓これは登録テンプレートです:
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 Applicableは議定書を作ります: o Statusに郵送してください: 標準のo Author/変化コントローラ: IETF o Specificationは(s)を記録します: RFC3865のo関連情報:
5. Author's Acknowledgements
5. 作者の承認
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、ダグ・バートン、ケントクリスピン、デーヴ・クロッカー、ネッド・フリード、カーティスGenerous、Arnt Gulbrandsen、ジョン・レヴィン、キース・ムーア、ヘクトル・サントス、テッド・ハーディー、ポールVixie、およびピンダロスWongは親切にドキュメント、そして/または、改善提案のレビューを提供しました。 ロブBlokzijl、ジョン・クロウクロフト、クリスチャンのHuitema、ジェフ・ヒューストン、およびピンダロスWongから米国の外で請求することに関する情報を受け取りました。 ジョン・レヴィンはこの提案と「ばらまかないでください」というリストの間のコントラストを指摘しました。 いつものように、すべての過失および怠慢が作者の責任です。
Malamud Standards Track [Page 14] RFC 3865 No Soliciting September 2004
2004年9月に請求しないマラマッド標準化過程[14ページ]RFC3865
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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"、1997年11月のRFC2234。
[RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC
2821, April 2001.
[RFC2821] Klensin、J.、エド、「簡単なメール転送プロトコル」、RFC2821、4月2001日
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
April 2001.
[RFC2822] レズニック、P.、エド、「インターネットメッセージ・フォーマット」、RFC2822、4月2001日
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
3463, January 2003.
[RFC3463] ボードルイ、G.、「高められたメールシステムステータスコード」、RFC3463、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.ムガール人、「メッセージヘッダーフィールドのための登録手順」BCP90、2004年9月のRFC3864。
6.2. Informative References
6.2. 有益な参照
[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/サイト/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>
[キャントウェル]米国最高裁判所、「キャントウェルv。」 「コネチカット州」、310米国296(1940)、1940年5月、<http://caselaw.lp.findlaw.com/スクリプト/getcase.pl--法廷は米国、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]連邦取引委員会、「テレマーケティング販売は統治する」官報Vol.68、No.19、2003年1月、<http://www.ftc.gov/OS/2002/12/tsrfinalrule.pdf>。
Malamud Standards Track [Page 15] RFC 3865 No Soliciting September 2004
2004年9月に請求しないマラマッド標準化過程[15ページ]RFC3865
[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億ドルをスパムに費やす」<http://www.cnn.com/2003/TECH/biztech/01/03/spam.costs.ap/index.html2003年1月の>。
[Habeas] Habeas, Inc., "Habeas Compliance Message", 2004,
<http://www.habeas.com/servicesComplianceStds.html>
[Habeas]Habeas Inc.、「Habeas承諾メッセージ」、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] クルーゼ、B.、「認証されたメール転送プロトコル」が進歩、2004年5月に働いています。
[daboo-sieve-spamtest]
Daboo, C., "SIEVE Spamtest and Virustest Extensions",
Work in Progress, October 2003.
C.と、「ふるいのSpamtestとVirustest拡張子」という[最もspamtestにふるいをdabooしています]のDabooは進歩、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.と、「軽量のSMTP送付者認可のためのRMX DNS RRと方法」、Progress、8月2004日のWork
[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.とP.ホフマン、「SMTPバナーの反UBEの、そして、反UCEのキーワード」、改正1.1、1999年3月、<smtp-バナーhttp://www.cauce.org/提案/rfc.shtml>。
[Malamud] Malamud, C., "An Internet Prayer Wheel", Mappa.Mundi
Magazine, August 1999,
<http://mappa.mundi.net/cartography/Wheel/>.
[マラマッド]マラマッド、C.、「インターネット地蔵車」、Mappa.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>
[マーチン]米国最高裁判所、「マーチンv。」 「ストルーザーズの市(オハイオ)」、319米国141(1943)、1943年5月、<http://caselaw.lp.findlaw.com/スクリプト/getcase.pl--法廷は米国、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>
[ニューベリー] ウェストニューベリ(マサチューセッツ)「請求/選挙運動内規」の町、WestNewburyMA_内規/000A1547-70 2002年3月<http://www.town.west-newbury.ma.us/公共の_ドキュメント/Eの第18章 セクション10 903AC>。
[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>
[ペリー]米国最高裁判所、「ペリーEducation Association v。」 「ペリー地元の教育者の協会」、1983年の460米国2月37日(1983)に、<http://caselaw.lp.findlaw.com/スクリプト/getcase.pl?法廷は米国、vol=460、およびinvol=37>と等しいです。
Malamud Standards Track [Page 16] RFC 3865 No Soliciting September 2004
2004年9月に請求しないマラマッド標準化過程[16ページ]RFC3865
[RFC2505] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs",
BCP 30, RFC 2505, February 1999.
[RFC2505] リンドバーグ、G.、「SMTP MTAsのための反スパム推薦」、BCP30、RFC2505、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/印刷室/プレスリリース/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>
[見張り搭]米国最高裁判所、「ニューヨークInc.、他vの見張り搭聖書とTract Society。」 「ストラットン他の村」、122 S.Ct。 2080(2002)、2002年6月、<http://caselaw.lp.findlaw.com/スクリプト/getcase.pl--法廷は米国、vol=000、およびinvol=00-1737>と等しいです。
Malamud Standards Track [Page 17] RFC 3865 No Soliciting September 2004
2004年9月に請求しないマラマッド標準化過程[17ページ]RFC3865
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)
懇願キーワードがWord0*と等しい、(「」、単語)、。 このストリングの長さは限られています。 アルファー0*(wordchar)1000のキャラクタが言い表す<==wordchar=に「(「. 」 /「-」/"_"/」: 」 /アルファー/ケタ)
; used in the initial EHLO exchange
No-Soliciting-Service = "NO-SOLICITING"
[ SP Solicitation-keywords ]
; 「請求初期のEHLO交換サービスに請求しない=がないこと」では、使用されます。[SP懇願キーワード]
; used on the Solicitation: message header Solicitation-header = "Solicitation:" 1*SP Solicitation-keywords
; Solicitationで中古: メッセージヘッダーSolicitation-ヘッダー=、「懇願:」 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.
; MAIL FROMコマンドと回答のときに、使用されます。 オンである、受け取られている: ヘッダー。 メール、パラメタに請求してください、= 「請求してください」は懇願キーワードと「等しいです」。 使用されているときの懇願キーワード MAIL FROMコマンドは同じであるに違いありません。 Solicitationのそれらに: ヘッダー。
; 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
; 受け取って、使用される、: ヘッダーはWith請求します。= “WITH" FWSは「(「[FWS]コメント[FWS]」)」について議定書の中で述べます。 引用された「(「*([FWS]はccontentします)[FWS]」)」というRFC2822コメント=ccontent=ctext/組の/コメント/、メール、パラメタに請求してください、。 メール、パラメタに請求してください、。 ctextの制限されたフォームです。 Attdl=“WITH" FWSプロトコルCFWSプロトコル="ESMTP"/"SMTP"/プロトコルAttdl-プロトコル=原子があるRFC2821から
Author's Address
作者のアドレス
Carl Malamud Memory Palace Press PO Box 300 Sixes, OR 97476 US
カールマラマッドメモリ宮殿プレスの私書箱300 6、または97476米国
EMail: carl@media.org
メール: carl@media.org
Malamud Standards Track [Page 18] RFC 3865 No Soliciting September 2004
2004年9月に請求しないマラマッド標準化過程[18ページ]RFC3865
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Malamud Standards Track [Page 19]
マラマッド標準化過程[19ページ]
一覧
スポンサーリンク
