RFC 6430 - Email Feedback Report Type Value: not-spam 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6430
タイトル : RFC 6430 - 電子メールフィードバックレポートタイプ値：スパムではありません
翻訳編集 : 自動生成

[要約] RFC 6430は、電子メールのフィードバックレポートタイプ値「not-spam」に関するものです。このRFCの目的は、電子メールのスパムフィルタリングシステムによって判定されたメッセージがスパムではないことを示すための値を定義することです。

Internet Engineering Task Force (IETF)                             K. Li
Request for Comments: 6430                                      B. Leiba
Category: Standards Track                            Huawei Technologies
ISSN: 2070-1721                                            November 2011

Email Feedback Report Type Value: not-spam

電子メールフィードバックレポートタイプ値：スパムではありません

Abstract

概要

This document defines a new Abuse Reporting Format (ARF) feedback report type value: "not-spam". It can be used to report an email message that was mistakenly marked as spam.

このドキュメントでは、新しい悪用レポート形式（ARF）フィードバックレポートタイプ値「Not-Spam」を定義します。スパムと誤ってマークされた電子メールメッセージを報告するために使用できます。

Status of This Memo

本文書の位置付け

This is an Internet Standards Track document.

これは、インターネット標準トラックドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6430.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6430で取得できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。

Table of Contents

   1. Introduction ....................................................2
      1.1. Discussion .................................................2
   2. Feedback Report Type: not-spam ..................................3
   3. Example .........................................................3
   4. Security Considerations .........................................5
   5. IANA Considerations .............................................6
   6. Acknowledgements ................................................6
   7. References ......................................................6
      7.1. Normative References .......................................6
      7.2. Informative References .....................................6

1. Introduction

1. はじめに

In RFC 5965 [RFC5965], an Abuse Reporting Format (ARF) is defined for reporting email abuse. Currently, two feedback report types are defined that are related to the spam problem and that can be used to report abusive or fraudulent email messages:

RFC 5965 [RFC5965]では、電子メールの乱用を報告するために、乱用報告書（ARF）が定義されています。現在、スパム問題に関連する2つのフィードバックレポートタイプが定義されており、虐待的または詐欺的な電子メールメッセージを報告するために使用できます。

o abuse: indicates unsolicited email or some other kind of email abuse.

o 悪用：未承諾の電子メールまたは他の種類の電子メールの乱用を示します。

o fraud: indicates some kind of fraud or phishing activity.

o 詐欺：ある種の詐欺またはフィッシング活動を示します。

This specification defines a new feedback report type: "not-spam". It can be used to report a message that was mistakenly marked as spam.

この仕様では、新しいフィードバックレポート「Not-Spam」タイプを定義します。スパムと誤ってマークされたメッセージを報告するために使用できます。

1.1. Discussion

1.1. 考察

In some cases, the email client receives an email message that was incorrectly tagged as spam, perhaps by the email system, or accidentally by the user. The email client accepts the end user's "not-spam" report instruction, retrieves information related to the message, and reports this email as not-spam to the email operator. When the email operator receives the report, it can determine what action is appropriate for the particular message and user. (The requirement for a not-spam report type is from the Open Mobile Alliance (OMA) Spam Report Requirement Document [OMA-SpamRep-RD].)

場合によっては、電子メールクライアントは、おそらく電子メールシステムによって、またはユーザーが偶然にスパムとして誤ってタグ付けされた電子メールメッセージを受信します。電子メールクライアントは、エンドユーザーの「非スパム」レポート命令を受け入れ、メッセージに関連する情報を取得し、このメールを電子メールオペレーターに非スパムとして報告します。電子メールオペレーターがレポートを受信すると、特定のメッセージとユーザーに適切なアクションを決定できます。（非スパムレポートタイプの要件は、Open Mobile Alliance（OMA）SPAMレポート要件ドキュメント[OMA-SPAMREP-RD]からのものです。）

For example, in response to a "not-spam" report, the email system can remove the spam tag or otherwise reclassify the message, possibly preventing similar email for this user from being marked as spam in the future. The report can be used to adjust the training of an automated classifier. After processing the report, the email

たとえば、「スパムではない」レポートに応じて、電子メールシステムはスパムタグを削除したり、メッセージを再分類したり、このユーザーが将来スパムとしてマークされるのを防ぐことができます。レポートは、自動分類器のトレーニングを調整するために使用できます。レポートを処理した後、メール

operator might send a notification to the email client about the processing result (for example, by moving the message from one mailbox to another, such as from "Junk" to "Inbox").

オペレーターは、処理結果について電子メールクライアントに通知を送信する場合があります（たとえば、「ジャンク」から「受信トレイ」までのメッセージをあるメールボックスから別のメールボックスに移動することにより）。

In most cases, "not-spam" reports will probably not be taken on their own, but will be considered along with other information, analysis of the message, etc. Because different users have different needs and different views of what constitutes spam, reports from one user might or might not be applicable to others. And because users might sometimes press a "report not spam" button accidentally, immediate strong action, such as marking all similar messages as "good" based on a single report, is probably not the right approach. Recipients of "not-spam" reports need to consider what's right in their environments.

ほとんどの場合、「スパムではない」レポートはおそらくそれ自体で取得されるのではなく、他の情報、メッセージの分析などとともに考慮されるでしょう。あるユーザーから他のユーザーに適用される場合とそうでない場合があります。また、ユーザーは誤って「レポートではなくレポート」ボタンを押すことがあるため、単一のレポートに基づいて「良い」と同様のメッセージをすべてマークするなど、即時の強いアクションは、おそらく正しいアプローチではありません。「スパムではない」レポートの受信者は、環境で正しいものを考慮する必要があります。

There are anti-spam systems that use (non-standard) "not spam" feedback today. All of them take the reports and mix them with other spam reports and other data, using their own algorithms, to determine appropriate action. In no case do the existing systems use a "not spam" report as an immediate, automatic override.

今日（標準以外の）「スパムではない」フィードバックを使用するアンチスパムシステムがあります。それらはすべて、レポートを採用し、独自のアルゴリズムを使用して他のスパムレポートや他のデータと混合して、適切なアクションを決定します。いかなる場合でも、既存のシステムは、即時の自動オーバーライドとして「スパムではない」レポートを使用します。

The feedback types "abuse" and "not-spam" can be taken as opposites. A mistaken "not-spam" report could be countermanded by a subsequent "abuse" report from the same user, and an operator could consider collected reports of "abuse" and "not-spam" in making future assessments.

フィードバックの種類「乱用」と「非スパム」は、反対としてとることができます。誤った「非スパム」レポートは、同じユーザーからの後続の「乱用」レポートによって対抗することができ、オペレーターは将来の評価を行う際に「乱用」と「非スパム」の収集されたレポートを検討することができます。

2. Feedback Report Type: not-spam

2. フィードバックレポートタイプ：スパムではありません

This document defines a new feedback report type, "not-spam", which extends the Email Feedback Reports specification [RFC5965].

このドキュメントでは、新しいフィードバックレポート「Not-Spam」タイプを定義します。これにより、電子メールフィードバックレポートの仕様[RFC5965]が拡張されます。

In the first MIME part of the feedback report message, the end user or the email client can add information to indicate why the message is not considered as spam -- for example, because the originator or its domain is well known.

フィードバックレポートメッセージの最初のMIME部分では、エンドユーザーまたは電子メールクライアントが情報を追加して、メッセージがスパムと見なされない理由を示すことができます。たとえば、オリジネーターまたはそのドメインがよく知られているためです。

3. Example

3. 例

In the example, Joe, a pharmaceuticals sales representative, has received a message about discount pharmaceuticals. Because that is a frequent subject of spam email, the message has been marked as spam -- incorrectly, in this case. Joe has reported it as "not-spam", and this is an example of the report, shortened (the "[...etc...]" part) for presentation here.

この例では、Pharmaceuticalsの営業担当者であるJoeは、ディスカウント医薬品に関するメッセージを受け取りました。それはスパムメールの頻繁な主題であるため、メッセージはスパムとしてマークされています - この場合は間違っています。ジョーはそれを「スパムではない」と報告しており、これはレポートの例であり、ここでのプレゼンテーションのために短縮（「[...など...など）の部分）が短縮されています。

Note that the message has been signed using DomainKeys Identified Mail (DKIM) [RFC6376] -- a good security practice as suggested in Section 8.2 of RFC 5965 [RFC5965].

このメッセージは、RFC 5965 [RFC5965]のセクション8.2で示唆されているように、優れたセキュリティプラクティスであるDomainkeys Idefied Mail（DKIM）[RFC6376]を使用して署名されていることに注意してください。

      DKIM-Signature: v=1; a=rsa-sha256; s=abuse; d=example.com;
        c=simple/simple; q=dns/txt; i=abusedesk@example.com;
        h=From:Date:Subject:To:Message-ID:MIME-Version:Content-Type;
        bh=iF4dMNYs/KepE0HuwfukJCDyjkduUzZFiaHqO9DMIPU=;
        b=e+BF8DCHFGqCp7/pExleNz7pVaLEoT+uWj/8H9DoZpxFI1vNnCTDu14w5v
          ze4mqJkldudVI0JspsYHTYeomhPklCV4F95GfwpM5W+ziUOv7AySTfygPW
          EerczqZwAK88//oaYCFXq3XV9T/z+zlLp3rrirKGmCMCPPcbdSGv/Eg=
      From: <abusedesk@example.com>
      Date: Thu, 8 Mar 2005 17:40:36 EDT
      Subject: FW: Discount on pharmaceuticals
      To: <abuse@example.net>
      Message-ID: <20030712040037.46341.5F8J@example.com>
      MIME-Version: 1.0

      Content-Type: multipart/report; report-type=feedback-report;
           boundary="part1_13d.2e68ed54_boundary"

      --part1_13d.2e68ed54_boundary
      Content-Type: text/plain; charset="US-ASCII"
      Content-Transfer-Encoding: 7bit

This is an email abuse report for an email message received from IP 192.0.2.1 on Thu, 8 Mar 2005 14:00:00 EDT. For more information about this format please see http://tools.ietf.org/html/rfc5965 Comment: I sell pharmaceuticals, so this is not spam for me.

これは、2005年3月8日のThuのIP 192.0.2.1から受け取った電子メールメッセージの電子メール乱用レポートです。このフォーマットの詳細については、http：//tools.ietf.org/html/rfc5965コメントを参照してください：私はPharmaceuticalsを販売しているので、これは私にとってはスパムではありません。

--part1_13d.2e68ed54_boundary Content-Type: message/feedback-report

-PART1_13D.2E68ED54_BOUNDARY CONTENT-TYPE：メッセージ/フィードバックレポート

Feedback-Type: not-spam User-Agent: SomeGenerator/1.0 Version: 1

フィードバックタイプ：NOT-SPAMユーザーエージェント：SOMEGENERATOR/1.0バージョン：1

--part1_13d.2e68ed54_boundary Content-Type: message/rfc822 Content-Disposition: inline

-PART1_13D.2E68ED54_BOUNDARY CONTENT-TYPE：MESSAGE/RFC822コンテンツ - 分散：インライン

      Received: from mailserver.example.net
           (mailserver.example.net [192.0.2.1])
           by example.com with ESMTP id M63d4137594e46;
           Thu, 08 Mar 2005 14:00:00 -0400
      From: <someone@example.net>
      To: <Undisclosed Recipients>
      Subject: Discount on pharmaceuticals
      MIME-Version: 1.0
      Content-type: text/plain
      Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net
      Date: Thu, 02 Sep 2004 12:31:03 -0500

Hi, Joe. I got a lead on a source for discounts on pharmaceuticals, and I thought you might be interested. [...etc...] --part1_13d.2e68ed54_boundary--

こんにちは、ジョー。私は医薬品の割引の情報源でリードを獲得しました、そして、私はあなたが興味を持っているかもしれないと思いました。[...など...] - Part1_13d.2e68ed54_boundary--

Example 1: not-spam Report

例1：スパムではないレポート

4. Security Considerations

4. セキュリティに関する考慮事項

All of the security considerations from the Email Feedback Reports specification [RFC5965] are inherited here. In addition, the Email Feedback Reports Applicability Statement [MARF-AS] contains important information about trust relationships and other security- and integrity-related aspects of accepting abuse feedback.

電子メールフィードバックレポートの仕様[RFC5965]からのセキュリティ上の考慮事項はすべて、ここで継承されています。さらに、電子メールフィードバックレポートのアプリケーションステートメント[MARF-AS]には、信頼関係や、虐待フィードバックを受け入れることのその他のセキュリティ関連および整合性関連の側面に関する重要な情報が含まれています。

In particular, not-spam reports will likely be used in an attack on a filtering system, reporting true spam as "not-spam". Even in absence of malice, some not-spam reports might be made in error, or will only apply to the user sending the report. Operators need to be careful in trusting such reports, beyond their applicability to the specific user in question.

特に、スパムではないレポートは、フィルタリングシステムへの攻撃で使用される可能性が高く、真のスパムを「非スパム」と報告します。悪意がない場合でも、一部のスパムレポートは誤って行われるか、レポートを送信するユーザーにのみ適用される場合があります。オペレーターは、問題の特定のユーザーへの適用性を超えて、そのようなレポートを信頼することに注意する必要があります。

5. IANA Considerations

5. IANAの考慮事項

IANA has registered the newly defined feedback type name: "not-spam", according to the instructions in Section 7.3 of the base specification [RFC5965].

IANAは、基本仕様[RFC5965]のセクション7.3の指示に従って、新しく定義されたフィードバックタイプ名「Not-Spam」を登録しました。

The following has been added to the "Feedback Report Type Values" registry:

以下は、「フィードバックレポートタイプ値」レジストリに追加されました。

Feedback Type Name: not-spam

フィードバックタイプ名：スパムではありません

Description: Indicates that the entity providing the report does not consider the message to be spam. This may be used to correct a message that was incorrectly tagged or categorized as spam.

説明：レポートを提供するエンティティがメッセージをスパムとは見なさないことを示します。これは、スパムとして誤ってタグ付けまたは分類されたメッセージを修正するために使用できます。

Published in: this document

公開：このドキュメント

Status: current

ステータス：現在

6. Acknowledgements

6. 謝辞

The authors would like to thank Murray S. Kucherawy and Bert Greevenbosch for their discussion and review, and J.D. Falk for suggesting some explanatory text.

著者は、Murray S. KucherawyとBert Greevenboschの議論とレビューに感謝し、J.D。Falkがいくつかの説明テキストを提案してくれたことに感謝します。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, August 2010.

[RFC5965] Shafranovich、Y.、Levine、J。、およびM. Kucherawy、「電子メールフィードバックレポートの拡張形式」、RFC 5965、2010年8月。

7.2. Informative References

7.2. 参考引用

[MARF-AS] Falk, J., "Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)", Work in Progress, September 2011.

[MARF-AS] Falk、J。、「電子メールフィードバックレポートの作成と使用：虐待報告書（ARF）の適用可能性ステートメント」、2011年9月、進行中の作業。

[OMA-SpamRep-RD] Open Mobile Alliance, "Mobile Spam Reporting Requirements", Candidate Version 1.0 OMA-RD-SpamRep-V1_0- 20101123-C, November 2010, <http:// www.openmobilealliance.org/Technical/release_program/docs/ SpamRep/V1_0-20101123-C/ OMA-RD-SpamRep-V1_0-20101123-C.pdf>.

[OMA-SPAMREP-RD]オープンモバイルアライアンス、「モバイルスパムレポート要件」、候補バージョン1.0 OMA-RD-SPAMREP-V1_0- 2010-101123-C、<http：// www.openmobilealliance.org/technical/release_grom/ docs/ spamrep/ v1_0-20101123-c/ oma-rd-spamrep-v1_0-201123-c.pdf>。

[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.

[RFC6376] Crocker、D.、ed。、Hansen、T.、ed。、およびM. Kucherawy、ed。、「Domainkeys Idefied Mail（DKIM）署名」、RFC 6376、2011年9月。

Authors' Addresses

著者のアドレス

Kepeng Li Huawei Technologies Huawei Base, Bantian, Longgang District Shenzhen, Guangdong 518129 P.R. China

Kepeng Li Huawei Technologies Huawei Base、Bantian、Longgang District Shenzhen、Guangdong 518129 P.R. China

   Phone: +86-755-28974289
   EMail: likepeng@huawei.com

Barry Leiba Huawei Technologies

   Phone: +1 646 827 0648
   EMail: barryleiba@computer.org
   URI:   http://internetmessagingtechnology.org/