Re: [Asrg] Summary/outline of why the junk button idea is pre-failed
Ian Eiloart <iane@sussex.ac.uk> Wed, 03 March 2010 11:28 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 881DE3A8D88 for <asrg@core3.amsl.com>; Wed, 3 Mar 2010 03:28:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.963
X-Spam-Level:
X-Spam-Status: No, score=-2.963 tagged_above=-999 required=5 tests=[AWL=-0.520, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156]
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 DQvfyVG8xa5k for <asrg@core3.amsl.com>; Wed, 3 Mar 2010 03:28:22 -0800 (PST)
Received: from sivits.uscs.susx.ac.uk (sivits.uscs.susx.ac.uk [139.184.14.88]) by core3.amsl.com (Postfix) with ESMTP id 3C4B83A8626 for <asrg@irtf.org>; Wed, 3 Mar 2010 03:28:22 -0800 (PST)
Received: from lewes.staff.uscs.susx.ac.uk ([139.184.135.133]:64229) by sivits.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <iane@sussex.ac.uk>) id KYPELD-0000KP-07 for asrg@irtf.org; Wed, 03 Mar 2010 11:29:37 +0000
Date: Wed, 03 Mar 2010 11:28:22 +0000
From: Ian Eiloart <iane@sussex.ac.uk>
Sender: iane@sussex.ac.uk
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Message-ID: <8AB182C5C16A028035F3564C@lewes.staff.uscs.susx.ac.uk>
In-Reply-To: <7FD79400-9C5E-4E5E-9F06-4079925AB512@blighty.com>
References: <20100302131810.GA22938@gsp.org> <Pine.GSO.4.64.1003020824500.16639@nber6.nber.org> <20100302155638.GA2653@gsp.org> <Pine.GSO.4.64.1003021158110.14693@nber6.nber.org> <7FD79400-9C5E-4E5E-9F06-4079925AB512@blighty.com>
Originator-Info: login-token=Mulberry:01icnNyfIqOy7KNiEr9e/8PkA870HuI+zv/jQ=; 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] Summary/outline of why the junk button idea is pre-failed
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: Wed, 03 Mar 2010 11:28:23 -0000
--On 2 March 2010 10:38:39 -0800 Steve Atkins <steve@blighty.com> wrote: > > On Mar 2, 2010, at 9:12 AM, Daniel Feenberg wrote: > >> >> >> On Tue, 2 Mar 2010, Rich Kulawiec wrote quite a lot. I don't propose to >> answer it directly - he doesn't introduce any new evidence or new >> arguments, just asserts his old arguments more loudly. Everyone reading >> the exchange is entitled to evaluate the arguments for themselves in the >> light of their own experience. > > +1 > >> >> There is one argument, not made by Kulawiec that does deserve a >> response. That is the underlying problem with the TIS button that is >> real. It will generate ARFs that are really just list-unsubscribe >> requests from perfectly legitimate sources. It will generate these in >> large numbers and it will be impractical to reduce them with user >> education. Anyone proposing to process the flood of such messages will >> have to come up with an economical way of doing so that doesn't >> inconvenience the list owners. > > They'll only be sent if the list owner has signed up for the ISPs > feedback loop. If the list owner believes the FBL reports will > inconvenience them, they need not request them. Where there's a list-unsubscribe button, the client should offer to unsubscribe rather than report the message. In fact, the button could even change its label. If the user still wants to report the message as junk, then the administrator has the option of unsubscribing the user. But, note, the user in a better position to answer the question "is it just this message that you're objecting to, or all messages from this list". In fact, that's a prime example of why you might want to distinguish between "block" and "report", and why the button needs to be labelled with a verb, not an adjective. > As a ludicrous extreme, if the list owners are sending email that is so > offensive that every single recipient hits the "TIS" button then they'll > have to be able to deal with no more inbound email than they're sending > outbound (and that only very briefly). > > More realistic numbers are at least two or three orders of magnitude > lower than that. If you're sending a million messages a day, all to ISPs > that you have signed up for feedback loop reports, then you might have to > deal with a couple of thousand feedback loop reports. That's a level of > traffic that's trivial to handle for a company that can manage a database > and MTA to send a million messages in the other direction. > >> In fact, I think most of the opposition to the TIS button comes from the >> owners of such lists who feel they would be the victims. To some extent >> they are justified - they are following the rules, why should they pay a >> penalty. But if the penalty were a small change in their operation, say >> an improvement in the standardization of list-unsubscribe headers - it >> might be justifiable. > > Most of the senders I've talked to think that the reports from the TIS > button at, eg, AOL are _great_. ESPs especially so. > > The marketers who object to the TIS button, tend to object to the concept > that their important mail can be described as "spam" by the recipient at > all. Whether that button sends a feedback loop report, adjusts MUA-level > filters, adjusts MTA-level filters or nothing much at all is very much > secondary to them. > >> >> Since any operator can just ignore the reports, it is unreasonable to >> claim that the TIS button will cause extensive damage to anything. They >> might be ineffective, but I don't think so. >> > > Cheers, > Steve > > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/
- [Asrg] Summary/outline of why the junk button ide… Rich Kulawiec
- Re: [Asrg] Summary/outline of why the junk button… Daniel Feenberg
- Re: [Asrg] Summary/outline of why the junk button… Jose-Marcio Martins da Cruz
- Re: [Asrg] Summary/outline of why the junk button… Alessandro Vesely
- Re: [Asrg] Summary/outline of why the junk button… Rich Kulawiec
- Re: [Asrg] Summary/outline of why the junk button… Alessandro Vesely
- Re: [Asrg] Summary/outline of why the junk button… Rich Kulawiec
- Re: [Asrg] Summary/outline of why the junk button… Martijn Grooten
- Re: [Asrg] Summary/outline of why the junk button… der Mouse
- Re: [Asrg] Summary/outline of why the junk button… Chris Lewis
- Re: [Asrg] Summary/outline of why the junk button… Daniel Feenberg
- Re: [Asrg] Summary/outline of why the junk button… Michael Thomas
- Re: [Asrg] Summary/outline of why the junk button… Steve Atkins
- Re: [Asrg] Summary/outline of why the junk button… Barry Shein
- Re: [Asrg] Summary/outline of why the junk button… Chris Lewis
- Re: [Asrg] Summary/outline of why the junk button… Chris Lewis
- Re: [Asrg] Summary/outline of why the junk button… Steve Atkins
- Re: [Asrg] Summary/outline of why the junk button… Daniel Feenberg
- Re: [Asrg] Summary/outline of why the junk button… BOBOTEK, ALEX (ATTLABS)
- Re: [Asrg] Summary/outline of why the junk button… Jose-Marcio Martins da Cruz
- Re: [Asrg] Summary/outline of why the junk button… John Levine
- Re: [Asrg] Summary/outline of why the junk button… Barry Shein
- Re: [Asrg] Summary/outline of why the junk button… Ian Eiloart
- Re: [Asrg] Summary/outline of why the junk button… Ian Eiloart
- Re: [Asrg] Summary/outline of why the junk button… Ian Eiloart
- Re: [Asrg] Summary/outline of why the junk button… Ian Eiloart
- Re: [Asrg] Summary/outline of why the junk button… Dennis Dayman
- Re: [Asrg] Summary/outline of why the junk button… Paul Russell
- Re: [Asrg] Summary/outline of why the junk button… Chris Lewis
- Re: [Asrg] Summary/outline of why the junk button… Ian Eiloart
- Re: [Asrg] Summary/outline of why the junk button… Barry Shein
- Re: [Asrg] Summary/outline of why the junk button… Steve Atkins
- Re: [Asrg] Summary/outline of why the junk button… Barry Shein
- Re: [Asrg] Summary/outline of why the junk button… Chris Lewis