[Top] [All Lists]

Re: I-D ACTION:draft-shafranovich-feedback-report-01.txt

2005-05-23 07:29:45
On Mon May 16 2005 15:38, Internet-Drafts(_at_)ietf(_dot_)org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts 

      Title           : An Extensible Format for Email Feedback Reports
      Author(s)       : Y. Shafranovich
      Filename        : draft-shafranovich-feedback-report-01.txt
      Pages           : 19
      Date            : 2005-5-16
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.

A URL for this Internet-Draft is:

This draft probably warrants some discussion on the ietf-822 list.

Review of         draft-shafranovich-feedback-report-01      by B. Lilly

Internet-Drafts and RFCs are required to meet certain criteria:
[R1.Checklist] (see also references in that document), [R2.ID],
[R3.Instruct].  These can be checked by using the "idnits" tool:
[R4.idnits].  That tool noted the following regarding the document:

idnits 1.71 (02 May 2005)


  Checking nits according to :

    Checking conformance with RFC 3978/3979 boilerplate...
    the boilerplate looks good.
  * There are 15 instances of too long lines in the document, the longest
    one being 44 characters in excess of 72.

  Checking nits according to :

    Nothing found here (but these checks does not cover all of
    1id-guidelines.txt yet).

  Miscellaneous warnings:


    Run idnits with the --verbose option for more detailed information.

The document contains:

   [ ] ABNF [R5.RFC2234]

   [X] Internet message (or fragment)

   Verification tools are available at [R6.verify] and/or [R7.mparse].

   Verification tools yielded the following results (for brevity, only
   one example is shown):

From: <abusedesk(_at_)example(_dot_)com>
Date: Thu, 8 Mar 2005 17:40:36 EDT
X-NG: Thu<- RFC 822 [5.2] prohibits date inconsistency (day-of-week) (Tue)
X-NG: Thu<- RFC 2822 [3.3] prohibits date inconsistency (day-of-week) (Tue)
X-Warning:                   ->EDT RFC 2822 [3.3] prohibits (when generating
 messages) obsolete zone
Subject: FW: Earn money
To: <abuse(_at_)example(_dot_)net>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report; 
X-Warning: RFC 2822 [2.1.1, 2.3, 3.5] strongly recommends against line length
78 octets (99)
X-Err: RFC 2821 [4.4] requires exactly one field (0 Return-Path)

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

This is an email abuse report for an email message received from IP on Thu, 8 Mar 2005 14:00:00 EDT.
For more information about this format please see

X-Warning: RFC 2822 [2.1.1, 2.3, 3.5] strongly recommends against line length
78 octets (113)
Content-Type: message/feedback-report

Feedback-Type: abuse
User-Agent: SomeGenerator/1.0
Version: 0.1

Content-Type: message/rfc822
Content-Disposition: inline

From: <somespammer(_at_)example(_dot_)net>
Received: from ( [])
     by with ESMTP id M63d4137594e46; Thu, 08 Mar 2005 14:00:00 
X-NG:                               ->( [])
 RFC 821 [4.1.2] requires one space character
X-NG: RFC 821 [4.1.2] requires one space character                         
X-NG:      <- RFC 821 [4.1.2] requires one space character
X-NG:                           ->M63d4137594e46 RFC 822 [4.1] requires
X-NG:                                         ->; RFC 821 [4.1.2] requires one
 space character
X-NG: RFC 2821 [4.4] requires CFWS            ->;
X-NG: RFC 821 [4.1.2] prohibits day-of-week     ->Thu
X-NG:                                           ->Thu RFC 822 [5.2] prohibits
 date inconsistency (day-of-week) (Tue)
X-NG:                                           ->Thu RFC 2821 [4.4] prohibits
 date inconsistency (day-of-week) (Tue)
X-NG:                                           ->Thu RFC 2822 [3.3] prohibits
 date inconsistency (day-of-week) (Tue)
X-Warning: RFC 2822 [2.1.1, 2.3, 3.5] strongly recommends against line length
78 octets (81)
To: <Undisclosed Recipients>
X-NG: Undisclosed Recipients<- RFC 822 [6.1] requires domain
 requires domain
X-NG: Undisclosed Recipients<- RFC 2822 [3.4, 3.4.1] requires domain
X-Warning:    -> RFC 2822 [3.4.1, 4.4] prohibits (when generating messages)
 CFWS in local-part
X-NG:          ->Recipients RFC 822 [6.1] requires one '@' (0)
 one '@' (0)
X-NG:          ->Recipients RFC 2822 [3.2.4, 3.4.1, 4.4] prohibits atom not
 followed by dot
X-NG:          ->Recipients RFC 2822 [3.4, 3.4.1] requires one '@' (0)
Subject: Earn money
MIME-Version: 1.0
Content-type: text/plain
Message-ID: 8787KJKJ3K4J3K4J3K4J3(_dot_)mail(_at_)example(_dot_)net
X-NG:                               ->@ syntax error, unexpected '@',
 expecting EOH
Date: Thu, 02 Sep 2004 12:31:03 -0500

Spam Spam Spam
Spam Spam Spam
Spam Spam Spam
Spam Spam Spam

The formatting of the document needs work. See [R8.formatting] and
[R9.formatting] and

The (intended) status of the document is:

   [X] Not indicated

   [ ] Experimental

   [ ] Informational

   [ ] Proposed Standard

   [ ] Draft Standard

   [ ] Internet Standard

   [ ] Best Current Practice

   However, the status as defined in [R10.BCP9] should be:

   [ ] Experimental (typically denotes a specification that is part of
       some research or development effort, subject only to editorial
       considerations and to verification that there has been adequate
       coordination with the standards process)

   [ ] Informational (published for the general information of the
       Internet community, does not represent an Internet community
       consensus or recommendation, subject only to editorial
       considerations and to verification that there has been adequate
       coordination with the standards process)

   [ ] Proposed Standard (generally stable, has resolved known design
       choices, is believed to be well-understood, has received
       significant community review, appears to enjoy enough community
       interest to be considered valuable, has no known technical

   [ ] Draft Standard (at least two independent and fully interoperable
       implementations from different code bases have been developed,
       sufficient successful operational experience has been obtained,
       unused options and features have been removed, well-understood,
       known to be quite stable both in its semantics and as a basis for
       developing an implementation, must have been Proposed Standard
       for at least six months)

   [ ] Internet Standard (significant implementation and successful
       operational experience has been obtained, characterized by a high
       degree of technical maturity and by a generally held belief that
       the specified protocol or service provides significant benefit to
       the Internet community, must have been Draft Standard for at
       least four months)

   [ ] Historic (A specification that has been superseded by a more
       recent specification or is for any other reason considered to be
       obsolete, must have been Standards Track)

   [ ] Best Current Practice (a way to standardize practices and the
       results of community deliberations, subject to the same basic set
       of procedures as standards track documents, the community's best
       current thinking on a statement of principle or on what is
       believed to be the best way to perform some operations or IETF
       process function, common guidelines for policies and operations
       which are generally different in scope and style from protocol
       standards, not well suited to the phased roll-in nature of the
       three stage standards track and instead generally only make sense
       for full and immediate instantiation)

   [X] The document should probably be split: registration of media
       types in the standards tree requires an RFC of any type.
       Registration procedures (which should be specified for
       registration of extension items) are typically specified in a BCP
       RFC.  Specifications with conformance criteria (which should be
       explicit) are typically Standards Track RFCs.

The document suffers from the following serious defects:

   [X] missing or inadequate security considerations

   [X] missing or inadequate internationalization considerations

   [X] incompatible with one or more Internet Standards

   [X] uses non-standard terminology which may lead to confusion,
       misinterpretation, and loss of interoperability.  Specifically,
       "header" is used where the term "header field" should be used,
       "header field" is used in places where fields in a specific media
       type are being referenced but where that type has no header,
       "content type" is used where the standard term "media type"
       should be used, and the term "address" is used in at least one
       place where the standard term "mailbox" should instead be used.
       Several non-standard terms used are nowhere defined.

   [X] [R11.BCP14] is referenced, but keywords are used inappropriately,
       and/or words which appear to be keywords are nowhere defined

The document could benefit from spell checking and careful proofreading.
A quick check reveals that the following are suspect:

                          is it allow
                          can only registered

Specific issues with the draft:

   o The term "feedback" is undefined.  As the stated intent of the
     media type is primarily for reporting email abuse, perhaps "email-
     abuse" should be substituted for "feedback".

   o The draft implies that "opt-out" is viable.  It is not, and the
     draft will meet some considerable resistance if it does not
     distance itself from that spammer-supported concept.  (opt-out is
     not viable because there are more than 10 billion potential senders
     of unsolicited material (nearly that many individuals, plus a large
     number of corporate entites).  Responding to a single message from
     each, at 5 seconds per response, working continuously, would take
     more than 1,500 years of uninterrupted effort.  How long do you
     plan to live, and do you wish to do something other than "opt-out"
     of unsolicited messages?)

   o The draft states "this format is intended specifically for
     communications among providers", implying that a mere individual
     (not a provider) cannot use it to report abuse to a government
     agency (also not a provider), for example.

   o The draft says "seeks to define a standard" and "the actual
     standard is defined in the next sections".  The term standard
     should be avoided when referring to an Internet-Draft [R2.ID].

   o The draft states "The first MIME part of the message contains a
     human readable description of the report" but does not state
     whether or not that part can be a MIME composite type (e.g.
     multipart/alternative).  Nor does it provide for (e.g.) an audio
     type, which might be appropriate if the recipient is known to be
     visually impaired.

   o The term "munge" is used, but is nowhere defined.

   o The draft states "it is RECOMMENDED that the entire original email
     message be included without any modification" but does not indicate
     how such a message containing a virus or other malware can be
     successfully conveyed in the presence of filtering (at the sender's
     site, in transit, or at the intended recipient's site) without
     encryption and/or encoding.

   o The draft states "The subject line of the feedback report SHOULD be
     the same as the included email message", which conflicts with the
     defined semantics of the Subject field as stated in RFC 2822, viz.
     a description of the topic of the message containing it, not a
     purported description of a different message.

   o The draft refers to "formatted according to the ABNF of RFC 822
     [14]"; RFC 822 uses EBNF, not ABNF.  A more appropriate reference
     would be RFCs 2234 (ABNF) and 2822 (Internet Message Format).  Note
     that RFC 822 is listed as being obsoleted by 2822.

   o The draft does not provide any ABNF or suitable formal syntax
     format for defining the fields that it claims to define.  There is
     insufficient information for an implementation.  Indeed, it is not
     possible to thoroughly review the draft proposal in the absence of
     some concrete definitions.

   o The draft refers to RFC 2616, which is an HTTP specification that
     uses a different field syntax from the Internet Message Format.

   o The draft refers to a version number, and specifies "0.1", but:

      o what does it mean?

      o Is it a floating point number, a serial number, etc.?

      o Is it decimal, hexadecimal, octal, or binary?

      o How are versions compared?

      o What is supposed to happen when a generated version is not
        recognized by a receiving implementation?

      o May comments, whitespace, and/or line folding appear within the
        version designation (as with RFC 2045 MIME-Version) or not?  See
        also RFC 2234 section 3.1.

   o In several proposed fields, e.g.  "Original-Mail-From:", the draft
     makes statements such as "The format of this field is defined in
     section of RFC 2821", whereas there is no such definition
     of any such fields in the referenced RFCs.

   o Optional fields are proposed for reporting domain names and for
     reporting URIs.  Many URIs contain domain names, but the draft does
     not specify whether or not domain names appearing in URIs should
     also be reported *as* domain names.

   o The draft seeks to define a media type with multiple fields (but
     N.B. not *header* fields in this case), but does not provide enough

      o Where's the syntax specification for the format?

      o What order should the fields appear in?

      o Is the order significant?

      o May empty lines appear between fields?

      o What about the promised extensibility?

      o Where are the syntax specifications for the fields?

      o Where are the BCP 90 registration templates for the fields?

   o The media type registration form doesn't say anything about a
     charset parameter, or about required charsets.  Can I send such a
     report in EBCDIC?

   o The media type registration form says: "Macintosh File Type
     Code(s): none".  MacOS file type codes are 4 characters.  Do you
     mean that the MacOS file type code is the four character sequence

   o The draft proposes establishing an IANA registry for header fields
     (actually fields which do not appear in a header).  There is
     already such a registry and corresponding registration procedure as
     established by BCP 90.  That mechanism could be used by extending
     BCP 90 in small ways to accommodate specifying applicability of
     fields to the defined media type proposed in the draft.

   o The draft uses the capitalized term "REQUIRE", which is not a
     BCP 14 keyword and the meaning of which is not defined in the

   o The draft needs to be reviewed for inconsistencies.  For example,
     the media type registration states "implementors MUST ignore any
     fields they do not support", whereas a subsequent section states
     "implementors SHOULD ignore any fields they do not support".  Is it
     a requirement per keyword usage guidelines in BCP 14, or a mere

   o There is no mention of architectural or internationalization
     considerations w.r.t. keywords.  Are keywords case-independent
     protocol elements or text?  Is it OK to use "Feedback-Type:

   o Security considerations are supposed to appear before IANA
     considerations [R3.Instruct].

   o Please don't break a line in the middle of a media type

   o "Feedback-Type: any" appears several times, and there does not
     appear to be any registration of "any", which is otherwise
     syntactically valid as a keyword.  The design needs to be carefully
     rethought (hint: define an alternative which is clearly not an
     single keyword, such as "*").  Likewise for "N/A".

   o The term "phishing" appears, but is nowhere defined.

   o The draft provides a catch-all "other - any other feedback that
     doesn't fit into other types".  How does one distinguish a
     subsequent extension from "other" (hint: only register types that
     have a specific definition)?

   o There is provision for one specific type of malware -- "virus", but
     not other types (worms, dialers, keystroke loggers, logic bombs,
     etc.).  The Security Glossary FYI may be a useful reference.

   o The Security considerations section is completely unacceptable.

   o References are normally unnumbered sections.

   o Examples are badly broken.

   o Discussion venue should be an IETF list for documents intended as
     IETF documents.

   o Regarding "outstanding issues" and encoding, beware of the
     restrictions specified in RFC 2045 section 6.4.

Please carefully review the references and resources indicated:

   [X] [R1.Checklist]

   [X] [R2.ID]

   [X] [R3.Instruct]

   [X] [R4.idnits]

   [X] [R5.RFC2234]

   [X] [R6.verify]

   [X] [R7.mparse]

   [X] [R8.formatting]

   [X] [R9.formatting]

   [X] [R10.BCP9]

   [X] [R11.BCP14]

   [X] [R12.FYI18]

   [X] [R13.FYI36]

   [X] [R14.STD11]

   [X] [R15.BCP18]

   [X] [R16.BCP22]

   [X] [R17.BCP26]

   [X] [R18.BCP61]

   [X] [R19.BCP72]

   [X] [R20.BCP82]

   [X] [R21.BCP90]

   [X] [R22.RFC1796]

   [X] [R23.RFC1925]

   [X] [R24.RFC1958]

   [X] [R25.RFC1982]

   [X] [R26.RFC2223]

   [X] [R27.RFC2822]

   [X] [R28.RFC3426]

   [X] [R29.RFC3439]

   [X] [R30.RFC3444]

   [X] [R31.RFC3536]

   [X] [R32.RFC3724]

   [X] [R33.RFC3930]

   [X] [R34.Errata]

   [X] [R35.Fields]

The following applies to the document being reviewed:

   [X] The document seems promising, but needs work.


   [R1.Checklist]  Wijnen, B., "Checklist for Internet-Drafts (IDs)
                   submitted for RFC publication", February 2005,

   [R2.ID]         Fenner, B., "Guidelines to Authors of
                   Internet-Drafts", March 2005,

   [R3.Instruct]   Reynolds, J. and R. Braden, "Instructions to Request
                   for Comments (RFC) Authors"
                   (draft-rfc-editor-rfc2223bis-08.txt), July 2004.


   [R5.RFC2234]    Crocker, D. and P. Overell, "Augmented BNF for Syntax
                   Specifications: ABNF", RFC 2234, November 1997.

   [R6.verify]     TOOLS, "Available Verification Tools",

   [R7.mparse]     Internet Message Format validating parser,

   [R8.formatting] RFC Editor, "Formatting RFCs and Internet Drafts",

   [R9.formatting] Lilly, B., "Writing Internet-Drafts and Requests For
                   Comments using troff and nroff"
                   (draft-lilly-using-troff-04.pdf), May 2005.

   [R10.BCP9]      Bradner, S., "The Internet Standards Process --
                   Revision 3", BCP 9, RFC 2026, October 1996.

   [R11.BCP14]     Bradner, S., "Key words for use in RFCs to Indicate
                   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [R12.FYI18]     Malkin, G., "Internet Users' Glossary", RFC 1983,
                   August 1996.

   [R13.FYI36]     Shirey, R., "Internet Security Glossary", RFC 2828,
                   May 2000.

   [R14.STD11]     Crocker, D., "Standard for the format of ARPA
                   Internet text messages", STD 11, RFC 822, August

   [R15.BCP18]     Alvestrand, H., "IETF Policy on Character Sets and
                   Languages", BCP 18, RFC 2277, January 1998.

   [R16.BCP22]     Scott, G., "Guide for Internet Standards Writers",
                   BCP 22, RFC 2360, June 1998.

   [R17.BCP26]     Narten, T. and H. Alvestrand, "Guidelines for Writing
                   an IANA Considerations Section in RFCs", BCP 26,
                   RFC 2434, October 1998.

   [R18.BCP61]     Schiller, J., "Strong Security Requirements for
                   Internet Engineering Task Force Standard Protocols",
                   BCP 61, RFC 3365, August 2002.

   [R19.BCP72]     Rescorla, E. and B. Korver, "Guidelines for Writing
                   RFC Text on Security Considerations", BCP 72,
                   RFC 3552, July 2003.

   [R20.BCP82]     Narten, T., "Assigning Experimental and Testing
                   Numbers Considered Useful", BCP 82, RFC 3692, January

   [R21.BCP90]     Klyne, G., Nottingham, M., and J. Mogul,
                   "Registration Procedures for Message Header Fields",
                   BCP 90, RFC 3864, September 2004.

   [R22.RFC1796]   Huitema, C., Postel, J., and S. Crocker, "Not All
                   RFCs are Standards", RFC 1796, April 1995.

   [R23.RFC1925]   Callon, R., "The Twelve Networking Truths", RFC 1925,
                   April 1996.

   [R24.RFC1958]   Carpenter, B., "Architectural Principles of the
                   Internet", RFC 1958, June 1996.

   [R25.RFC1982]   Elz, R. and R. Bush, "Serial Number Arithmetic",
                   RFC 1982, August 1996.

   [R26.RFC2223]   Postel, J. and J. Reynolds, "Instructions to RFC
                   Authors", RFC 2223, October 1997.

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

   [R28.RFC3426]   Floyd, S., "General Architectural and Policy
                   Considerations", RFC 3426, November 2002.

   [R29.RFC3439]   Bush, R. and D. Meyer, "Some Internet Architectural
                   Guidelines and Philosophy", RFC 3439, December 2002.

   [R30.RFC3444]   Pras, A. and J. Schoenwaelder, "On the Difference
                   between Information Models and Data Models",
                   RFC 3444, January 2003.

   [R31.RFC3536]   Hoffman, P., "Terminology Used in
                   Internationalization in the IETF", RFC 3536, May

   [R32.RFC3724]   Kempf, J., Austein, R., and IAB, "The Rise of the
                   Middle and the Future of End-to-End: Reflections on
                   the Evolution of the Internet Architecture",
                   RFC 3724, March 2004.

   [R33.RFC3930]   Eastlake 3rd, D., "The Protocol versus Document
                   Points of View in Computer Protocols", RFC 3930,
                   October 2004.

   [R34.Errata]    RFC-Editor errata page,

   [R35.Fields]    Lilly, B., "Implementer-friendly Specification of
                   Message and MIME-Part Header Fields and Field
                   Components" (draft-lilly-field-specification-03.txt),
                   May 2005.

Reviewer's Address

   Bruce Lilly

   Email: blilly(_at_)erols(_dot_)com