--On 2 March 2010 10:38:39 -0800 Steve Atkins <steve(_at_)blighty(_dot_)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(_at_)irtf(_dot_)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 mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg