Re: [Asrg] request for review for a non FUSSP proposal

Ian Eiloart <iane@sussex.ac.uk> Tue, 23 June 2009 15:18 UTC

Return-Path: <iane@sussex.ac.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 677A028C177 for <asrg@core3.amsl.com>; Tue, 23 Jun 2009 08:18:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Level:
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599]
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 mTkx04Wm55bu for <asrg@core3.amsl.com>; Tue, 23 Jun 2009 08:18:30 -0700 (PDT)
Received: from sivits.uscs.susx.ac.uk (sivits.uscs.susx.ac.uk [139.184.14.88]) by core3.amsl.com (Postfix) with ESMTP id 6B8B028C172 for <asrg@irtf.org>; Tue, 23 Jun 2009 08:18:30 -0700 (PDT)
Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:49506) by sivits.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <iane@sussex.ac.uk>) id KLP6JS-000FBB-99 for asrg@irtf.org; Tue, 23 Jun 2009 16:19:04 +0100
Date: Tue, 23 Jun 2009 16:18:43 +0100
From: Ian Eiloart <iane@sussex.ac.uk>
Sender: iane@sussex.ac.uk
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Message-ID: <BD2863274B2CC4BD8F817C35@lewes.staff.uscs.susx.ac.uk>
In-Reply-To: <4A40C3B4.5060103@telmon.org>
References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> <4A3FFB64.6030409@telmon.org> <20090622215251.GA2137@gsp.org> <4A400246.9060103@telmon.org> <1245709864.77647.26.camel@legolas.orthanc.ca> <E4491C663C5CE5D2397CAEDB@lewes.staff.uscs.susx.ac.uk> <4A40C3B4.5060103@telmon.org>
Originator-Info: login-token=Mulberry:01ocKtvQojGyLiLwEfDegUNyAwBzrOFwToFi0=; token_authority=support@its.sussex.ac.uk
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Sussex: true
X-Sussex-transport: remote_smtp
Subject: Re: [Asrg] request for review for a non FUSSP proposal
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, 23 Jun 2009 15:18:31 -0000

--On 23 June 2009 13:59:48 +0200 Claudio Telmon <claudio@telmon.org> wrote:

> Ian Eiloart wrote:
>
>> However, the burden placed
>> on end users should not be a cognitive burden - most won't cope.
>
> If I understand what you mean, then IMHO this framework should pass this
> cognitive test, since the availability of tokens to correspondents (and
> spammers) should be easy to understand... well, much easier than
> failures of digital signatures, DSN, and locks on web pages, anyway...

It the behaviour of the user is required to change, then that's a bad 
thing. I've not read the spec, so I'm not judging this proposal. Just 
correcting the claim that you can't burden the use at all. You can, but 
ideally you want to do it in ways that the user doesn't notice. If your 
spec requires a user to find something in addition to an email address, 
then it needs to be extremely easy to do.

Still, we're already in a position where people are fearful of publishing 
email addresses, so this spec might alleviate that problem. But, it isn't 
fundamental to combatting spam.

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/