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(_at_)(_dot_)(_dot_)(_dot_)
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(_at_)wanadoo(_dot_) 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