Proposed Best Current Practice Document

This is an evolving document based on the discussion of standard spam reporting techniques in the Usenet newsgroup news.admin.net-abuse.email

Abuse Reporting

     This document is an Internet-Draft and is subject to
     all provisions of Section 10 of RFC2026.  It is intended to be
     a Best Current Practice document.

     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/1id-abstracts.html

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









     Abstract

     This is a method for creating standardized complaints
     of Internet abuse that is easy to generate by hand or 
     via automation, and which is easy to handle by hand or 
     via automation.  Automation does not relieve the sender 
     or the receiver of the need to inspect by hand.  Failure 
     of a report to adhere to this method is not a reason to 
     reject the report.  This document does not specify abuse
     policy.








     Contact








     Send comments to:



Usenet discussion area



How about an RFC for Spam Report Formatting?


Email
     In your email, start the Subject line with: [Reporting]
     George Crissman
     strads@tmisnet.com








     Related Documents and Definitions

     RFC 821  Email
     RFC 822  Email
     RFC 1855 Netiquette
     RFC 2142 Standard Reporting Addresses
     RFC 2234 Appendix A - Core
     RFC 2373 Appendix B - IPv6address, IPv4address
     RFC 2396 URI-reference, absoluteURI
     RFC 2822 Email

     User Generation Tool (Not functional)
         Sample Complaint Form
     Sample Report
         HTML
         Single-Line Format
         Block Format







     Introduction

     Unsolicited advertising email known as "spam" has been 
     growing rapidly on the Internet.  It is considered
     an improper usage of email (see RFC 1855) and is generally
     resisted and unwanted.  

     In addition, excessive crossposting of off-topic Usenet
     messages, also known as "spam", remains an ongoing problem
     that interferes with the usefulness of the news groups.

     Further, as technology advances, new techniques of presenting
     the user with unsolicited content have appeared and are likely
     to appear in the future.

     Given this continuing growth of spam in it's various forms, 
     it is desirable to create a standardized abuse reporting format 
     that is easy for an individual to create and read, a format that 
     lends itself to automation, and a format that is extensible.  

     The purpose of the standardized report is to politely inform 
     the ISP about abuse of the Internet that includes their equipment
     and service with a goal of correcting misconfigurations,
     enforcing the Acceptable Use Policy (also called Terms Of
     Service), and/or otherwise ending the abuse.  In addition, a
     standard reporting method will aid those subjected to Internet
     abuse to respond in an effective manner.  

     Given the widely varying level of expertise in System 
     Administrators, both in technical ability as well as 
     language comprehension, it is desired to keep the reports 
     polite, short, simple, and direct for best handling.

     Two methods are available.
     1.  A simple, block-oriented layout that is easy to learn
         and easy to parse by new users.
     2.  An expert, line-oriented layout that caters to
         detail-oriented reporting for skilled users.








     Security Concerns

     Safeguarding innocent email addresses

        Email addresses in specimens MUST be munged.
        A suggested munging method: leave the two 
        characters before the @ and the first three 
        after the @, replace the rest with "x", so:
        RoastedBillyGoates@hotmail.com would become
        xxxxxxxxxxxxxxxxes@hotxxxxxxxx

     Safeguarding innocent web sites
     Identifying fraudulent header information
     Identifying fraudulent abuse reports
     Bypassing automated report processing





     Basic Format: Markers

     Start Marker

     Notify: Boundary="---arbitrary string---"
     ---arbitrary string---
     <notification information>
     ---arbitrary string---

     Abuse-Specimen: Boundary="---arbitrary string---"
     ---arbitrary string---
     <raw spam, firewall log, whatever>
     ---arbitrary string---

     Continuation Marker (Optional)

     Previous: Boundary="---arbitrary string---"
     ---arbitrary string---
     <historical information, prior notifications>
     ---arbitrary string---

     Comment Marker (Optional)

     Comment: Boundary="---arbitrary string---"
     ---arbitrary string---
     <historical information, prior notifications>
     ---arbitrary string---

     End Marker

     No end marker needed.


     Basic Format: Markers surrounding Content

     The top of the report can optionally begin with a
     listing of marker identifications.  Otherwise, the
     identifications are declared where they are used
     throughout the text.

     Markers: Boundary="---arbitrary string markers---"
     ---arbitrary string markers---
     Notify: Boundary="---arbitrary string notify---"
     Abuse-Specimen: Boundary="---arbitrary string---"
     Previous: Boundary="---arbitrary string---"
     Previous: Boundary="---arbitrary string---"
     Previous: Boundary="---arbitrary string---"
     ---arbitrary string markers---

     ---arbitrary string notify---  /* Style #1 */
     W:   Who:        Identifies intended message recipient  
     A:   Action:     Specific abuse technique
     R:   Reference:  Isolated URI / Telephone Number / etc.
     H:   Header:     In-context URI / Telephone Number / etc.   
     B:   Body:       In-context URI / Telephone Number / etc.   
     T:   Attachment: In-context URI / Telephone Number / etc.   
     E:   Evidence:   URI to evidence file
     C:   Comment:    Free-form comment

     /* Note that one of H:, B:, or T: is chosen per block. */

     /* Style 2 */

     A:  Attn:        Identifies intended message recipient  
     T:  Type:        Specific abuse technique
     R:  Re:          Isolated URI / Telephone Number / etc.
     P:  Proof:       In-context URI / Telephone Number / etc.   
     S:  See:         URI to evidence file
     C:  Comment:     Free-form comment
     ---arbitrary string notify---

     One block of information is created for each
     implicated address or service provider.
     Multiple blocks are separated by a blank line.

     Up to six pieces of information may be contained
     in one block.
 
     Each block contains up to (and including) six parts --

     1.  Who is being addressed in this block.
          Answers the receivers questions, "Is this for me?"

     2.  What is being complained about (Action)
         Answers the receiver's question "Why am I involved?"

     3.  Proof from the attachment (Reference)
         Direct copy from the offending message, limited to
         a specific IP address, domain name, email address,
         or other specific contact method.

     4.  Location of the proof (Header, Body, File, Lookup)
         Identifies the location of the proof in the
         message, providing surrounding context for easy
         identification.

     5.  Evidence File (Web, Ftp)
         The URI of a detailed evidence file, if it exists.

     6.  Space for additional information (Comment)
         Free-form uncontrolled space allowing for additional
         comment by the sender.







     Appendix: Reporting

     Reports may be sent to the designated reporting address for:
     1.  The point of origin (determined from the headers)
     2.  Email drop boxes (if implicated)
     3.  Web sites (if implicated)
     4.  Regulatory authorities (if available)
     5.  Spam tracking services / block lists (if desired)
     6.  Online repositories
     7.  Other implicated parties (trademark protection)

     If the designated reporting address fails, alternate addresses
     may be determined and used.  Variations in the format according
     to destination are discouraged.







     Appendix: Example

     One unsolicited advertising email arrives with valid
     information in the headers, body, and attachment to
     the message.  One outgoing notification would be
     generated containing the following blocks at the top
     of the page:

     /* Original Identifiers (somewhat lacking) */
     Who:  Pacbell Net
     Action:  Source of Spam
     Reference:  123.234.212.131
     Header:  Received: from bestoffer.to
     (adsl-216-103-34-84.dsl.lsan03.pacbell.net
     [216.103.34.84])
     Evidence:  http://www.spews.org/html/S1417.html
     Comment:

     /* Alternate Identifiers (better) */
     Attn:  Yahoo Com
     Type:  Dropbox
     Re:  nofoolin@yahoo.com
     Proof:   simply <a href="mailto:nofoolin@yahoo.com">CLICK HERE</a>.
     See:  
     Comment:

     Who:  Bestoffer.to
     Action:  Target URL
     Reference:  > <a href="http://www.bestoffer.to/offers/dish.phtml">
     clicking here</a>
     File:  message.html
     Evidence:  http://www.spews.org/html/S1417.html
     Comment:

     Each item in the block begins with a different initial 
     letter, allowing a report to be condensed into a
     single-letter followed by a delimiter of some sort,
     followed by information.

     /* Original Identifiers (somewhat lacking) */
     W:  Intended receiver
     A:  Source of Spam
     R:  123.234.212.131
     H:  Received: from bestoffer.to
     (adsl-216-103-34-84.dsl.lsan03.pacbell.net
     [216.103.34.84])
     E:  http://www.spews.org/html/S1417.html
     C:

     /* Alternate Identifiers (better) */
     A:  Intended receiver
     T:  Source of Spam
     R:  123.234.212.131
     P:  Received: from bestoffer.to
     (adsl-216-103-34-84.dsl.lsan03.pacbell.net
     [216.103.34.84])
     S:  http://www.spews.org/html/S1417.html
     C:

     Missing information would not be cause to reject
     a given report, although a "complete block" would
     consist of six data lines.  Multiple blocks could
     be attached, one for each uncovered problem.
     Ordering of data within a block would be uncontrolled.

     W:
     C:
     R:  123.234.212.131
     A:  Source of Spam
     E:  http://www.spews.org/html/S1417.html
     H:  Received: from bestoffer.to
     (adsl-216-103-34-84.dsl.lsan03.pacbell.net
     [216.103.34.84])

     would be a valid sequence, for example.

     so would:

     H:  Received: from bestoffer.to
     (adsl-216-103-34-84.dsl.lsan03.pacbell.net
     [216.103.34.84])
     Evidence:  http://www.spews.org/html/S1417.html

     Mixing single-letter identifiers with complete
     identifiers is permitted.

     Generally, inclusion of all six data items in one
     block provides the greatest amount of information
     to the receiver and is preferred.

     Below the block information would be the complete
     headers and body of the spam message causing the 
     notification.







     Expert Mode

     For those who would like to use a one-line reporting
     format, a highly-controlled "expert block" 
     would be available.  The first line defines the
     specific data fields and delimiters used.  Expert mode
     ends with a blank line.

     X: <abuse type>: <abused resource>; <complaint target>
     SMTP-Relay: 10.2.3.4; abuse@isp.kr
     SMTP-Relay: 10.4.5.6; abuse@isp3.jp
     SMTP-Source: 172.17.18.19; abuse@uu.net.th
     Header-Mail-Address: dropbox@mail.com; abuse@outblaze.com
     Body-Mail-Address: bigmoney@yahoo.com.ag; abuse@yahoo.com.ag
     Body-Mail-Address: remove@eudoramail.co; abuse@eudoramail.co
     Body-URL: http://spamhaven.rackspace.net/pornpage?refid=abrunner;
     abuse@rackspace.net
     Body-URL: http://spamhaven.exodus.net/pornpage?refid=abrunner;
     abuse@exodus.net
     Body-URL: http://spamhaven.idt.net/pornpage?refid=abrunner;
     abuse@idt.net
     Sender-Incident: 1234356; spamreporter@mydomain.tld
     Related-Incidents: 234567,98765,233445; abuse@uu.net.th
     Related-Incidents: RT-0012,RT-0987; abuse@rackspace.net

Discussion

news.admin.net-abuse.email
How about an RFC for Spam Report Formatting?

Contributors