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

"Andrew Richards" <> Mon, 08 February 2010 19:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 713423A7261 for <>; Mon, 8 Feb 2010 11:18:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.487
X-Spam-Status: No, score=-0.487 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p0V2xHvbJpUl for <>; Mon, 8 Feb 2010 11:18:06 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 31FA93A7256 for <>; Mon, 8 Feb 2010 11:18:05 -0800 (PST)
Received: (qmail 12982 invoked by uid 0); 8 Feb 2010 19:19:05 -0000
Received: (ofmipd; 8 Feb 2010 19:18:43 -0000
Date: 8 Feb 2010 19:19:06 +0000
Message-Id: <>
From: "Andrew Richards" <>
To: "Anti-Spam Research Group - IRTF" <>
User-Agent: KMail/1.12.2 (Linux/2.6.31-19-generic-pae; KDE/4.3.2; i686; ; )
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] =?iso-8859-1?q?Consensus_Call_-_submission_via_posting_=28?= =?iso-8859-1?q?was_Re=3A=09Iteration_=233=29?=
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, 08 Feb 2010 19:18:07 -0000

On Monday 08 February 2010 18:05:06 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.
> Think SpamCop for example.
> I'm not sure why "exessive [volume]" is a particular concern.

Okay, let me rephrase that to "not elegant"

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

An example where this might be noticeable:
Bob receives a multi-megabyte email (with attachment etc) and decides to 
press the TiS button. He's on a modest ADSL or dial-up link, so if he 
returns the whole message in a report this will temporarily impact on his 
bandwidth which he may well notice. If instead just a few packets are used 
to communicate the unwanted UIDL / MessageID he'll not be troubled.

I think this is where elegance (= lightweight on bandwidth) helps in this 
situation. At the same time I grant that this would be introducing an 
additional burden on MTAs to store messages where they may not be doing so 
at present.

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