[Top] [All Lists]

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

2005-05-25 12:26:48

Bruce Lilly wrote:

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


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

Can you elaborate as to why the document must be split? For example, RFC 3464 includes the MIME registration in the same document. Why should this document, which is also a child-of-RFC3462 be any different?

The document suffers from the following serious defects:


   [X] missing or inadequate internationalization considerations

I am not sure what this is refering to. This is a message intended for machines, not humans, and follows the same conventions as RFC 3462 from which it descends. What internationalization issues have to be discussed?

   [X] incompatible with one or more Internet Standards

Can you be more specific? What Internet standards is this document not compatible with, what specific issues are there, etc.?

Specific issues with the draft:


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

This is a technical standard, not an editorial page. The "opt-out" option is included to be used in feedback loops from ISPs to legit bulk mailers such as SkyList, etc., not a general opt-out mechanism. It is perfectly viable according to the ISPs and the bulk mailers I have spoken to.

   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.

I will change it to read "this format is intended primarly for communications among providers, but can also be used in other situations". Would that be more clear?

   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.

This is a child-of-RFC3462. Whatever is specified there, applies here. Last time I checked, I did not see any of those options there or in any standards that descend from it such as DSNs and MSG-TRACK.

   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.

This issue was brought up by someone already. One option would be to relay just the headers of the message (an option included in this document). However, the consensus in the discussions that I had with ISPs is that this is something out of scope for this document. Rather, this is an issue for the abuse desks (sender and receiver) to deal with.

I do not see any other plausible solution short of mucking around with the RFC3462 format and making this even more complicated. Both ISPs and abuse desks have expressed their desire to keep this simple.

   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.

This was included due to the fact that smaller ISPs tend to use the Subject line for manual processing. This is currently the accepted convention and I don't know if mandating anything else will actually accomplish something.

However, what about prefixing the subject as follows:

"[FEEDBACK REPORT:] subject"

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

I did not find any other standard that defines the user agent field. The "User-Agent" and "Mailer" fields used by email programs are not defined in any standard that I was able to locate. Perhaps a new registration or document for the user agent field should be written, OR the syntax copied from RFC 2616 and included in this document in long hand.

   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.

It is refering to the following:

"MAIL FROM:" ("<>" / Reverse-Path)
                       [SP Mail-parameters] CRLF

Specifically to everything that appears after MAIL FROM. The format is probably the same as Return-Path header, but I wanted to reference the original SMTP transaction directly.

   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?

This is a child-of-RFC3462.

      o What about the promised extensibility?

There is an extensibility section.

      o Where are the syntax specifications for the fields?

Are you refering to ABNF?

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

DNS and message tracking standards do not register their fields with BCP 90 IANA registry. Since this is a similar child-of-RFC3462, I do not see why it should be any different.

   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?

This is a child-of-RFC3462, everything that applies there applies here as well (only 7bit ASCII).

   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.

See above comment re BCP 90 (and take a look at the DSN and MSGTRACK stuff as well).

   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:

Are you refering to the feedback-type keywords?

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

Other specifically refers to a case where the abuse reporter DOES NOT want to specific a specific feedback type and leave that task for the receiver.

   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.

I assumed that it includes all malware.

   o The Security considerations section is completely unacceptable.

Obviously, this is only a draft at this point and has not been sent to the IESG or anyone else for approval just yet. Rather, it is still something that needs work, and specific suggestions would be highly welcome. Blanket statements like the one above are not much helpful - of course I am aware that this section is not finished yet. If you would like to help writing it, I would be very happy.

   o References are normally unnumbered sections.

Can you provide a reasoning for this or is this simply something the community is used to?

   o Examples are badly broken.

Aside from the various 2822 problems highlited above, how so?

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

There is no current IETF list for this type of stuff. The ietf-822 list is not official at this point. When this spec becomes more mature, I will discuss with the appropriate ADs the best avenue for moving this forward. But for now, there is already a dedicated list for this.