| draft-shafranovich-feedback-report-00.txt | | draft-shafranovich-feedback-report-01-pre1.txt | |
| | | | |
| Network Working Group Y. Shafranovich | | Network Working Group Y. Shafranovich | |
| Internet-Draft SolidMatrix Technologies, Inc. | | Internet-Draft SolidMatrix Technologies, Inc. | |
|
| Expires: September 2, 2005 March 2005 | | Expires: November 7, 2005 May 6, 2005 | |
| | | | |
| An Extensible Format for Email Feedback Reports | | An Extensible Format for Email Feedback Reports | |
|
| draft-shafranovich-feedback-report-00.txt | | draft-shafranovich-feedback-report-01-pre1.txt | |
| | | | |
| Status of this Memo | | Status of this Memo | |
| | | | |
| This document is an Internet-Draft and is subject to all provisions | | This document is an Internet-Draft and is subject to all provisions | |
| of Section 3 of RFC 3667. By submitting this Internet-Draft, each | | of Section 3 of RFC 3667. By submitting this Internet-Draft, each | |
| author represents that any applicable patent or other IPR claims of | | author represents that any applicable patent or other IPR claims of | |
| which he or she is aware have been or will be disclosed, and any of | | which he or she is aware have been or will be disclosed, and any of | |
| which he or she become aware will be disclosed, in accordance with | | which he or she become aware will be disclosed, in accordance with | |
| RFC 3668. | | RFC 3668. | |
| | | | |
| | | | |
| skipping to change at page 1, line 35 | | skipping to change at page 1, line 35 | |
| 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 September 2, 2005. | | This Internet-Draft will expire on November 7, 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 | |
| replacement for various existing report formats currently used in | | replacement for various existing report formats currently used in | |
| Internet email. | | Internet email. | |
| | | | |
| Table of Contents | | Table of Contents | |
| | | | |
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |
| 2. Intent . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | | 2. Intent . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |
|
| 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 | | 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 . . . . . . 4 | | 5. Format of 'message/feedback-report' Content Type . . . . . . 5 | |
| 6. MIME Type Registration of message/feedback-report . . . . . 5 | | 5.1 Required Fields . . . . . . . . . . . . . . . . . . . . . 5 | |
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6 | | 5.2 Optional Fields Appearing Once . . . . . . . . . . . . . . 5 | |
| 8. Security Considerations . . . . . . . . . . . . . . . . . . 6 | | 5.3 Optional Fields Appearing Multiple Times . . . . . . . . . 6 | |
| 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 6 | | 6. MIME Type Registration of message/feedback-report . . . . . 6 | |
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 | | 7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . 7 | |
| 10.1 Normative References . . . . . . . . . . . . . . . . . . 7 | | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 | |
| 10.2 Informative References . . . . . . . . . . . . . . . . . 7 | | 8.1 Initial Values for the Header Names Registry . . . . . . . 9 | |
| Author's Address . . . . . . . . . . . . . . . . . . . . . . 7 | | 8.2 Initial values for the "Feedback-Type" registry . . . . . 10 | |
| A. Appendix A - An Sample Abuse Report . . . . . . . . . . . . 8 | | 9. Security Considerations . . . . . . . . . . . . . . . . . . 10 | |
| B. Status of This Document [To Be Removed Upon Publication] . . 9 | | 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 10 | |
| B.1 Discussion Venue . . . . . . . . . . . . . . . . . . . . . 9 | | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |
| B.2 Document Repository . . . . . . . . . . . . . . . . . . . 9 | | 11.1 Normative References . . . . . . . . . . . . . . . . . . 11 | |
| B.3 Document History . . . . . . . . . . . . . . . . . . . . . 9 | | 11.2 Informative References . . . . . . . . . . . . . . . . . 11 | |
| Intellectual Property and Copyright Statements . . . . . . . 10 | | Author's Address . . . . . . . . . . . . . . . . . . . . . . 12 | |
| | | A. Appendix A - An Sample Abuse Report . . . . . . . . . . . . 12 | |
| | | B. Status of This Document [To Be Removed Upon Publication] . . 13 | |
| | | B.1 Discussion Venue . . . . . . . . . . . . . . . . . . . . . 13 | |
| | | B.2 Document Repository and Public Website . . . . . . . . . . 13 | |
| | | B.3 Document History . . . . . . . . . . . . . . . . . . . . . 13 | |
| | | Intellectual Property and Copyright Statements . . . . . . . 15 | |
| | | | |
| 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 [4]. 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]. | |
| | | | |
| 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, | |
| is outside the scope of this document. | | how trust among report senders and receivers is established, and | |
| | | reports related to more than one message are outside the scope of | |
| | | this document. | |
| | | | |
| | | 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 [RFC2119]. | |
| | | | |
| 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 | | on public discussion and feedback. Readers are encourages to submit | |
| | | 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: | |
| | | | |
|
| a. To inform ISPs about email abuse originating from their networks | | o To inform ISPs about email abuse and viruses originating from or | |
| | | related to their networks | |
| | | | |
|
| b. To provide feedback to email service providers about abuse | | o To provide feedback about abuse complaints to email service | |
| complaints | | providers and relevant third parties (such as reputation | |
| | | providers) | |
| | | | |
|
| c. To inform the author of the message that the receiver wants to | | o To inform email service provides about opt-out requests | |
| opt out. | | | |
| | | | |
|
| Note that the reports defined in this document are limited to | | Please note that while the parent "multipart/report" content type | |
| providing feedback about email only. | | defined in RFC 3462 [1] is used for all kinds of administrative | |
| | | messages, this format is intended specifically for communications | |
| | | among providers regarding email abuse and related issues, and SHOULD | |
| | | NOT be used for other reports. | |
| | | | |
| 3. Requirements | | 3. Requirements | |
| | | | |
|
| The following requirements are necessary for feedback reports : | | The following requirements are necessary for feedback reports (the | |
| | | actual standard is defined in the next sections) : | |
| | | | |
|
| a. They must be both human and machine readable | | o They must be both human and machine readable | |
| | | | |
|
| b. Copy of the original email message or email headers must be | | o A copy of the original email message (body and headers) or the | |
| enclosed in order to allow the receiver to properly handle the | | message headers must be enclosed in order to allow the receiver to | |
| report. | | properly handle the report. | |
| | | | |
| | | o The machine readable section must provide ability for report | |
| | | generators to share metadata with receivers, | |
| | | | |
| | | o The format must be extensible. | |
| | | | |
| 4. Format of Email Feedback Reports | | 4. Format of Email Feedback Reports | |
| | | | |
|
| An email feedback report is a MIME message with a top level MIME | | To satisfy the requirements, an email feedback report is defined as a | |
| content type of "multipart/report" (as defined in RFC 3462 [1]). The | | MIME message with a top level MIME content type of "multipart/report" | |
| following apply: | | (as defined in RFC 3462 [1]). The following apply: | |
| | | | |
| a. The "report-type" parameter of "multipart/report" type is set to | | a. The "report-type" parameter of "multipart/report" type is set to | |
|
| "feedback-report". | | "feedback-report" | |
| | | | |
| b. The first MIME part of the message contains a human readable | | b. The first MIME part of the message contains a human readable | |
|
| description of the report | | description of the report and MUST be included. | |
| | | | |
|
| c. The second MIME part of the message contains a machine readable | | c. The second MIME part of the message is a machine-readable section | |
| abuse report with the content type of "message/feedback-report" | | with the content type of "message/feedback-report" (defined later | |
| (defined later on in this document). | | on in this document) and MUST be included. This section is | |
| | | intended to convey metadata about the report in question that may | |
| | | 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 [1]) OR a copy of the headers from the | | (as defined in RFC 2046 [2]) 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]). | | (as defined in RFC 3462 [1]). This part MUST BE included (unlike | |
| | | RFC 3462 [1]). | |
| e. Each abuse report should related to a single originating message. | | | |
| | | | |
|
| f. The subject line of the abuse report should read as "Email | | e. Each feedback report MUST be related to only a SINGLE email | |
| Feedback Report for IP X.X.X.X" where "X.X.X.X" is the source IP | | message. Summary and aggregate formats are outside the scope of | |
| of the MTA from which the original message was received. If | | this specification. | |
| email authentication is used, the sender may substitute the text | | | |
| "for domain YYYYY.ZZZZ" where "YYYYY.ZZZZ" is the authenticated | | | |
| domain. | | | |
| | | | |
|
| g. It is preferable that all original email headers are included | | f. The subject line of the feedback report SHOULD be the same as the | |
| even though they are defined as optional in RFC 3462 [1]. | | included email message and MAY include only the standard | |
| | | forwarding prefix used by MUAs such as "FW:" (many smaller | |
| | | operators using MUAs for abuse handling rely on the subject lines | |
| | | for processing). | |
| | | | |
| 5. Format of 'message/feedback-report' Content Type | | 5. Format of 'message/feedback-report' Content Type | |
| | | | |
|
| The message/feedback-report content type consists of several header | | This content type provides a machine-readable section intended to let | |
| fields as follows: | | the report generator convey metadata to the report receiver. The | |
| | | intent of this section is it allow report generators to convey | |
| | | metadata to report receivers that may not available or may not be | |
| | | readily available from the originating email message or headers. | |
| | | | |
|
| a. "Source-IP:" - contains an IPv4 or IPv6 address of the MTA from | | The body of this content type consists of multiple "fields" formatted | |
| which the original message was received. | | according to the ABNF of RFC 822 [12] header "fields". This section | |
| | | defines the initial set of fields provided by this specification. | |
| | | Additional fields maybe registered according to the procedure | |
| | | described later on in this document. Note that these fields | |
| | | represent information that the receiver is asserting about the report | |
| | | in question, but are not necessarily verifiable. Report receivers | |
| | | MUST NOT assume that these assertions are always true. | |
| | | | |
|
| b. "Received-Date:" - date the original message was received. This | | 5.1 Required Fields | |
| field is formatted in according to the definition in section 3.3 | | | |
| of RFC 2822 [2] | | | |
| c. "Original-Message-ID:" - contains the RFC 2822 [2] Message-ID of | | | |
| the original message | | | |
| | | | |
|
| d. "Feedback-Type:" - contains the type of feedback as defined in | | The following header fields are REQUIRED and MUST only appear once: | |
| the corresponding IANA registry. | | | |
| | | | |
|
| e. "Authenticated-Domain:" and "Authenticated-Domain-Method:" - | | o "Feedback-Type:" - contains the type of feedback report (as | |
| defines the authenticated domain and method used for perform that | | defined in the corresponding IANA registry). This is intended to | |
| authentication. The list of method tokens is contained in the | | let report generators distinguish among different types of | |
| corresponding IANA registry. Note that the actual type of | | reports. | |
| authentication used is outside the scope of this document. | | | |
| | | o "User-Agent:" - indicates the name and version of the software | |
| | | program that generated the report. The format of this field MUST | |
| | | follow section 14.43 of RFC 2616 [3]. | |
| | | | |
| | | o "Version" - indicates the version of specification that the report | |
| | | generator is using to generate the report. The version number in | |
| | | this specification is set to "0.1". | |
| | | | |
| | | 5.2 Optional Fields Appearing Once | |
| | | | |
| | | The following header fields are OPTIONAL and MUST NOT appear more | |
| | | than once: | |
| | | | |
| | | o "Original-Mail-From:" - copy of the email address used in the MAIL | |
| | | FROM portion of the original SMTP transaction. The format of this | |
| | | field is defined in section 4.1.1.2 of RFC 2821 [4]. | |
| | | | |
| | | o "Original-Rcpt-To:" - copy of the email address used in the RCPT | |
| | | TO portion of the original SMTP transaction. The format of this | |
| | | field is defined in section 4.1.1.3 of RFC 2821 [4]. | |
| | | | |
| | | o "Received-Date:" - indicates the date the original message was | |
| | | received by the report generator. This field MUST BE formatted as | |
| | | per section 3.3 of RFC 2822 [5]. | |
| | | | |
| | | o "Source-IP:" - contains an IPv4 or IPv6 address of the MTA from | |
| | | which the original message was received. IPv4 addresses are to be | |
| | | formatted in dot-decimal notation as currently used by the | |
| | | community. IPv6 addresses MUST BE formatted as per section 2.2 of | |
| | | RFC 2373 [6]. | |
| | | | |
| | | 5.3 Optional Fields Appearing Multiple Times | |
| | | | |
| | | The following set of header fields are OPTIONAL and MAY appear more | |
| | | than once: | |
| | | | |
| | | o "Authentication-Results:" - indicates the result of an | |
| | | authentication check run by the report generator. The format of | |
| | | this field is is defined in draft-kucherawy-sender-auth-header | |
| | | [7]. Report receivers should note that this field only indicates | |
| | | an assertion made by the report generator. | |
| | | | |
| | | o "Reported-Domain:" - indicates a domain name that the report | |
| | | generator believes to be relevant to the report. Domain format is | |
| | | defined in section 2.3.1 of RFC 1035 [8]. | |
| | | | |
| | | o "Reported-URI:" - indicates a URI that the report generator | |
| | | believes to be relevant to the report. URI format is defined in | |
| | | RFC 2396 [13]. | |
| | | | |
| | | o "Removal-Recipient:" - indicates the email address to be removed | |
| | | from the mailing list (only used with "opt-out" feedback report). | |
| | | The format of this field is defined in section 3.4.1 of RFC 2822 | |
| | | [5]. | |
| | | | |
| 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 [4], 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 5, line 41 | | skipping to change at page 7, line 21 | |
| | | | |
| Optional parameters: none | | Optional parameters: none | |
| | | | |
| Encoding considerations: | | Encoding considerations: | |
| | | | |
| "7bit" encoding is sufficient and MUST be used to maintain | | "7bit" encoding is sufficient and MUST be used to maintain | |
| readability when viewed by non-MIME mail readers. | | readability when viewed by non-MIME mail readers. | |
| | | | |
| Security considerations: | | Security considerations: | |
| | | | |
|
| See section 3 of RFC 3462 [1] | | See the "Security Considerations" of this document. | |
| | | | |
|
| Interoperability considerations: none | | Interoperability considerations: implementors MUST ignore any fields | |
| | | they do not support | |
| | | | |
| Published specification: this document | | Published specification: this document | |
| | | | |
| Applications which use this media type: Abuse helpdesk software for | | Applications which use this media type: Abuse helpdesk software for | |
| ISPs | | ISPs | |
| | | | |
| Additional information: | | Additional information: | |
| | | | |
| Magic number(s): none | | Magic number(s): none | |
| | | | |
| | | | |
| skipping to change at page 6, line 19 | | skipping to change at page 7, line 47 | |
| Macintosh File Type Code(s): none | | Macintosh File Type Code(s): none | |
| | | | |
| Person and email address to contact for further information: | | Person and email address to contact for further information: | |
| | | | |
| Yakov Shafranovich <ietf@shaftek.org> | | Yakov Shafranovich <ietf@shaftek.org> | |
| | | | |
| Intended usage: COMMON | | Intended usage: COMMON | |
| | | | |
| Author/Change controller: IESG | | Author/Change controller: IESG | |
| | | | |
|
| 7. IANA Considerations | | 7. Extensibility | |
| | | | |
| | | Like many other formats and protocols, this format may need to be | |
| | | extended overtime to fit the ever changing landscape of the Internet. | |
| | | Therefore, extensibility is being provided via two IANA registries: | |
| | | | |
| | | one for feedback types and a second for header fields. The feedback | |
| | | type registry is to be used in conjunction with the "Feedback-Type" | |
| | | field above. The header name registry is intended for registration | |
| | | of new metadata fields to be used in the machine readable portion | |
| | | (part 2) of this format. Please note that version numbers do not | |
| | | change with new field registrations unless a new specification of | |
| | | this format is published. Also note that all new field registrations | |
| | | can only registered OPTIONAL fields. Any new required fields REQUIRE | |
| | | a new version of this specification to be published. | |
| | | | |
| | | In order to encourage extensibility and interoperability of this | |
| | | format, implementors SHOULD ignore any fields they do not support. | |
| | | | |
| | | 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 for "Feedback-Type" and "Authentication-Domain- | | setup two registries: one for header field names and a second for | |
| Method" headers. Below are the initial values for these registries. | | "Feedback-Type" values. This section contains the templates used for | |
| | | registration of new entries in these registries and initial values. | |
| | | New registrations to these two registries MUST have approval by an | |
| | | Designated Expert in accordance with the Expert Review guidelines as | |
| | | described in RFC 2434 [9]. Any new field registered is considered | |
| | | OPTIONAL unless a new version of this specifiction is published. | |
| | | | |
|
| Initial values for the "Feedback-Type" registry: | | For the header name registry, the following MUST be provided in an | |
| | | RFC publication (or Internet draft with IETF consensus or IESG | |
| | | approval) in order to register a new header field name: | |
| | | | |
|
| abuse - spam or some other kind of email abuse | | 1. Name of the field being registered | |
| | | | |
|
| opt-out - a request to opt out from a mailing list. | | 2. Short description of the field | |
| | | | |
|
| virus - report of a virus found in the originating message | | 3. Whether the field can appear more than once | |
| | | | |
|
| Initial values for the "Authentication-Domain-Method" registry: | | 4. Which "Feedback-Type" types does this field apply to (or "any") | |
| | | | |
|
| domainkeys - as defined in delany-domainkeys-base [5] | | 5. The RFC number (or Internet draft name) in which this header is | |
| | | registered | |
| | | | |
|
| iim - as defined in fenton-identified-mail [6] | | If the header field being registered requires its own IANA registry, | |
| | | than the appropriate registry MUST be properly defined. | |
| | | | |
|
| sender-id - as defined in lyon-senderid-core [7] | | For the feedback type registry, the following MUST be provided in an | |
| | | RFC publication (or Internet draft with IETF consensus or IESG | |
| | | approval) in order to register a new header field name: | |
| | | | |
|
| spf - as defined in schlitt-spf-classic [8] | | 1. Name of the feedback type being registered | |
| | | | |
|
| 8. Security Considerations | | 2. Short description | |
| | | | |
| | | 3. The RFC number (or Internet draft name) in which this feedback | |
| | | type is registered | |
| | | | |
| | | 8.1 Initial Values for the Header Names Registry | |
| | | | |
| | | The data below is populated from this document. The RFC number used | |
| | | for registration of these values is this document. | |
| | | | |
| | | Field Name: Authentication-Results | |
| | | Description: results of authentication check | |
| | | Multiple Appearances: Yes | |
| | | Related "Feedback-Type": any | |
| | | | |
| | | Field Name: Feedback-Type | |
| | | Description: type of feedback report | |
| | | Multiple Appearances: No | |
| | | Related "Feedback-Type": N/A | |
| | | | |
| | | Field Name: Original-Mail-From | |
| | | Description: email address used in the MAIL FROM portion of the | |
| | | original SMTP transaction | |
| | | Multiple Appearances: No | |
| | | Related "Feedback-Type": any | |
| | | | |
| | | Field Name: Original-Rcpt-To | |
| | | Description: copy of the email address used in the RCPT TO portion of | |
| | | the original SMTP transaction | |
| | | Multiple Appearances: No | |
| | | Related "Feedback-Type": any | |
| | | | |
| | | Field Name: Received-Date | |
| | | Description: date the original message was received | |
| | | Multiple Appearances: No | |
| | | Related "Feedback-Type": any | |
| | | | |
| | | Field Name: Reported-Domain | |
| | | Description: relevant domain name | |
| | | Multiple Appearances: Yes | |
| | | Related "Feedback-Type": any | |
| | | | |
| | | Field Name: Reported-URI | |
| | | Description: relevant URI | |
| | | Multiple Appearances: Yes | |
| | | Related "Feedback-Type": any | |
| | | | |
| | | Field Name: Removal-Recipient | |
| | | Description: email address to be removed from the mailing list | |
| | | Multiple Appearances: Yes | |
| | | Related "Feedback-Type": opt-out | |
| | | | |
| | | Field Name: Source-IP | |
| | | Description: IPv4 or IPv6 address from which the original message was | |
| | | received | |
| | | Multiple Appearances: No | |
| | | Related "Feedback-Type": any | |
| | | | |
| | | Field Name: User-Agent | |
| | | Description: name and version of the program used | |
| | | Multiple Appearances: No | |
| | | Related "Feedback-Type": any | |
| | | | |
| | | Field Name: Version | |
| | | Description: version of specification used | |
| | | Multiple Appearances: No | |
| | | Related "Feedback-Type": any | |
| | | | |
| | | 8.2 Initial values for the "Feedback-Type" registry | |
| | | | |
| | | The initial names and descriptions are provided below. The RFC | |
| | | number used for registration of these values is this document. | |
| | | | |
| | | o abuse - spam or some other kind of email abuse | |
| | | | |
| | | o opt-out - a request to opt out from a mailing list. | |
| | | | |
| | | o virus - report of a virus found in the originating message | |
| | | | |
| | | 9. Security Considerations | |
| | | | |
| See section 3 of RFC 3462 [1] | | See section 3 of RFC 3462 [1] | |
| | | | |
|
| 9. 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. | |
| | | | |
|
| 10. References | | 11. References | |
| | | | |
|
| 10.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] Resnick, P., "Internet Message Format", RFC 2822, April 2001. | | [2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |
| | | | |
| [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. | |
| | | | |
|
| 10.2 Informative References | | [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., | |
| | | Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- | |
| | | HTTP/1.1", RFC 2616, June 1999. | |
| | | | |
|
| [4] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet | | [4] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, | |
| Mail Extensions (MIME) Part Four: Registration Procedures", | | April 2001. | |
| BCP 13, RFC 2048, November 1996. | | | |
| | | | |
|
| [5] Delany, M., "Domain-based Email Authentication Using Public-Keys | | [5] Resnick, P., "Internet Message Format", RFC 2822, April 2001. | |
| Advertised in the DNS (DomainKeys)", | | | |
| draft-delany-domainkeys-base-02 (work in progress), March 2005. | | | |
| | | | |
|
| [6] Fenton, J. and M. Thomas, "Identified Internet Mail", | | [6] Hinden, R. and S. Deering, "IP Version 6 Addressing | |
| draft-fenton-identified-mail-01 (work in progress), | | Architecture", RFC 2373, July 1998. | |
| October 2004. | | | |
| | | | |
|
| [7] Lyon, J., "Sender ID: Authenticating E-Mail", | | [7] Kucherawy, M., "Message Header for Indicating Sender | |
| draft-lyon-senderid-core-00 (work in progress), November 2004. | | Authentication Status", draft-kucherawy-sender-auth-header-02 | |
| | | (work in progress), May 2005. | |
| | | | |
|
| [8] Wong, M., "Sender Policy Framework: Authorizing Use of Domains | | [8] Mockapetris, P., "Domain names - implementation and | |
| in E-MAIL", draft-schlitt-spf-classic-00 (work in progress), | | specification", STD 13, RFC 1035, November 1987. | |
| January 2005. | | | |
| | | [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA | |
| | | Considerations Section in RFCs", BCP 26, RFC 2434, | |
| | | 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] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet | |
| | | Mail Extensions (MIME) Part Four: Registration Procedures", | |
| | | BCP 13, RFC 2048, November 1996. | |
| | | | |
| | | [12] Crocker, D., "Standard for the format of ARPA Internet text | |
| | | messages", STD 11, RFC 822, August 1982. | |
| | | | |
| | | [13] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | |
| | | Resource Identifiers (URI): Generic Syntax", RFC 2396, | |
| | | 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 - An Sample Abuse Report | |
| | | | |
| 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: Email Abuse Report for IP 10.67.41.167 | | 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. | |
| | | | |
| --part1_13d.2e68ed54_boundary | | --part1_13d.2e68ed54_boundary | |
| Content-Type: message/feedback-report | | Content-Type: message/feedback-report | |
| | | | |
|