Re: [privacydir] draft-jdfalk-maawg-cfblbcp

The two sections you mention do map to a subset of the FIPs -- collection limitation, purpose specification, data quality, use limitation, and openness to some extent (I'm using the OECD FIPS available at http://www.oecd.org/document/18/0,3746,en_2649_34255_1815186_1_1_1_1,00&&en-USS_01DBC.html#part2). But I agree with you that there are other important ones missing, namely individual participation, which would give Message Recipients the ability to control whether feedback gets sent, and also openness vis a vis Message Recipients, which would allow them to be informed about the fact that feedback gets sent when they hit the 'report spam' button. To put it another way, I doubt that people realize that when they click 'report spam' that a message goes back to the spammer's mailbox provider, and this is something that they should be able to find out and have decoupled from any local mail client features associated with spam reporting (like sending the offending message to a spam folder).

The other missing FIPs are accountability (can Message Recipeints see logs of feedback that has been sent in the past?) and security (not sure this one is highly relevant here).

Alissa

On Oct 18, 2011, at 9:40 AM, Sean Turner wrote:

> I'm not sure if anybody else read the following draft:
> Complaint Feedback Loop Operational Recommendations
> http://datatracker.ietf.org/doc/draft-jdfalk-maawg-cfblbcp/
> 
> It's interesting that it has a privacy considerations and terms of use, which to me read somewhat (but not exactly) like what Hannes posted as the Fair Information Practices (FIPs) earlier this month on the IETF list, apply to the Feedback Provider (read ISP) and Feedback Consumer (read another ISP) but not to the End User who reported the Spam.
> 
> Thoughts?
> 
> spt
> _______________________________________________
> privacydir mailing list
> privacydir@ietf.org
> https://www.ietf.org/mailman/listinfo/privacydir
> 