plus syntax?
<consent token hash>+chuqui(_at_)plaidworks(_dot_)com?
Recipient user maintains a database of hashes with allowed addresses
they'll accept that hash from. Since a user (like me, or like a list
with monthly admin postings) might have more than one email address to
send from legitimately, allowing a token to map to more than one
address simplifies things. Allows users to manage access, revoke or
modify consent, and allows some flexibility in the use of the token
based on the real world. You could potentially flag some tokens as
being filtered to a folder for review, while other tokens filtered to
c/r and others to blacklist, based on why you generated them.
Given this, I think you could also create "good until" tokens, too, now
that I think about it. Maybe re-invent the web site mailto with a token
that's got some way of seeing when it was generated and can only be
used for, say, 24 hours after generation. That'd solve most of the
problems we see with role accounts without forcing everyone through c/r
stuff. Spammers would have to scrape and spam in real time, which is
still possible, but a lot harder.
On Thursday, April 10, 2003, at 10:19 AM, J C Lawrence wrote:
Quite. My tendency is that we should sketch out a protocol by which
the
subscription process can establish and maintain a consent token.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg