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/