On Sat, 19 Apr 2003 01:00:05 -0400
Dave Lampert
<dlampert_c640993e_b876_4465_bf0e_964d0c4b0a35(_at_)homeai(_dot_)com> wrote:
We may all be talking about the same idea... see also:
Not quite. The proposal I'm writing for posting later this week
(current consulting permitting) is at its heart a protocol for consent
token manipulation, along with a set of suggested token types and a
possible model of how tokens supporting such __could__ be implemented.
The central expectation is that implementations at the MUA level will
vary extensively in both detail, and feature-set -- which is as it
should be.
[Asrg] Gray list: rating of associates
https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg01552.html
I'll ignore the patent aspects beyond the notes that:
a)I consider them patently ludicrous (pun intended)
and:
b) should they be enforced to any trivial degree; automatic and
instant cause for the proposal to be discarded with prejudice.
Instead of using a plus-type email like
"boffo+a90f234af57eee8bacab(_at_)there", it uses a GUID like the one I'm
sending my email from now.
There is nothing unique or interesting to a plus address, and in fact
there is nothing I've seen that you are doing which is particularly
different from a plus address. You have a way of taking a standard
"base address" and extending it with additional data, or taking such an
extended address and deriving from it a "base address". The fact of
what the extracted token is used for, or what data it represnts or its
other semantics are quite arbitrary and largely irrelevant. Those are
the exact same operations that plus addressing supports. The choice of
character or regex used is utterly arbitrary and quite unagreed upon in
the field.
I use this system now and it works whether other servers recognize
this new approach or not. Every email address is unique to the
sender-receiver pairing.
Sender consent tokens (using the TMDA definitions for convenience) are
only one form of consent token I'm looking to suggest. I've little
doubt that should this be adopted that most implementations won't do my
full set, and that a few will exceed it. <shrug> Which is as it should
be. Tokens should be opaque to all but their generators.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw(_at_)kanga(_dot_)nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg