I have a few suggestions...
-----Original Message-----
From: asrg-admin(_at_)ietf(_dot_)org [mailto:asrg-admin(_at_)ietf(_dot_)org]
On
Behalf Of Kee Hinckley
<snip>
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).
There are a couple of obvious ways. Mailing list software that complies
with a "consent token" mechanism would store that token along with the
address of the list member, and would emit the token into the messages
in some way that is appropriate (probably as a header)... this would be
difficult in some cases, but not impossible. (the specifics of
implementation are a separate topic I think)
Another solution is for the RECIEVER to recognize the list processing
system as a legitimate sender and add a white list (consent) entry to
their policy. It is possible that this operation could be automated also
as follows:
1. Subscriber supplies a one-time token to the list manager.
2. List manager responds to subscription request with the one-time token
and sends that response from the list processor equipment (just like any
other list message).
3. Receiver recognizes the one-time token, records the sourcing
information from the list processor and creates an appropriate
white-list (consent) entry in the consent policy.
4. The token expires.
Any third party attempt to sign a receiver up to a list would fail
because no valid token would be present - so no consent entry would be
created. In addition, an attempt to do so with an incorrect consent
token could be registered as abuse. (Records of abuse could be shared
with other members of a COT that share policy information - again
another discussion).
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.)
Presumably, anyone who has a valid token for you can send to you
wherever you go as long as you remember the token. Your ability to send
messages to them from a new address _should_ work and would be seen as a
new introduction based on the token you are using - as if you had
provided the token to a third party to introduce them to "the group".
The key bit here is that since the consent token is controlled by the
receiver, and it is separate from the email addresses involved, then any
sender in possession of the token has the consent of the receiver - even
if they are using third party equipment and email accounts.
If control of the consent token is lost (it is stolen or given to an
inappropriate party) then the receiver can discredit the consent token
and send a replacement to the legitimate senders.
_M
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg