[feedback-report] ARF spec oversights

[Chris Drake]

Hi,

There's a few important omissions in the ARF standard that I think
need addressing.

1. Mandatory - Generator identity

   There needs to be a way to distinguish between human-generated
   reports, machine generated reports, vindictive malicious (eg: DoS)
   reports, and 3rd-party (eg: not the original recipient) reports.

   We need some extra mandatory fields to specify this
   
2. Recommended - confirmation status

   As 90%+ of the people on this list should know by now - the effect
   of AOL, Gmail, Hotmail, etc folks putting their "Spam" button right
   next to their "Trash" button means that a large number of users are
   hitting the wrong button by mistake.

   For mail operations who send zero spam and zero unsolicited and
   zero marketing emails, this results in an almost 100%
   false-positive complaint rate - that is - every single "spam" that
   gets reported is a result of a user hitting "Spam" by mistake.

   There needs to be a way for ISP staff to find actual spam
   complaints in amongst this sea of user errors, without having to
   read the personal emails of hundreds of "lame users".

   Having a recommended (or perhaps even mandatory - to highlight how
   important this is!) header to indicate whether or not the user
   "just hit the spam button", or whether they were given an
   opportunity to preview what they were about to report, and actually
   confirmed that it was "spam" - is important.

   Consider also that some emails are highly confidential, and are not
   suitable for sending to abuse desks immediately upon clicking a
   single button: rg: We also recently received a user-error
   spam-report containing some extremely confidential, personal
   banking information.
   
3. Recommended - "Feedback type selected by" header

   Lots of people hit the "spam" button when they get emails from
   their friends or enemies, and that they merely dislike the
   contents.  We need to know how the "Feedback type" was determined:
   is it an accurate description of the reason for the report which
   was something the reporting original recipient selected, or is it
   some kind of generic guess or hard-coded constant inserted by the
   reporting ISPs abuse system ?
   
4. Reporting individual Authentication

   There also needs to be a way to communicate to ARF report
   recipients the results of an authenticity check performed against
   the reporting individual - for example - a third-party might
   maliciously choose "select-all" then "report as spam" with the
   "remove" option selected to cause everyone that a victim
   communicates with to be barred from sending email to the victim in
   future.

   As on ISP administering this bar - I need to know by who's
   *legitimate*, authenticated, authority this bar has been selected.

5. Confirmation requests

   Finally - we need a way to communicate back with the original
   reporting entity - if they selected "remove" from a mailling list
   that they're paying $1000 per year to be listed on, we need to let
   them know that we honored their request, or if they submitted a
   non-authenticated request - we need to get them to confirm this,
   and we probably also need to get them their instructions for how to
   cancel their account and get a refund. 

Kind Regards,
Chris Drake