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

Bruce Lilly wrote:

> Spam Spam Spam

Using your header checker on a reported spam is unnecessary,
spammers are famous for not playing by the rules, and attempts
to "fix" the header of a reported spam would be a bad idea, as
long as the line lengths are still MIME compatible.  I had some
trouble when I tried to report a spam with more than 4096
characters in the Subject (one line) to fda.gov.

> http://www.rfc-editor.org/pipermail/rfc-interest/2005-January/000235.html

Oops, tnx for info.

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

My own definition of "feedback expected to make it to an abuse
desk" is "they MUST support RfC 2049" (otherwise RFCI, Admin-C,
ICANN WDPRS. nanas, the works, in that order), and especially
message/rfc822 or multipart/digest.

The actual problem / complaint / feedback (like say "abuse@...
submitted to rfc-ignorant.org") is stated in the subject, the
body is the forwarded evidence.

I found that that format has a serious chance to survive.  Of
course all B64 parts replaced by REMOVED, all suspicious file
types like pif in name= values replaced by pif.REMOVED, and
all strings "<iframe " replaced by "<!frame ".  If it's still
bounced I get seriously angry.

> The draft states "it is RECOMMENDED that the entire original
> email message be included without any modification"

Omigod, try this with say abuse@wanadoo.  Or with a 2 MB Nimda.
Or with 50 identical Sober-P, or any unmodified mail worm.  Or
with the mere string "<iframe " in the body.  It's hopeless.

> 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

Utter dubious, the original spam subjects never make it, and I
need the subject for the problem / complaint / feedback.  They
are contained in the forwarded message/rfc822 part(s).

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

| except that the order shown for the sub-items 7a-7f within
| Body of Memo is generally recommended but not required.

7c security, 7d IANA considerations.  No nitpicking intended, I
don't have it in that order in an I-D, but fortunately it's not
required.

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

There was also an IRTF ASRG list, but it is dead like almost
everything in the IRTF ASRG after MARID was opened and later
closed:  abuse-rep AT asrg.sp.am

>    [X] [R34.Errata]

How about replacing all [X] [Rxx.yyyy] (followed later by the
[Rxx.yyyy]) by just listing the relevant [Rxx.yyyy] ?  Plus an
URL to your complete Rxx list.  It's rather long.  Bye, Frank