4. Survey - Consent Model - Tokens (was Re: [Asrg] Nothing will stop spam???)

[Yakov Shafranovich <[e-mail]>]

Tokens can be based on a challenge/response mechanism, can be verified by 
trusted third parties such as CAs, etc. The whole notion of "consent 
tokens" is really a very generic terms that can encompass all types of 
tokens. The consent framework and any consent protocols must be able to 
support multiple token types, and allow for extensibility so new token 
types can be defined.

Yakov

At 07:50 AM 7/9/2003 -0400, C. Wegrzyn wrote:

>There are really two ways to handle this it seems. First is the notion of 
>"consent" token that travels with the message; this is the key that 
>unlocks the door on the receipient's email system. The second is the idea 
>of a list kept at the receipient's email system.
>
>The consent token traveling with the email seems to be somewhat 
>problematic. It would have to prevent middlemen attacks and for that to 
>happen the token would need to encode the source of the email message. I 
>believe that is a problem.  For instance I have two email clients with two 
>different email addresses - one being the company I work at and the other 
>being my personal account. Now if the token includes the originating 
>address I would have to have two different tokens. I would think we would 
>want a single token regardless of where I am and whatever address I use 
>and that would make a lot of work. But this single token would make it 
>susceptible to middleman attacks.
>
>In the receiver side screening mechanism, the second idea, I keep track of 
>addresses that I am willing to accept. As noted earlier very little mail 
>is sent through multiple MTA's (though I can tell you of one case that it 
>will happen!). This is patently more simple. I both cases - the token and 
>screening - I need to keep something to note who to allow through. But in 
>the former instance the sender needs to do something as well. Seems like 
>more work.
>
>Am I missing something here?
>
>Peace,
>Chuck Wegrzyn
>
>
>
>Kee Hinckley wrote:
>
>>At 9:14 PM -0600 7/7/03, Selby Hatch wrote:
>>
>>>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
>>
>>
>>That's in the case of my sending email to someone else.  I'm trying to 
>>figure out how a separate consent token fits into the case of my 
>>subscribing to this mailing list (for instance).
>>
>>>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
>>
>>
>>Again, recipient vs. sender issue.  I should be fine receiving from 
>>people I've agreed to receive from.  However what is the process for 
>>updating *their* consent to receive from *me*?  And how does it work if I 
>>don't get the opportunity to notify them until *after* the change.  (E.g. 
>>just got laid off.)
>
>
>
>_______________________________________________
>Asrg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/asrg


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