| draft-shafranovich-feedback-report-01-pre1.txt | | draft-shafranovich-feedback-report-01.txt | |
| | | | |
| Network Working Group Y. Shafranovich | | Network Working Group Y. Shafranovich | |
| Internet-Draft SolidMatrix Technologies, Inc. | | Internet-Draft SolidMatrix Technologies, Inc. | |
|
| Expires: November 7, 2005 May 6, 2005 | | Expires: November 14, 2005 May 13, 2005 | |
| | | | |
| An Extensible Format for Email Feedback Reports | | An Extensible Format for Email Feedback Reports | |
|
| draft-shafranovich-feedback-report-01-pre1.txt | | draft-shafranovich-feedback-report-01.txt | |
| | | | |
| Status of this Memo | | Status of this Memo | |
| | | | |
|
| This document is an Internet-Draft and is subject to all provisions | | By submitting this Internet-Draft, each author represents that any | |
| of Section 3 of RFC 3667. By submitting this Internet-Draft, each | | applicable patent or other IPR claims of which he or she is aware | |
| author represents that any applicable patent or other IPR claims of | | have been or will be disclosed, and any of which he or she becomes | |
| which he or she is aware have been or will be disclosed, and any of | | aware will be disclosed, in accordance with Section 6 of BCP 79. | |
| which he or she become aware will be disclosed, in accordance with | | | |
| RFC 3668. | | | |
| | | | |
| Internet-Drafts are working documents of the Internet Engineering | | Internet-Drafts are working documents of the Internet Engineering | |
| Task Force (IETF), its areas, and its working groups. Note that | | Task Force (IETF), its areas, and its working groups. Note that | |
| other groups may also distribute working documents as Internet- | | other groups may also distribute working documents as Internet- | |
| Drafts. | | Drafts. | |
| | | | |
| Internet-Drafts are draft documents valid for a maximum of six months | | Internet-Drafts are draft documents valid for a maximum of six months | |
| and may be updated, replaced, or obsoleted by other documents at any | | and may be updated, replaced, or obsoleted by other documents at any | |
| time. It is inappropriate to use Internet-Drafts as reference | | time. It is inappropriate to use Internet-Drafts as reference | |
| material or to cite them other than as "work in progress." | | material or to cite them other than as "work in progress." | |
| | | | |
| The list of current Internet-Drafts can be accessed at | | The list of current Internet-Drafts can be accessed at | |
| http://www.ietf.org/ietf/1id-abstracts.txt. | | http://www.ietf.org/ietf/1id-abstracts.txt. | |
| | | | |
| The list of Internet-Draft Shadow Directories can be accessed at | | The list of Internet-Draft Shadow Directories can be accessed at | |
| http://www.ietf.org/shadow.html. | | http://www.ietf.org/shadow.html. | |
| | | | |
|
| This Internet-Draft will expire on November 7, 2005. | | This Internet-Draft will expire on November 14, 2005. | |
| | | | |
| Copyright Notice | | Copyright Notice | |
| | | | |
| Copyright (C) The Internet Society (2005). | | Copyright (C) The Internet Society (2005). | |
| | | | |
| Abstract | | Abstract | |
| | | | |
| This document defines an extensible format and MIME type that may be | | This document defines an extensible format and MIME type that may be | |
| used by network operators to report feedback about received email to | | used by network operators to report feedback about received email to | |
| other parties. This format is intended as a machine readable | | other parties. This format is intended as a machine readable | |
| | | | |
| skipping to change at page 2, line 13 | | skipping to change at page 2, line 13 | |
| Internet email. | | Internet email. | |
| | | | |
| Table of Contents | | Table of Contents | |
| | | | |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |
| 2. Intent . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | | 2. Intent . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |
| 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 | | 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 | |
| 4. Format of Email Feedback Reports . . . . . . . . . . . . . . 4 | | 4. Format of Email Feedback Reports . . . . . . . . . . . . . . 4 | |
| 5. Format of 'message/feedback-report' Content Type . . . . . . 5 | | 5. Format of 'message/feedback-report' Content Type . . . . . . 5 | |
| 5.1 Required Fields . . . . . . . . . . . . . . . . . . . . . 5 | | 5.1 Required Fields . . . . . . . . . . . . . . . . . . . . . 5 | |
|
| 5.2 Optional Fields Appearing Once . . . . . . . . . . . . . . 5 | | 5.2 Optional Fields Appearing Once . . . . . . . . . . . . . . 6 | |
| 5.3 Optional Fields Appearing Multiple Times . . . . . . . . . 6 | | 5.3 Optional Fields Appearing Multiple Times . . . . . . . . . 6 | |
|
| 6. MIME Type Registration of message/feedback-report . . . . . 6 | | 6. MIME Type Registration of message/feedback-report . . . . . 7 | |
| 7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . 7 | | 7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . 8 | |
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 | | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 | |
| 8.1 Initial Values for the Header Names Registry . . . . . . . 9 | | 8.1 Initial Values for the Header Names Registry . . . . . . . 9 | |
| 8.2 Initial values for the "Feedback-Type" registry . . . . . 10 | | 8.2 Initial values for the "Feedback-Type" registry . . . . . 10 | |
|
| 9. Security Considerations . . . . . . . . . . . . . . . . . . 10 | | 9. Security Considerations . . . . . . . . . . . . . . . . . . 11 | |
| 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 10 | | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11 | |
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 | | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |
| 11.1 Normative References . . . . . . . . . . . . . . . . . . 11 | | 11.1 Normative References . . . . . . . . . . . . . . . . . . 11 | |
|
| 11.2 Informative References . . . . . . . . . . . . . . . . . 11 | | 11.2 Informative References . . . . . . . . . . . . . . . . . 12 | |
| Author's Address . . . . . . . . . . . . . . . . . . . . . . 12 | | Author's Address . . . . . . . . . . . . . . . . . . . . . . 12 | |
|
| A. Appendix A - An Sample Abuse Report . . . . . . . . . . . . 12 | | A. Appendix A - Sample Feedback Reports . . . . . . . . . . . . 12 | |
| B. Status of This Document [To Be Removed Upon Publication] . . 13 | | A.1 Simple Report for Email Abuse without Optional Headers . . 12 | |
| B.1 Discussion Venue . . . . . . . . . . . . . . . . . . . . . 13 | | A.2 Opt-Out Report without Message Body . . . . . . . . . . . 13 | |
| B.2 Document Repository and Public Website . . . . . . . . . . 13 | | A.3 Full Report for Email Abuse with All Headers . . . . . . . 14 | |
| B.3 Document History . . . . . . . . . . . . . . . . . . . . . 13 | | B. Status of This Document [To Be Removed Upon Publication] . . 16 | |
| Intellectual Property and Copyright Statements . . . . . . . 15 | | B.1 Discussion Venue . . . . . . . . . . . . . . . . . . . . . 16 | |
| | | B.2 Document Repository and Public Website . . . . . . . . . . 16 | |
| | | B.3 Document History . . . . . . . . . . . . . . . . . . . . . 16 | |
| | | B.4 Outstanding Issues . . . . . . . . . . . . . . . . . . . . 17 | |
| | | Intellectual Property and Copyright Statements . . . . . . . 19 | |
| | | | |
| 1. Introduction | | 1. Introduction | |
| | | | |
| As the spam problem has grown in the past few years, network | | As the spam problem has grown in the past few years, network | |
| operators have begun to exchange abuse reports among themselves and | | operators have begun to exchange abuse reports among themselves and | |
| other parties to combat this problem. However, different operators | | other parties to combat this problem. However, different operators | |
| define their own formats and the receivers are forced to write custom | | define their own formats and the receivers are forced to write custom | |
| software to interpret the many types of them. In addition, many | | software to interpret the many types of them. In addition, many | |
| operators use various other report formats to provide non-abuse | | operators use various other report formats to provide non-abuse | |
| feedback about processed email. This memo seeks to define a standard | | feedback about processed email. This memo seeks to define a standard | |
| extensible format and the "message/feedback-report" MIME type for | | extensible format and the "message/feedback-report" MIME type for | |
| these reports in accordance with RFC 2048 [11]. This format and | | these reports in accordance with RFC 2048 [11]. This format and | |
| content type is intended to be used within the scope of the framework | | content type is intended to be used within the scope of the framework | |
| of the "multipart/report" content type defined in RFC 3462 [1]. | | of the "multipart/report" content type defined in RFC 3462 [1]. | |
|
| | | While there have been previous work in this area([12] and [13]), none | |
| | | of them have yet been sucessful. It is hoped that this document will | |
| | | have a better fate. | |
| | | | |
| | | This format is intended primarily as an Abuse Reporting Format (ARF) | |
| | | for reporting email abuse but also includes support for feedback | |
| | | loops, virus reports and other similar activities. | |
| | | | |
| This document only defines the format and content type to be used for | | This document only defines the format and content type to be used for | |
| these reports. Determination of where these reports should be sent, | | these reports. Determination of where these reports should be sent, | |
| how trust among report senders and receivers is established, and | | how trust among report senders and receivers is established, and | |
| reports related to more than one message are outside the scope of | | reports related to more than one message are outside the scope of | |
| this document. | | this document. | |
| | | | |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |
|
| document are to be interpreted as described in [RFC2119]. | | document are to be interpreted as described in RFC 2119 [2]. | |
| | | | |
| NOTE: This document may be incomplete and is intented to evolve based | | NOTE: This document may be incomplete and is intented to evolve based | |
| on public discussion and feedback. Readers are encourages to submit | | on public discussion and feedback. Readers are encourages to submit | |
| their comments and suggestions. | | their comments and suggestions. | |
| | | | |
| 2. Intent | | 2. Intent | |
| | | | |
| The reports defined in this document are intended for several | | The reports defined in this document are intended for several | |
| purposes: | | purposes: | |
| | | | |
|
| o To inform ISPs about email abuse and viruses originating from or | | o To inform ISPs about email abuse originating from or related to | |
| related to their networks | | their networks | |
| | | | |
| o To provide feedback about abuse complaints to email service | | o To provide feedback about abuse complaints to email service | |
| providers and relevant third parties (such as reputation | | providers and relevant third parties (such as reputation | |
| providers) | | providers) | |
|
| | | | |
| o To inform email service provides about opt-out requests | | o To inform email service provides about opt-out requests | |
| | | | |
| Please note that while the parent "multipart/report" content type | | Please note that while the parent "multipart/report" content type | |
| defined in RFC 3462 [1] is used for all kinds of administrative | | defined in RFC 3462 [1] is used for all kinds of administrative | |
| messages, this format is intended specifically for communications | | messages, this format is intended specifically for communications | |
| among providers regarding email abuse and related issues, and SHOULD | | among providers regarding email abuse and related issues, and SHOULD | |
| NOT be used for other reports. | | NOT be used for other reports. | |
| | | | |
| 3. Requirements | | 3. Requirements | |
| | | | |
| | | | |
| skipping to change at page 4, line 16 | | skipping to change at page 4, line 23 | |
| | | | |
| The following requirements are necessary for feedback reports (the | | The following requirements are necessary for feedback reports (the | |
| actual standard is defined in the next sections) : | | actual standard is defined in the next sections) : | |
| | | | |
| o They must be both human and machine readable | | o They must be both human and machine readable | |
| | | | |
| o A copy of the original email message (body and headers) or the | | o A copy of the original email message (body and headers) or the | |
| message headers must be enclosed in order to allow the receiver to | | message headers must be enclosed in order to allow the receiver to | |
| properly handle the report. | | properly handle the report. | |
| | | | |
|
| o The machine readable section must provide ability for report | | o The machine readable section must provide ability for the report | |
| generators to share metadata with receivers, | | generators to share metadata with receivers, | |
| | | | |
| o The format must be extensible. | | o The format must be extensible. | |
| | | | |
| 4. Format of Email Feedback Reports | | 4. Format of Email Feedback Reports | |
| | | | |
| To satisfy the requirements, an email feedback report is defined as a | | To satisfy the requirements, an email feedback report is defined as a | |
| MIME message with a top level MIME content type of "multipart/report" | | MIME message with a top level MIME content type of "multipart/report" | |
| (as defined in RFC 3462 [1]). The following apply: | | (as defined in RFC 3462 [1]). The following apply: | |
| | | | |
| | | | |
| skipping to change at page 4, line 41 | | skipping to change at page 4, line 48 | |
| description of the report and MUST be included. | | description of the report and MUST be included. | |
| | | | |
| c. The second MIME part of the message is a machine-readable section | | c. The second MIME part of the message is a machine-readable section | |
| with the content type of "message/feedback-report" (defined later | | with the content type of "message/feedback-report" (defined later | |
| on in this document) and MUST be included. This section is | | on in this document) and MUST be included. This section is | |
| intended to convey metadata about the report in question that may | | intended to convey metadata about the report in question that may | |
| not be readily available from the included email message itself. | | not be readily available from the included email message itself. | |
| | | | |
| d. The third MIME part of the message contains either a full copy of | | d. The third MIME part of the message contains either a full copy of | |
| the original message with a MIME content type of "message/rfc822" | | the original message with a MIME content type of "message/rfc822" | |
|
| (as defined in RFC 2046 [2]) OR a copy of the headers from the | | (as defined in RFC 2046 [3]) OR a copy of the headers from the | |
| original message with MIME content type of "text/rfc822-headers" | | original message with MIME content type of "text/rfc822-headers" | |
| (as defined in RFC 3462 [1]). This part MUST BE included (unlike | | (as defined in RFC 3462 [1]). This part MUST BE included (unlike | |
|
| RFC 3462 [1]). | | RFC 3462 [1]). While some operators may choose to modify or | |
| | | munge this portion for privacy or legal reasons, it is | |
| | | RECOMMENDED that the entire original email message be included | |
| | | without any modification. | |
| | | | |
| e. Each feedback report MUST be related to only a SINGLE email | | e. Each feedback report MUST be related to only a SINGLE email | |
| message. Summary and aggregate formats are outside the scope of | | message. Summary and aggregate formats are outside the scope of | |
| this specification. | | this specification. | |
| | | | |
| f. The subject line of the feedback report SHOULD be the same as the | | f. The subject line of the feedback report SHOULD be the same as the | |
| included email message and MAY include only the standard | | included email message and MAY include only the standard | |
| forwarding prefix used by MUAs such as "FW:" (many smaller | | forwarding prefix used by MUAs such as "FW:" (many smaller | |
| operators using MUAs for abuse handling rely on the subject lines | | operators using MUAs for abuse handling rely on the subject lines | |
| for processing). | | for processing). | |
| | | | |
| 5. Format of 'message/feedback-report' Content Type | | 5. Format of 'message/feedback-report' Content Type | |
| | | | |
| This content type provides a machine-readable section intended to let | | This content type provides a machine-readable section intended to let | |
| the report generator convey metadata to the report receiver. The | | the report generator convey metadata to the report receiver. The | |
| intent of this section is it allow report generators to convey | | intent of this section is it allow report generators to convey | |
| metadata to report receivers that may not available or may not be | | metadata to report receivers that may not available or may not be | |
| readily available from the originating email message or headers. | | readily available from the originating email message or headers. | |
| | | | |
| The body of this content type consists of multiple "fields" formatted | | The body of this content type consists of multiple "fields" formatted | |
|
| according to the ABNF of RFC 822 [12] header "fields". This section | | according to the ABNF of RFC 822 [14] header "fields". This section | |
| defines the initial set of fields provided by this specification. | | defines the initial set of fields provided by this specification. | |
| Additional fields maybe registered according to the procedure | | Additional fields maybe registered according to the procedure | |
| described later on in this document. Note that these fields | | described later on in this document. Note that these fields | |
| represent information that the receiver is asserting about the report | | represent information that the receiver is asserting about the report | |
| in question, but are not necessarily verifiable. Report receivers | | in question, but are not necessarily verifiable. Report receivers | |
| MUST NOT assume that these assertions are always true. | | MUST NOT assume that these assertions are always true. | |
| | | | |
| 5.1 Required Fields | | 5.1 Required Fields | |
| | | | |
| The following header fields are REQUIRED and MUST only appear once: | | The following header fields are REQUIRED and MUST only appear once: | |
| | | | |
| o "Feedback-Type:" - contains the type of feedback report (as | | o "Feedback-Type:" - contains the type of feedback report (as | |
| defined in the corresponding IANA registry). This is intended to | | defined in the corresponding IANA registry). This is intended to | |
| let report generators distinguish among different types of | | let report generators distinguish among different types of | |
| reports. | | reports. | |
| | | | |
| o "User-Agent:" - indicates the name and version of the software | | o "User-Agent:" - indicates the name and version of the software | |
| program that generated the report. The format of this field MUST | | program that generated the report. The format of this field MUST | |
|
| follow section 14.43 of RFC 2616 [3]. | | follow section 14.43 of RFC 2616 [4]. | |
| | | | |
| o "Version" - indicates the version of specification that the report | | o "Version" - indicates the version of specification that the report | |
| generator is using to generate the report. The version number in | | generator is using to generate the report. The version number in | |
| this specification is set to "0.1". | | this specification is set to "0.1". | |
| | | | |
| 5.2 Optional Fields Appearing Once | | 5.2 Optional Fields Appearing Once | |
| | | | |
| The following header fields are OPTIONAL and MUST NOT appear more | | The following header fields are OPTIONAL and MUST NOT appear more | |
| than once: | | than once: | |
| | | | |
| o "Original-Mail-From:" - copy of the email address used in the MAIL | | o "Original-Mail-From:" - copy of the email address used in the MAIL | |
| FROM portion of the original SMTP transaction. The format of this | | FROM portion of the original SMTP transaction. The format of this | |
|
| field is defined in section 4.1.1.2 of RFC 2821 [4]. | | field is defined in section 4.1.1.2 of RFC 2821 [5]. | |
| | | | |
| o "Original-Rcpt-To:" - copy of the email address used in the RCPT | | o "Original-Rcpt-To:" - copy of the email address used in the RCPT | |
| TO portion of the original SMTP transaction. The format of this | | TO portion of the original SMTP transaction. The format of this | |
|
| field is defined in section 4.1.1.3 of RFC 2821 [4]. | | field is defined in section 4.1.1.3 of RFC 2821 [5]. | |
| | | | |
| o "Received-Date:" - indicates the date the original message was | | o "Received-Date:" - indicates the date the original message was | |
| received by the report generator. This field MUST BE formatted as | | received by the report generator. This field MUST BE formatted as | |
|
| per section 3.3 of RFC 2822 [5]. | | per section 3.3 of RFC 2822 [6]. | |
| | | | |
| o "Source-IP:" - contains an IPv4 or IPv6 address of the MTA from | | o "Source-IP:" - contains an IPv4 or IPv6 address of the MTA from | |
| which the original message was received. IPv4 addresses are to be | | which the original message was received. IPv4 addresses are to be | |
| formatted in dot-decimal notation as currently used by the | | formatted in dot-decimal notation as currently used by the | |
| community. IPv6 addresses MUST BE formatted as per section 2.2 of | | community. IPv6 addresses MUST BE formatted as per section 2.2 of | |
|
| RFC 2373 [6]. | | RFC 2373 [7]. | |
| | | | |
| 5.3 Optional Fields Appearing Multiple Times | | 5.3 Optional Fields Appearing Multiple Times | |
| | | | |
| The following set of header fields are OPTIONAL and MAY appear more | | The following set of header fields are OPTIONAL and MAY appear more | |
| than once: | | than once: | |
| | | | |
| o "Authentication-Results:" - indicates the result of an | | o "Authentication-Results:" - indicates the result of an | |
| authentication check run by the report generator. The format of | | authentication check run by the report generator. The format of | |
| this field is is defined in draft-kucherawy-sender-auth-header | | this field is is defined in draft-kucherawy-sender-auth-header | |
|
| [7]. Report receivers should note that this field only indicates | | [8]. Report receivers should note that this field only indicates | |
| an assertion made by the report generator. | | an assertion made by the report generator. | |
| | | | |
| o "Reported-Domain:" - indicates a domain name that the report | | o "Reported-Domain:" - indicates a domain name that the report | |
| generator believes to be relevant to the report. Domain format is | | generator believes to be relevant to the report. Domain format is | |
|
| defined in section 2.3.1 of RFC 1035 [8]. | | defined in section 2.3.1 of RFC 1035 [9]. | |
| | | | |
| o "Reported-URI:" - indicates a URI that the report generator | | o "Reported-URI:" - indicates a URI that the report generator | |
| believes to be relevant to the report. URI format is defined in | | believes to be relevant to the report. URI format is defined in | |
|
| RFC 2396 [13]. | | RFC 2396 [15]. | |
| | | | |
| o "Removal-Recipient:" - indicates the email address to be removed | | o "Removal-Recipient:" - indicates the email address to be removed | |
|
| from the mailing list (only used with "opt-out" feedback report). | | from the mailing list (MUST only be used with "opt-out" and "opt- | |
| The format of this field is defined in section 3.4.1 of RFC 2822 | | out-list" types). The format of this field is defined in section | |
| [5]. | | 3.4.1 of RFC 2822 [6]. | |
| | | | |
| 6. MIME Type Registration of message/feedback-report | | 6. MIME Type Registration of message/feedback-report | |
| | | | |
| This section provides the media type registration application (as per | | This section provides the media type registration application (as per | |
| RFC 2048 [11], which will be submitted to IANA after IESG approval of | | RFC 2048 [11], which will be submitted to IANA after IESG approval of | |
| this document. | | this document. | |
| | | | |
| To: ietf-types@iana.org | | To: ietf-types@iana.org | |
|
| | | | |
| Subject: Registration of MIME media types message/feedback-report | | Subject: Registration of MIME media types message/feedback-report | |
| | | | |
| MIME media type name: message | | MIME media type name: message | |
| | | | |
| MIME subtype name: feedback-report | | MIME subtype name: feedback-report | |
| | | | |
| Required parameters: none | | Required parameters: none | |
| | | | |
| Optional parameters: none | | Optional parameters: none | |
| | | | |
| | | | |
| skipping to change at page 8, line 27 | | skipping to change at page 8, line 38 | |
| | | | |
| 8. IANA Considerations | | 8. IANA Considerations | |
| | | | |
| After IESG approval, IANA is expected to register MIME type "message/ | | After IESG approval, IANA is expected to register MIME type "message/ | |
| feedback-report" using the application provided in this document and | | feedback-report" using the application provided in this document and | |
| setup two registries: one for header field names and a second for | | setup two registries: one for header field names and a second for | |
| "Feedback-Type" values. This section contains the templates used for | | "Feedback-Type" values. This section contains the templates used for | |
| registration of new entries in these registries and initial values. | | registration of new entries in these registries and initial values. | |
| New registrations to these two registries MUST have approval by an | | New registrations to these two registries MUST have approval by an | |
| Designated Expert in accordance with the Expert Review guidelines as | | Designated Expert in accordance with the Expert Review guidelines as | |
|
| described in RFC 2434 [9]. Any new field registered is considered | | described in RFC 2434 [10] (the expert should be appointed by the | |
| OPTIONAL unless a new version of this specifiction is published. | | Area Directors of the Applications Area). Any new field registered | |
| | | is considered OPTIONAL unless a new version of this specification is | |
| | | published. | |
| | | | |
| For the header name registry, the following MUST be provided in an | | For the header name registry, the following MUST be provided in an | |
| RFC publication (or Internet draft with IETF consensus or IESG | | RFC publication (or Internet draft with IETF consensus or IESG | |
| approval) in order to register a new header field name: | | approval) in order to register a new header field name: | |
| | | | |
| 1. Name of the field being registered | | 1. Name of the field being registered | |
| | | | |
| 2. Short description of the field | | 2. Short description of the field | |
| | | | |
| 3. Whether the field can appear more than once | | 3. Whether the field can appear more than once | |
| | | | |
| skipping to change at page 10, line 9 | | skipping to change at page 10, line 21 | |
| Related "Feedback-Type": any | | Related "Feedback-Type": any | |
| | | | |
| Field Name: Reported-URI | | Field Name: Reported-URI | |
| Description: relevant URI | | Description: relevant URI | |
| Multiple Appearances: Yes | | Multiple Appearances: Yes | |
| Related "Feedback-Type": any | | Related "Feedback-Type": any | |
| | | | |
| Field Name: Removal-Recipient | | Field Name: Removal-Recipient | |
| Description: email address to be removed from the mailing list | | Description: email address to be removed from the mailing list | |
| Multiple Appearances: Yes | | Multiple Appearances: Yes | |
|
| Related "Feedback-Type": opt-out | | Related "Feedback-Type": opt-out, opt-out-list | |
| | | | |
| Field Name: Source-IP | | Field Name: Source-IP | |
| Description: IPv4 or IPv6 address from which the original message was | | Description: IPv4 or IPv6 address from which the original message was | |
| received | | received | |
| Multiple Appearances: No | | Multiple Appearances: No | |
| Related "Feedback-Type": any | | Related "Feedback-Type": any | |
| | | | |
| Field Name: User-Agent | | Field Name: User-Agent | |
| Description: name and version of the program used | | Description: name and version of the program used | |
| Multiple Appearances: No | | Multiple Appearances: No | |
| | | | |
| skipping to change at page 10, line 34 | | skipping to change at page 10, line 46 | |
| Multiple Appearances: No | | Multiple Appearances: No | |
| Related "Feedback-Type": any | | Related "Feedback-Type": any | |
| | | | |
| 8.2 Initial values for the "Feedback-Type" registry | | 8.2 Initial values for the "Feedback-Type" registry | |
| | | | |
| The initial names and descriptions are provided below. The RFC | | The initial names and descriptions are provided below. The RFC | |
| number used for registration of these values is this document. | | number used for registration of these values is this document. | |
| | | | |
| o abuse - spam or some other kind of email abuse | | o abuse - spam or some other kind of email abuse | |
| | | | |
|
| o opt-out - a request to opt out from a mailing list. | | o fraud - indicates some kind of fraud or phishing activity. | |
| | | | |
| | | o opt-out - a request to opt out from ALL mailing lists from this | |
| | | provider. | |
| | | | |
| | | o opt-out-list - a request to opt out from THIS mailing list ONLY. | |
| | | | |
| | | o other - any other feedback that doesn't fit into other types. | |
| | | | |
| o virus - report of a virus found in the originating message | | o virus - report of a virus found in the originating message | |
| | | | |
| 9. Security Considerations | | 9. Security Considerations | |
| | | | |
| See section 3 of RFC 3462 [1] | | See section 3 of RFC 3462 [1] | |
| | | | |
| 10. Acknowledgments | | 10. Acknowledgments | |
| | | | |
| The author would like to thank many of the members of the email | | The author would like to thank many of the members of the email | |
| community who provided helpful comments and suggestions for this | | community who provided helpful comments and suggestions for this | |
| document including many of the participants in ASRG, IETF and MAAWG | | document including many of the participants in ASRG, IETF and MAAWG | |
|
| activities. | | activities, and all of the members of the abuse-feedback-report | |
| | | public mailing list. | |
| | | | |
| 11. References | | 11. References | |
| | | | |
| 11.1 Normative References | | 11.1 Normative References | |
| | | | |
| [1] Vaudreuil, G., "The Multipart/Report Content Type for the | | [1] Vaudreuil, G., "The Multipart/Report Content Type for the | |
| Reporting of Mail System Administrative Messages", RFC 3462, | | Reporting of Mail System Administrative Messages", RFC 3462, | |
| January 2003. | | January 2003. | |
| | | | |
|
| [2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | | [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement | |
| | | Levels", BCP 14, RFC 2119, March 1997. | |
| | | | |
| | | [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |
| Extensions (MIME) Part Two: Media Types", RFC 2046, | | Extensions (MIME) Part Two: Media Types", RFC 2046, | |
| November 1996. | | November 1996. | |
| | | | |
|
| [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., | | [4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., | |
| Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- | | Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- | |
| HTTP/1.1", RFC 2616, June 1999. | | HTTP/1.1", RFC 2616, June 1999. | |
| | | | |
|
| [4] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, | | [5] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, | |
| April 2001. | | April 2001. | |
| | | | |
|
| [5] Resnick, P., "Internet Message Format", RFC 2822, April 2001. | | [6] Resnick, P., "Internet Message Format", RFC 2822, April 2001. | |
| | | | |
|
| [6] Hinden, R. and S. Deering, "IP Version 6 Addressing | | [7] Hinden, R. and S. Deering, "IP Version 6 Addressing | |
| Architecture", RFC 2373, July 1998. | | Architecture", RFC 2373, July 1998. | |
| | | | |
|
| [7] Kucherawy, M., "Message Header for Indicating Sender | | [8] Kucherawy, M., "Message Header for Indicating Sender | |
| Authentication Status", draft-kucherawy-sender-auth-header-02 | | Authentication Status", draft-kucherawy-sender-auth-header-02 | |
| (work in progress), May 2005. | | (work in progress), May 2005. | |
| | | | |
|
| [8] Mockapetris, P., "Domain names - implementation and | | [9] Mockapetris, P., "Domain names - implementation and | |
| specification", STD 13, RFC 1035, November 1987. | | specification", STD 13, RFC 1035, November 1987. | |
| | | | |
|
| [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA | | [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA | |
| Considerations Section in RFCs", BCP 26, RFC 2434, | | Considerations Section in RFCs", BCP 26, RFC 2434, | |
| October 1998. | | October 1998. | |
| | | | |
|
| [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement | | | |
| Levels", BCP 14, RFC 2119, March 1997. | | | |
| | | | |
| 11.2 Informative References | | 11.2 Informative References | |
| | | | |
| [11] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet | | [11] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet | |
| Mail Extensions (MIME) Part Four: Registration Procedures", | | Mail Extensions (MIME) Part Four: Registration Procedures", | |
| BCP 13, RFC 2048, November 1996. | | BCP 13, RFC 2048, November 1996. | |
| | | | |
|
| [12] Crocker, D., "Standard for the format of ARPA Internet text | | [12] Crissman, G., "Proposed Spam Reporting BCP Document", May 2005, | |
| | | <http://www.tmisnet.com/~strads/spam/bcp.html>. | |
| | | | |
| | | [13] Anti-Spam Research Group (ASRG) of the Internet Research Task | |
| | | Force (IRTF), "Abuse Reporting Standards Subgroup of the ASRG", | |
| | | May 2005, <http://asrg.sp.am/subgroups/abuse_reports.shtml>. | |
| | | | |
| | | [14] Crocker, D., "Standard for the format of ARPA Internet text | |
| messages", STD 11, RFC 822, August 1982. | | messages", STD 11, RFC 822, August 1982. | |
| | | | |
|
| [13] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | | [15] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | |
| Resource Identifiers (URI): Generic Syntax", RFC 2396, | | Resource Identifiers (URI): Generic Syntax", RFC 2396, | |
| August 1998. | | August 1998. | |
| | | | |
| Author's Address | | Author's Address | |
| | | | |
| Yakov Shafranovich | | Yakov Shafranovich | |
| SolidMatrix Technologies, Inc. | | SolidMatrix Technologies, Inc. | |
| | | | |
| Email: ietf@shaftek.org | | Email: ietf@shaftek.org | |
| URI: http://www.shaftek.org | | URI: http://www.shaftek.org | |
| | | | |
|
| Appendix A. Appendix A - An Sample Abuse Report | | Appendix A. Appendix A - Sample Feedback Reports | |
| | | | |
|
| | | A.1 Simple Report for Email Abuse without Optional Headers | |
| From: <abusedesk@example.com> | | From: <abusedesk@example.com> | |
| Date: Thu, 8 Mar 2005 17:40:36 EDT | | Date: Thu, 8 Mar 2005 17:40:36 EDT | |
| Subject: FW: Earn money | | Subject: FW: Earn money | |
| To: <abuse@example.net> | | To: <abuse@example.net> | |
| MIME-Version: 1.0 | | MIME-Version: 1.0 | |
| Content-Type: multipart/report; report-type=feedback-report; boundary="part1_13d.2e68ed54_boundary" | | Content-Type: multipart/report; report-type=feedback-report; boundary="part1_13d.2e68ed54_boundary" | |
| | | | |
| --part1_13d.2e68ed54_boundary | | --part1_13d.2e68ed54_boundary | |
| Content-Type: text/plain; charset="US-ASCII" | | Content-Type: text/plain; charset="US-ASCII" | |
| Content-Transfer-Encoding: 7bit | | Content-Transfer-Encoding: 7bit | |
| | | | |
| This is an email abuse report for an email message received from IP 10.67.41.167 on Thu, 8 Mar 2005 14:00:00 EDT. | | This is an email abuse report for an email message received from IP 10.67.41.167 on Thu, 8 Mar 2005 14:00:00 EDT. | |
|
| | | For more information about this format please see http://www.mipassoc.org/arf/. | |
| | | | |
| | | --part1_13d.2e68ed54_boundary | |
| | | Content-Type: message/feedback-report | |
| | | | |
| | | Feedback-Type: abuse | |
| | | User-Agent: SomeGenerator/1.0 | |
| | | Version: 0.1 | |
| | | | |
| | | --part1_13d.2e68ed54_boundary | |
| | | Content-Type: message/rfc822 | |
| | | Content-Disposition: inline | |
| | | | |
| | | From: <somespammer@example.net> | |
| | | Received: from mailserver.example.net (mailserver.example.net [10.67.41.167]) | |
| | | by example.com with ESMTP id M63d4137594e46; Thu, 08 Mar 2005 14:00:00 -0400 | |
| | | To: <Undisclosed Recipients> | |
| | | Subject: Earn money | |
| | | MIME-Version: 1.0 | |
| | | Content-type: text/plain | |
| | | Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net | |
| | | Date: Thu, 02 Sep 2004 12:31:03 -0500 | |
| | | | |
| | | Spam Spam Spam | |
| | | Spam Spam Spam | |
| | | Spam Spam Spam | |
| | | Spam Spam Spam | |
| | | --part1_13d.2e68ed54_boundary-- | |
| | | | |
| | | A.2 Opt-Out Report without Message Body | |
| | | From: <abusedesk@example.com> | |
| | | Date: Thu, 8 Mar 2005 17:40:36 EDT | |
| | | Subject: FW: Earn money | |
| | | To: <abuse@example.net> | |
| | | 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 opt-out report for an email message received from IP 10.67.41.167 on Thu, 8 Mar 2005 14:00:00 EDT. | |
| | | For more information about this format please see http://www.mipassoc.org/arf/. | |
| | | | |
| | | --part1_13d.2e68ed54_boundary | |
| | | Content-Type: message/feedback-report | |
| | | | |
| | | Feedback-Type: opt-out | |
| | | User-Agent: SomeGenerator/1.0 | |
| | | Version: 0.1 | |
| | | Removal-Recipient: user@example.com | |
| | | | |
| | | --part1_13d.2e68ed54_boundary | |
| | | Content-Type: message/rfc822-headers | |
| | | Content-Disposition: inline | |
| | | | |
| | | From: <somespammer@example.net> | |
| | | Received: from mailserver.example.net (mailserver.example.net [10.67.41.167]) | |
| | | by example.com with ESMTP id M63d4137594e46; Thu, 08 Mar 2005 14:00:00 -0400 | |
| | | To: <Undisclosed Recipients> | |
| | | Subject: Earn money | |
| | | MIME-Version: 1.0 | |
| | | Content-type: text/plain | |
| | | Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net | |
| | | Date: Thu, 02 Sep 2004 12:31:03 -0500 | |
| | | --part1_13d.2e68ed54_boundary-- | |
| | | | |
| | | A.3 Full Report for Email Abuse with All Headers | |
| | | | |
| | | From: <abusedesk@example.com> | |
| | | Date: Thu, 8 Mar 2005 17:40:36 EDT | |
| | | Subject: FW: Earn money | |
| | | To: <abuse@example.net> | |
| | | 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 10.67.41.167 on Thu, 8 Mar 2005 14:00:00 EDT. | |
| | | For more information about this format please see http://www.mipassoc.org/arf/. | |
| | | | |
| --part1_13d.2e68ed54_boundary | | --part1_13d.2e68ed54_boundary | |
| Content-Type: message/feedback-report | | Content-Type: message/feedback-report | |
| | | | |
| Feedback-Type: abuse | | Feedback-Type: abuse | |
| User-Agent: SomeGenerator/1.0 | | User-Agent: SomeGenerator/1.0 | |
| Version: 0.1 | | Version: 0.1 | |
| Original-Mail-From: <somespammer@example.net> | | Original-Mail-From: <somespammer@example.net> | |
| Original-Rcpt-To: <user@example.com> | | Original-Rcpt-To: <user@example.com> | |
| Received-Date: Thu, 8 Mar 2005 14:00:00 EDT | | Received-Date: Thu, 8 Mar 2005 14:00:00 EDT | |
| | | | |
| skipping to change at page 13, line 39 | | skipping to change at page 16, line 25 | |
| | | | |
| B.2 Document Repository and Public Website | | B.2 Document Repository and Public Website | |
| | | | |
| Copies of this and earlier versions including multiple formats can be | | Copies of this and earlier versions including multiple formats can be | |
| found at <http://www.shaftek.org/publications/drafts/abuse-report/>. | | found at <http://www.shaftek.org/publications/drafts/abuse-report/>. | |
| A public website regarding this draft and related efforts is located | | A public website regarding this draft |