Re: [Asrg] Summary of junk button discussion

Ian Eiloart <> Mon, 01 March 2010 11:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B4C23A8708 for <>; Mon, 1 Mar 2010 03:52:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.443
X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q-7UnWW2TgIY for <>; Mon, 1 Mar 2010 03:52:16 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6771C3A8918 for <>; Mon, 1 Mar 2010 03:52:14 -0800 (PST)
Received: from ([]:50526) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <>) id KYLQD0-000BET-I0; Mon, 01 Mar 2010 11:53:24 +0000
Date: Mon, 01 Mar 2010 11:52:03 +0000
From: Ian Eiloart <>
To:, Anti-Spam Research Group - IRTF <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Originator-Info: login-token=Mulberry:01NynH4KCKNUV4lhtCo0+qnjpTnaHoOppPrJQ=;
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] Summary of junk button discussion
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <>
List-Id: Anti-Spam Research Group - IRTF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Mar 2010 11:52:17 -0000

--On 27 February 2010 14:08:37 +0100 Jose-Marcio Martins da Cruz 
<> wrote:

> Alessandro Vesely wrote:
>> On 27/Feb/10 07:22, Chris Lewis wrote:
>>> I'm aiming for a specification that permits a single <user action> to
>>> communicate upstream for _both_ filtering and reporting purposes,
>>> where whether it's used for filtering or reporting or both in any
>>> given instance is up to the site admin and/or end-user.
>> +1, and I would welcome an efficient IMAP implementation in that sense.
>> However, the spec should also allow to just send complaints.
> +1. "upstream communication is the idea". It's up to the (email
> address|device|...) to interpret how to interpret it and what to do with.

This is very sensible, but when you say "single <user action>", are you 
voicing support for the notion that only a single bit of data will be 
transmitted? Or will the vocabulary be richer than that? How about an 
extensible vocabulary?

For example, User Agents also have spam filters. It might be useful for 
such a filter to be able to make reports back to the administrator. Also, 
the user or the user's filter might want to say "this is not junk". Thus we 
have at least four messages that we might want to communicate to the admin. 
And, that's before we allow the user to express views on the type of junk 
that's present (boring versus offensive or potentially criminal).

Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see