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

Alissa Cooper <> Wed, 26 October 2011 10:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C6A7321F8AF9 for <>; Wed, 26 Oct 2011 03:03:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.281
X-Spam-Status: No, score=-102.281 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fb+iaQeSJi9u for <>; Wed, 26 Oct 2011 03:03:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B4C6021F8A66 for <>; Wed, 26 Oct 2011 03:03:47 -0700 (PDT)
X-Footer: Y2R0Lm9yZw==
Received: from localhost ([]) by (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Wed, 26 Oct 2011 06:03:36 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Alissa Cooper <>
In-Reply-To: <>
Date: Wed, 26 Oct 2011 04:03:35 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Sean Turner <>
X-Mailer: Apple Mail (2.1084)
Subject: Re: [privacydir] draft-jdfalk-maawg-cfblbcp
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Oct 2011 10:03:51 -0000

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,3746,en_2649_34255_1815186_1_1_1_1,00&&en-USS_01DBC.html#part2)l#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).


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