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

Sean Turner <> Wed, 26 October 2011 11:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6AB6A21F8AD8 for <>; Wed, 26 Oct 2011 04:58:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.115
X-Spam-Status: No, score=-101.115 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MANGLED_SPAM=2.3, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JixJhRs-H1ie for <>; Wed, 26 Oct 2011 04:58:51 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 84B8521F89BA for <>; Wed, 26 Oct 2011 04:58:51 -0700 (PDT)
Received: (qmail 5806 invoked from network); 26 Oct 2011 11:55:11 -0000
Received: from ( by with SMTP; 26 Oct 2011 11:55:11 -0000
Received: from [] (port=39813 helo=thunderfish.local) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1RJ288-0002jT-Jf; Wed, 26 Oct 2011 06:58:49 -0500
Message-ID: <>
Date: Wed, 26 Oct 2011 07:58:48 -0400
From: Sean Turner <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Alissa Cooper <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-BWhitelist: no
X-Source-Sender: (thunderfish.local) []:39813
X-Email-Count: 6
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
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 11:58:52 -0000

The rest of the story with this draft is that it's just a re-publication 
of a MAAWG document.  MAAWG isn't an IETF WG.  It's getting published 
without the "This is an IETF consensus document" sentence even though it 
went through IETF LC because MAAWG is going to retain change control. 
So, if we want to make any change to what's in this particular draft 
we'd have to go to MAAWG.  However, when/if an IETF WG refers to this 
document (likely a MARF draft) - we'll make them address these concerns.


On 10/26/11 6:03 AM, Alissa Cooper wrote:
> 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 s
pam 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
>> 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