[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 draft-ietf-marf-base

Network Working Group                                    Y. Shafranovich
Internet-Draft                            SolidMatrix Technologies, Inc.
Expires: September 2, 2005                                    March 2005


            An Extensible Format for Email Feedback Reports
               draft-shafranovich-feedback-report-00.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   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 become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 2, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document defines an extensible format and MIME type that may be
   used by network operators to report feedback about received email to
   other parties.  This format is intended as a machine readable
   replacement for various existing report formats currently used in
   Internet email.





Shafranovich            Expires September 2, 2005               [Page 1]

Internet-Draft         Format for Feedback Reports            March 2005


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Intent . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.   Requirements . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.   Format of Email Feedback Reports . . . . . . . . . . . . . .   4
   5.   Format of 'message/feedback-report' Content Type . . . . . .   4
   6.   MIME Type Registration of message/feedback-report  . . . . .   5
   7.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .   6
   8.   Security Considerations  . . . . . . . . . . . . . . . . . .   6
   9.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .   6
   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .   7
     10.1   Normative References . . . . . . . . . . . . . . . . . .   7
     10.2   Informative References . . . . . . . . . . . . . . . . .   7
        Author's Address . . . . . . . . . . . . . . . . . . . . . .   7
   A.   Appendix A - An Sample Abuse Report  . . . . . . . . . . . .   8
   B.   Status of This Document [To Be Removed Upon Publication] . .   9
     B.1  Discussion Venue . . . . . . . . . . . . . . . . . . . . .   9
     B.2  Document Repository  . . . . . . . . . . . . . . . . . . .   9
     B.3  Document History . . . . . . . . . . . . . . . . . . . . .   9
        Intellectual Property and Copyright Statements . . . . . . .  10






























Shafranovich            Expires September 2, 2005               [Page 2]

Internet-Draft         Format for Feedback Reports            March 2005


1.  Introduction

   As the spam problem has grown in the past few years, network
   operators have begun to exchange abuse reports among themselves and
   other parties to combat this problem.  However, different operators
   define their own formats and the receivers are forced to write custom
   software to interpret the many types of them.  In addition, many
   operators use various other report formats to provide non-abuse
   feedback about processed email.  This memo seeks to define a standard
   extensible format and the "message/feedback-report" MIME type for
   these reports in accordance with RFC 2048 [4].  This format and
   content type is intended to be used within the scope of the framework
   of the "multipart/report" content type defined in RFC 3462 [1].

   This document only defines the format and content type to be used for
   these reports.  Determination of where these reports should be sent
   is outside the scope of this document.

   NOTE: This document may be incomplete and is intented to evolve based
   on public discussion and feedback

2.  Intent

   The reports defined in this document are intended for several
   purposes:

   a.  To inform ISPs about email abuse originating from their networks

   b.  To provide feedback to email service providers about abuse
       complaints

   c.  To inform the author of the message that the receiver wants to
       opt out.

   Note that the reports defined in this document are limited to
   providing feedback about email only.

3.  Requirements

   The following requirements are necessary for feedback reports :

   a.  They must be both human and machine readable

   b.  Copy of the original email message or email headers must be
       enclosed in order to allow the receiver to properly handle the
       report.





Shafranovich            Expires September 2, 2005               [Page 3]

Internet-Draft         Format for Feedback Reports            March 2005


4.  Format of Email Feedback Reports

   An email feedback report is a MIME message with a top level MIME
   content type of "multipart/report" (as defined in RFC 3462 [1]).  The
   following apply:

   a.  The "report-type" parameter of "multipart/report" type is set to
       "feedback-report".

   b.  The first MIME part of the message contains a human readable
       description of the report

   c.  The second MIME part of the message contains a machine readable
       abuse report with the content type of "message/feedback-report"
       (defined later on in this document).

   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"
       (as defined in RFC 2046 [1]) OR a copy of the headers from the
       original message with MIME content type of "text/rfc822-headers"
       (as defined in 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
       Feedback Report for IP X.X.X.X" where "X.X.X.X" is the source IP
       of the MTA from which the original message was received.  If
       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
       even though they are defined as optional in RFC 3462 [1].


5.  Format of 'message/feedback-report' Content Type

   The message/feedback-report content type consists of several header
   fields as follows:

   a.  "Source-IP:" - contains an IPv4 or IPv6 address of the MTA from
       which the original message was received.

   b.  "Received-Date:" - date the original message was received.  This
       field is formatted in according to the definition in section 3.3
       of RFC 2822 [2]





Shafranovich            Expires September 2, 2005               [Page 4]

Internet-Draft         Format for Feedback Reports            March 2005


   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 corresponding IANA registry.

   e.  "Authenticated-Domain:" and "Authenticated-Domain-Method:" -
       defines the authenticated domain and method used for perform that
       authentication.  The list of method tokens is contained in the
       corresponding IANA registry.  Note that the actual type of
       authentication used is outside the scope of this document.


6.  MIME Type Registration of message/feedback-report

   This section provides the media type registration application (as per
   RFC 2048 [4], which will be submitted to IANA after IESG approval of
   this document.

   To: ietf-types@iana.org

   Subject: Registration of MIME media types message/feedback-report

   MIME media type name: message

   MIME subtype name: feedback-report

   Required parameters: none

   Optional parameters: none

   Encoding considerations:

      "7bit" encoding is sufficient and MUST be used to maintain
      readability when viewed by non-MIME mail readers.

   Security considerations:

      See section 3 of RFC 3462 [1]

   Interoperability considerations: none

   Published specification: this document

   Applications which use this media type: Abuse helpdesk software for
   ISPs

   Additional information:



Shafranovich            Expires September 2, 2005               [Page 5]

Internet-Draft         Format for Feedback Reports            March 2005


      Magic number(s): none

      File extension(s): none

      Macintosh File Type Code(s): none

   Person and email address to contact for further information:

      Yakov Shafranovich <ietf@shaftek.org>

   Intended usage: COMMON

   Author/Change controller: IESG

7.  IANA Considerations

   After IESG approval, IANA is expected to register MIME type "message/
   feedback-report" using the application provided in this document and
   setup two registries for "Feedback-Type" and "Authentication-Domain-
   Method" headers.  Below are the initial values for these registries.

   Initial values for the "Feedback-Type" registry:

      abuse - spam or some other kind of email abuse

      opt-out - a request to opt out from a mailing list.

      virus - report of a virus found in the originating message

   Initial values for the "Authentication-Domain-Method" registry:

      domainkeys - as defined in delany-domainkeys-base [5]

      iim - as defined in fenton-identified-mail [6]

      sender-id - as defined in lyon-senderid-core [7]

      spf - as defined in schlitt-spf-classic [8]


8.  Security Considerations

   See section 3 of RFC 3462 [1]

9.  Acknowledgments

   The author would like to thank many of the members of the email
   community who provided helpful comments and suggestions for this



Shafranovich            Expires September 2, 2005               [Page 6]

Internet-Draft         Format for Feedback Reports            March 2005


   document including many of the participants in ASRG, IETF and MAAWG
   activities.

10.  References

10.1  Normative References

   [1]  Vaudreuil, G., "The Multipart/Report Content Type for the
        Reporting of Mail System Administrative Messages", RFC 3462,
        January 2003.

   [2]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.

   [3]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part Two: Media Types", RFC 2046,
        November 1996.

10.2  Informative References

   [4]  Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
        Mail Extensions (MIME) Part Four: Registration Procedures",
        BCP 13, RFC 2048, November 1996.

   [5]  Delany, M., "Domain-based Email Authentication Using Public-Keys
        Advertised in the DNS  (DomainKeys)",
        draft-delany-domainkeys-base-02 (work in progress), March 2005.

   [6]  Fenton, J. and M. Thomas, "Identified Internet Mail",
        draft-fenton-identified-mail-01 (work in progress),
        October 2004.

   [7]  Lyon, J., "Sender ID: Authenticating E-Mail",
        draft-lyon-senderid-core-00 (work in progress), November 2004.

   [8]  Wong, M., "Sender Policy Framework: Authorizing Use of Domains
        in E-MAIL", draft-schlitt-spf-classic-00 (work in progress),
        January 2005.


Author's Address

   Yakov Shafranovich
   SolidMatrix Technologies, Inc.

   Email: ietf@shaftek.org
   URI:   http://www.shaftek.org





Shafranovich            Expires September 2, 2005               [Page 7]

Internet-Draft         Format for Feedback Reports            March 2005


Appendix A.  Appendix A - An Sample Abuse Report


   From: <abusedesk@example.com>
   Date: Thu, 8 Mar 2005 17:40:36 EDT
   Subject: Email Abuse Report for IP 10.67.41.167
   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.


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

   Source-IP: 10.67.41.167
   Received-Date: Thu, 8 Mar 2005 14:00:00 EDT
   Original-Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net
   Feedback-Type: abuse


   --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--






Shafranovich            Expires September 2, 2005               [Page 8]

Internet-Draft         Format for Feedback Reports            March 2005


Appendix B.  Status of This Document [To Be Removed Upon Publication]

B.1  Discussion Venue

   Comments about this document should be sent directly to the author at
   via <ietf@shaftek.org>.

B.2  Document Repository

   Copies of this and earlier versions including multiple formats can be
   found at <http://www.shaftek.org/publications/drafts/abuse-report/>.

B.3  Document History

   Changes from draft-shafranovich-abuse-report-00 to
   draft-shafranovich-feedback-report-00:

   o  Name of the format and report changed to 'feedback-report'

   o  Minor spelling corrections

   o  Added authentication headers and registry

   o  Added feedback-type header and registry.



























Shafranovich            Expires September 2, 2005               [Page 9]

Internet-Draft         Format for Feedback Reports            March 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Shafranovich            Expires September 2, 2005              [Page 10]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/