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

"Chris Lewis" <clewis@nortel.com> Mon, 08 February 2010 21:12 UTC

Return-Path: <CLEWIS@nortel.com>
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 092CA28C1AA for <asrg@core3.amsl.com>; Mon, 8 Feb 2010 13:12:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.537
X-Spam-Level:
X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 mEYaoO41gjZd for <asrg@core3.amsl.com>; Mon, 8 Feb 2010 13:12:35 -0800 (PST)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id C4F7E28C1A0 for <asrg@irtf.org>; Mon, 8 Feb 2010 13:12:31 -0800 (PST)
Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id o18LDUq12404 for <asrg@irtf.org>; Mon, 8 Feb 2010 21:13:30 GMT
Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Feb 2010 16:13:29 -0500
Received: from [47.130.64.86] (47.130.64.86) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 8 Feb 2010 16:13:29 -0500
Message-ID: <4B707E65.3000806@nortel.com>
Date: Mon, 8 Feb 2010 16:13:09 -0500
From: "Chris Lewis" <clewis@nortel.com>
Organization: Nortel
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
References: <4B6C6D35.1050101@nortel.com> <201002081911.55443.ar-asrg@acrconsulting.co.uk> <4B706386.5080501@bbiw.net> <201002082056.23128.ar-asrg@acrconsulting.co.uk>
In-Reply-To: <201002082056.23128.ar-asrg@acrconsulting.co.uk>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Feb 2010 21:13:29.0983 (UTC) FILETIME=[9006A0F0:01CAA903]
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: Mon, 08 Feb 2010 21:12:50 -0000

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