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
directories.
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:
http://www.ietf.org/internet-drafts/draft-shafranovich-feedback-report-01.txt
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)
draft-shafranovich-feedback-report-01.txt:
Checking nits according to http://www.ietf.org/ID-Checklist.html :
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 http://www.ietf.org/ietf/1id-guidelines.txt :
Nothing found here (but these checks does not cover all of
1id-guidelines.txt yet).
Miscellaneous warnings:
None.
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;
boundary="part1_13d.2e68ed54_boundary"
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)
--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
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
--part1_13d.2e68ed54_boundary
Content-Type: message/rfc822
Content-Disposition: inline
From: <somespammer(_at_)example(_dot_)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
X-NG: ->(mailserver.example.net [10.67.41.167])
RFC 821 [4.1.2] requires one space character
X-NG: RFC 821 [4.1.2] requires one space character
->=0D=0A
X-NG: <- RFC 821 [4.1.2] requires one space character
X-NG: ->M63d4137594e46 RFC 822 [4.1] requires
message-id
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
--part1_13d.2e68ed54_boundary--
The formatting of the document needs work. See [R8.formatting] and
[R9.formatting] and
http://www.rfc-editor.org/pipermail/rfc-interest/2005-January/000235.html
.
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
omissions)
[ ] 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:
sucessful
intented
encourages
is it allow
overtime
setup
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 4.1.1.2 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
detail:
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
"none"?
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
draft.
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
recommendation?
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:
Betrug"?
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
designation.
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.
References:
[R1.Checklist] Wijnen, B., "Checklist for Internet-Drafts (IDs)
submitted for RFC publication", February 2005,
http://www.ietf.org/ID-Checklist.html
[R2.ID] Fenner, B., "Guidelines to Authors of
Internet-Drafts", March 2005,
ftp://ftp.ietf.org/ietf/1id-guidelines.txt
[R3.Instruct] Reynolds, J. and R. Braden, "Instructions to Request
for Comments (RFC) Authors"
(draft-rfc-editor-rfc2223bis-08.txt), July 2004.
[R4.idnits] http://ietf.levkowetz.com/tools/idnits/
[R5.RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[R6.verify] TOOLS, "Available Verification Tools",
http://tools.ietf.org/verif-tools
[R7.mparse] Internet Message Format validating parser,
http://users.erols.com/blilly/mparse/index.html
[R8.formatting] RFC Editor, "Formatting RFCs and Internet Drafts",
http://www.rfc-editor.org/formatting.html
[R9.formatting] Lilly, B., "Writing Internet-Drafts and Requests For
Comments using troff and nroff"
(draft-lilly-using-troff-04.txt),
(draft-lilly-using-troff-04.ps),
(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
1982.
[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
2004.
[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
2003.
[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,
http://www.rfc-editor.org/errata.html
[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