Re: Goal: easier cpu parsable opt out tags

On Mon, 1 Mar 2004 14:29, Doug Royer wrote:
> - A mini protocol  between the MUA and the opt-out sites that allow
>    a user to opt-out in a standard way.

Even better, IMO, would be the following.

* Users do not want to "un-subscribe" from something that they never 
subscribed to in the first place. The default policy should be for 
subscription and un-subscription to be entirely under the control of the 
recipient, such that no third party can "subscribe" or "un-subscribe" them to 
anything.

This is, perhaps, a re-formulation of the "uniform interface to mailing lists" 
goal in conjunction with various "recipient control" goals. Note that the 
above does not recognise any form of spamming as a subscription: it only 
recognises recipient-initiated requests for mail as subscriptions. This 
doesn't exactly cover "opt out", which tacitly assumes a right for a sender 
to initiate a subscription. For those, we have the following requirement.

* Users want to be able to trivially blacklist any given sender.

This is more effective than an "opt-out", because opt out requires sender 
cooperation. It's still not entirely effective, though, because any given 
person can create an unlimited number of sender identities from which to 
spam. No sooner do you block amazingoffers.biz, than you start to get 
remarkably similar spam from bestdeals.info, or something like that.

Neither of these options preclude a formalised opt-out mechanism, but opt-out 
isn't necessarily something that we want to encourage, since it can 
facilitate abuse. Even if a spammer honours an opt-out request (on all 
current and future spamming runs), this does not prevent him selling the 
address to other spammers as a "confirmed active" address. This is 
counterproductive.

The best summary of the current suggestions with regards to recipient control 
of messages is currently at the following URI.

  http://www.cs.utk.edu/~moore/opinions/user-visible-email-ng-goals.html

James Seng's Wiki is more up-to-date, but not as conveniently organised so far 
as this particular subject is concerned.

  http://james.seng.cc/wiki/wiki.cgi?Mail-NG

Regards,
TFBW