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

Ian Eiloart <> Tue, 09 February 2010 13:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 573B428C1FB for <>; Tue, 9 Feb 2010 05:02:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.582
X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8qBuq-hbgXkb for <>; Tue, 9 Feb 2010 05:02:13 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0A6AF28C1FA for <>; Tue, 9 Feb 2010 05:02:12 -0800 (PST)
Received: from ([]:53775) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <>) id KXKSAI-000LW9-D2 for; Tue, 09 Feb 2010 13:03:54 +0000
Date: Tue, 09 Feb 2010 13:03:18 +0000
From: Ian Eiloart <>
To: Anti-Spam Research Group - IRTF <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <>
Originator-Info: login-token=Mulberry:01C3x+5nTd7EtM6dJId6J+8fFZcfSfQG6igOc=;
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] Consensus Call - submission via posting (was Re: Iteration #3)
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: Tue, 09 Feb 2010 13:02:14 -0000

--On 8 February 2010 13:05:06 -0500 Chris Lewis <> wrote:

> Andrew Richards wrote:
>> What bugs me about [1] is that the whole message is being re-sent, but
>> we  seem to have established that the only thing a spam button will be
>> saying  is "This is spam/unwanted", so sending a report including the
>> original  email for basically a single bit of information seems
>> excessive.
> In general, it isn't a "single bit of information", especially if you
> consider that this mechanism will undoubtably used to feed outsourced
> handlers who don't see your inbound mailstream at all.

A report to the mailstore operator need not be more than a few bits. I'd 
advocate at least two bits ("block" and "report"). But the value of the 
reports lies in crowd-sourcing them.

> Think SpamCop for example.
> I'm not sure why "exessive [volume]" is a particular concern.

It's a concern for users on low bandwidth connections. For example, my most 
frequent general complaints about spam volume come from people working in 
the field in countries with poor infrastructure. They want the most 
efficient access to mail that they can get. That means NOT downloading 
messages that they want to report as junk.

We're also seeing significant use of mobile devices for email - mostly 
iPhones at the moment. We expect to see that increasing.

Certainly the people with most incentive to report junk, are the ones with 
highest volumes of junk, and lowest bandwidth access.

> For the
> most part complaints are relatively rare, and this is only on that
> fraction that doesn't already get zapped by the filters. We're
> exceptional in the former (getting as much as 10-20% of all spam getting
> past the filters being reported as full forwards), but nobody has ever
> noticed the flow operationally.
> If you posit 100% "hit the TiS button", 100% spam, and _no_ filtering
> whatsoever, your outgoing from the user equals your incoming to the user.
> But if you're in a situation like that, one wonders why you have mail
> service or users at all.
> _______________________________________________
> Asrg mailing list

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