Re: [Asrg] who has the message (was Re: Consensus Call - submission via posting (was Re: Iteration #3))

"Andrew Richards" <ar-asrg@acrconsulting.co.uk> Tue, 09 February 2010 13:08 UTC

Return-Path: <ar-asrg@acrconsulting.co.uk>
X-Original-To: asrg@core3.amsl.com
Delivered-To: asrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20B5D3A71C8 for <asrg@core3.amsl.com>; Tue, 9 Feb 2010 05:08:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.513
X-Spam-Level:
X-Spam-Status: No, score=-0.513 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTbj2DsVjFFj for <asrg@core3.amsl.com>; Tue, 9 Feb 2010 05:08:58 -0800 (PST)
Received: from mx.nwdb.co.uk (arichards02.wiredworkplace.net [213.143.2.79]) by core3.amsl.com (Postfix) with SMTP id D469F3A6D69 for <asrg@irtf.org>; Tue, 9 Feb 2010 05:08:57 -0800 (PST)
Received: (qmail 23481 invoked by uid 0); 9 Feb 2010 13:10:00 -0000
Received: (ofmipd 82.38.187.212); 9 Feb 2010 13:09:38 -0000
Date: Tue, 09 Feb 2010 13:10:00 +0000
Message-Id: <201002091310.00615.ar-asrg@acrconsulting.co.uk>
From: Andrew Richards <ar-asrg@acrconsulting.co.uk>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
User-Agent: KMail/1.12.2 (Linux/2.6.31-19-generic-pae; KDE/4.3.2; i686; ; )
References: <4B6C6D35.1050101@nortel.com> <201002082056.23128.ar-asrg@acrconsulting.co.uk> <4B707E65.3000806@nortel.com>
In-Reply-To: <4B707E65.3000806@nortel.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] who has the message (was Re: Consensus Call - submission via posting (was Re: Iteration #3))
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Feb 2010 13:08:59 -0000

On Monday 08 February 2010 21:13:09 Chris Lewis wrote:
> Andrew Richards wrote:
> > On Monday 08 February 2010 19:18:30 Dave CROCKER wrote:
> >> On 2/8/2010 11:11 AM, Andrew Richards wrote:
> >>>> The alternative requires that a copy of the message still be at the
> >>>>   server. That works in only some MUA-based models. 
> >>>> Often/typically, the entire message is downloaded to the MUA's site
> >>>> and the server no longer has a copy.  Hence, it's too late to enjoy
> >>>> merely passing a citation back to the server.
> >>>
> >>> I wish to imply that it would become a requirement for the server to
> >>> hold a copy if it wishes to implement this functionality
> >>
> >> That creates a massive barrier to adoption.  Huge implementation
> >>  overhead.
> >
> > However TiS is implemented will require implementation work on the
> > server- side, so I'm not sure that [2] is so different from [1] in
> > this respect.
> 
> If the MUA is manually configured, it requires zero implementation
> effort on the server end, and if configured thru MDA header insertion
> (eg: Something RFC5451ish), it may still only need a configuration
> change, not a code change.
> 
> _We_ can do TiS button correlation to a spooled copy (within expiration
> limits), and in fact we use it now.
> 
> [There's a couple technical reasons for it being done this way, but as
> implemented _now_, this is just a short-cut to make sure we can snip out
> the _correct_ logging information, and don't need to look at the body,
> whether stored or forwarded.]
> 
> But we're corporate, we have employee agreements that state that we can
> do this.  I'd hate to be <large ISP> and have to be answering the media
> frenzy if EFF found out we were preserving all email this way.
> 
> Forwarding the email is a deliberate action on the user's part, and you
> can easily handle privacy issues if you pay attention during
> implementation and deployment.  If you insist on retaining everything
> for everybody so as to do abuse reporting from a subset of your users,
> privacy can become a much more difficult issue, and a much bigger
> implementation one to program around privacy issues (eg: only doing it
> for users who've shown they want this).

I take your point on privacy. Would the following address this point:

The MUA communicates to the upstream provider for TiS for the model I'm 
advocating, so the MUA could use the same method to signal to the upstream 
provider if it's okay to retain messages for TiS purposes and for how long. 
The user has then 'opted-in' to having their messages retained.

cheers,

Andrew.