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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg