[feedback-report] ARF spec oversights

[J.D. Falk]

On 2006-05-24 00:23, Chris Drake wrote:

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

What's the use case you're thinking of?

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

Sounds like a user interface decision, rather than a problem with the 
standard.

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

That still sounds like a user interface decision, rather than a problem 
with the standard.

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

And that's a policy issue, not a technical issue.  If you think your 
users can't be trusted with a spam button, that's between you and your 
users.

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

Do any current implementations care about feedback type?

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

I'm not sure I understand the scenario you're describing.  Are you 
talking about random third parties somehow gaining access to a Report 
Generator's reporting system?

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

If you can't figure out who you sent the mail to, that's not the Report 
Generator's problem.

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Communications Platform Team