Re: [Asrg] Nothing will stop spam???

Kee Hinckley wrote:

> At 9:31 PM -0400 7/3/03, Kee Hinckley wrote:
>
> > > individual signs up, they would provide the consent token
> > > for the FTC to use when then sent a confirmation email. The FTC WEB
> >
> > This would probably degenerate to a simple password, since anything 
> > else would require tight integration between the email client and the 
> > web browser (and a signup may occur when the email client isn't 
> > available, or even over the phone).  That's not necessarily bad, but 
> > it should be recognized.  The other issue here is that this requires 
> > modifying tens, if not hundreds, of thousands of web forms and their 
> > backend databases.  Given that, it seems wise to make it possible to 
> > include the consent token in the email address, potentially as an 
> > option.  (Although of course that won't work with the FTC site, since 
> > they decided to invent their own concept of what an email address 
> > looks like.)
I considered the possibility of having a consent token as part of the
email address, something like recipient/token(_at_)mta(_dot_)net(_dot_) The 
major
problem with this is that the consent token is so closely tied to the
email address that it would be very easily compromised. You sell the
email address and the consent token in one simple transaction.

I view the consent token as a separate entity from the email address.
The consent token would be inserted from some source (address book,
keyboard, token repository, etc.) into a header by the MUA
-- implementation details.
> Sleeping on this I came up with some more issues (okay, I didn't sleep 
> very well).
> 1. Like many systems, this ties in tightly with identity.  If I move to 
> a new ISP (or Comcast gets sold *again*) my email address changes. How 
> do I manage notifying all of my contacts.  Some people seem to think the 
> address book model works, but I correspond with several orders of 
> magnitude more people than are in my address book, and some of them I 
> only send mail to every few years--I don't want to have to notify them 
> all of a change, nor is it clear to me *how* I would notify them of a 
> change without hitting the consent system again. It's probably 
> technically feasible, albeit difficult, to do so if I know in advance of 
> the change--but that doesn't always happen.  Right now people struggle 
> with simple things like transferring their address book, never mind 
> transferring consent.  A regular occurrence on wormalert is mail from 
> someone to all of their contents with a brief comment like "sorry, just 
> mailing myself a copy of my address book".  That's how they do it--they 
> put everyone in the to, including their new address.  So.  Without a 
> persistent concept of identity, consent is rather transient to the 
> recipient, never mind the sender.
Yes, unfortunately, unless you have a private domain, changing email 
addresses requires notifying senders. But, it should not require
giving out new consent tokens. The consent framework should be such
that if you change ISPs, consent tokens that are currently valid
would continue to be valid for your new email address at the new
ISP. Some mechanism should be in place to update the new MTA for
incoming mail with your old consent tokens.
> 2. If a consent token does degenerate to a password, then two problems 
> occur.  One, it can be sold along with your email address, just as email 
> addresses are sold now.  You've basically made it simple for someone to 
> transfer your consent.  the only way around that is to tie a consent
> token to the sender, 
Yes.
which means complicated software, and a knowledge
> of what addresses will be used to contact you.  
Yes.
(Again, I think people
> working on this should focus first on a URL scheme for whitelisting.  
> E.g. whitelist:some-piece-of-information-identifying-senders.)  
> Secondly, a single password doesn't contain information about what 
> you've consented to.  Did I tell them I want a receipt for my order, or 
> that I want a daily advertisement?
The single password may not be sufficient information, but the 
relationship of the sender to the consent token and any attributes
that may be specified would be.
> Note that the latter problem is what I see as a major failing of 
> do-not-spam-me lists.  How does a vendor know whether the presence of an 
> address on that list applies to what aspect of an existing business 
> relationship?  And if it doesn't, then what's the point? They shouldn't 
> be sending you email anyway.  This isn't an issue with phone call lists 
> because Sears doesn't call you up every day with a new ad, so you don't 
> lose anything by putting yourself on a donotcall list.
It would be up to the recipient to keep track of the sender/consent
token relationship. MUA software should do most of the work.


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg