Subject: Re: [Asrg] New take on emerging idea. (yet another C-R system?)

From: "John Fenley" <[email-masked]>
Date: Thu, 10 Apr 2003 11:24:42 -0600

>From: J C Lawrence <[email-masked]>
>Chuq Von Rospach <[email-masked]> wrote:
>
> > I think this is a key issue -- if you send an e-mail to someone, I
> > think there has to be an assumption of consent to accept a
> > response. But OTOH, I'm not sure it implies a permanent willingness to
> > accept a communication relationship.
>
>Quite, and its this logic, along with the risk of consent tokens being
>leaked to and abused by spammers which persuades me that consent tokens
>must be able to be date limited.  Without that a consent token becomes
>an infinite get-into-my-mailbox-free card.
>
> > so perhaps there ought to be two forms of consent here: a one time use
> > key and a revocable consent key, something that can be embedded in a
> > header or in some other way in the return mail to unlock the door.
>
>Currently I'm thinking about consent tokens having three potential
>properties:
>
>   1) Date range
>
>   2) Sender address
>
>   3) Date range and sender address
>
>Those three would seem to cover the bases, from list posts, to bounce
>forwarded messages, to tardy repliers etc.  MUAs would handle the dirty
>work of tracking etc.

Why give someone a key at all?
A consent token is like a temporary whitelist(with the obvious diference 
that a token can be used by a different sender), so why not do temporary 
whitelisting? then the user has control, and can cancel the whitelist entry, 
or make it permenant.

also with opt-in/opt-out, my system allows a user to see istantly everywhere 
they are opted-in, and gives them the ability to remove items, and opt-out 
easily.

>--
>J C Lawrence
>---------(*)                Satan, oscillate my metallic sonatas.
>[email-masked]               He lived as a devil, eh?
>http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.  
http://join.msn.com/?page=features/virus

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: J C Lawrence <[email-masked]>
Date: Thu, 10 Apr 2003 10:39:10 -0700

On Thu, 10 Apr 2003 11:24:42 -0600 

>> forwarded messages, to tardy repliers etc.  MUAs would handle the
>> dirty work of tracking etc.

> Why give someone a key at all?  

Because you want people to be able to reply to your email without going
thu a C/R system, but you don't want to open your email gates to the
thundering horde in the process.

> A consent token is like a temporary whitelist (with the obvious
> diference that a token can be used by a different sender)...

The sender address tokens mentioned above can ONLY be used by the stated
sender address.  The are effectively identical to TMDA sender addresses.
The token states that bubba@domain can email me with this token, but
nobody else can.

> ... so why not do temporary whitelisting? 

What address would I whitelist?  How would I chose that address for the
following cases?

  -- I post to a list and several list members reply off-list

  -- I email a friend and he bounces/forward my mail to a friend of his,
  who then replies.

  -- I post my address on a web form as, "Interested in receiving data
  about ProductX in the future."

ObNote: The last point suggests that some equivalent to TMDA's keyword
addresses (and a dated combination) would be useful.  <sigh>

> ... then the user has control, and can cancel the whitelist entry, or
> make it permenant.

Quite, but you have to know what to whitelist first.

> also with opt-in/opt-out, my system allows a user to see istantly
> everywhere they are opted-in, and gives them the ability to remove
> items, and opt-out easily.

If you do it via consent tokens, the user can see all the consent tokens
he as acquired from others, and the consent tokens he has grated
others.  He doesn't (necessarily) see how or why those tokens were
created or exchanged, or what traffic takes advantage of them.

Note that this process exposes another spam vector.  As systems will
have to maintain their private lists of consent tokens, then an obvious
spammer approach is to compromise systems (and subscribe to large
mailing lists) and collect tuples of address pairs and consent tokens.
If they can then inject forged mail with the appropriate envelopes and
tokens they can bypass the system.

  My suspicion is that should this happen it will be relegated to
  criminals (eg Nigerian spam) only.  Businesses using such a tactic are
  too easily subject to punitive lawsuits on the grounds of
  misrepresentation, fraud, impersonation, etc -- and given abuse it is
  too easy to carry such punitive measures forward to the clients of the
  spam companies that take that approach ("You should have made sure
  they didn't...").

---

From: Chuq Von Rospach <[email-masked]>
Date: Thu, 10 Apr 2003 10:41:17 -0700

On Thursday, April 10, 2003, at 10:24  AM, John Fenley wrote:

> A consent token is like a temporary whitelist(with the obvious 
> diference that a token can be used by a different sender), so why not 
> do temporary whitelisting?

the address you send the consent to may not be the address the reply 
comes from. Think about mailing lists, responses from amazon.com or 
other online services, etc. You want the consent in the token, not in 
the address. You may very well not know the address when you give 
consent.