>
> 1 (a) (i) (2) b Token supported
>
> since CHANNEL seems to be a token.
This is correct. This is exactly what is meant by this
category. TDMA also
has similar capabilities.
I spoke to the developers at some length today.
They feel that the system isn't really very much like a white
list since white lists connote lists of senders and the
ZoEmail/CHANNEL system isn't looking at the
sender/from/reply-to fields at all.
Whitelists does not mean lists of senders. It is a method of explicity
allowing certain types of communication. While the common use is to
whitelist FROM addresses, there are other uses. For example, allow any
communication sent to the following address or allow any communication that
has this property.
Any given CHANNEL is usable by anyone that the correspondent
who knows that channel tells it to. (Much like a
"capability" in the operating systems sense of the word.)
They also tell me that since they can track who leaked a
channel to a spanner that ZoEmail/CHANNEL approach also
provides significant deterrents.
From this they argue that should be a (1)(c) category for
system which do both prevent and deterrents in an inseparable way.
I think that this is a property of any token supported system. Distribution
of the tokens can be done in a way such that redistribution can be tracked.
An example of this is 'keyword addresses' in TMDA.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg