Re: [Asrg] Re: 4d. Consent Framework - making it clearer
2003-10-01 19:40:33
Jonathan Morton wrote:
o Consent Expression Component: This involves recipients expressing
a policy that gives consent or non-consent for certain types of
communications
And this, I think, is the part which hasn't really been addressed yet
- at least, not by itself. I think the assumption has been that
it'll mostly live in the MUA, and is therefore safe to leave as a
implementation detail. Are you suggesting that the Policy
Enforcement should mostly live on the MTA, and therefore the
recipient's MUA must express consent (really, filtering preferences)
by communicating with the MTA?
The choice of where it lives is left ot the implementators. It maybe a
MUA that is also doing the spam processing, it could be a MUA
communicating with an MTA, it could be a MUA communicating with an
anti-spam tools, or it could be a dedicated GUI or webpage
communicating with anti-spam tools or MTAs. All possibilies are open
and we are not restricting to any of them.
OK, so you're saying that we need some kind of standard group of
settings - I'd suggest a standard file format which can be interchanged
between implementations - and a protocol to communicate those settings
*where necessary*.
A standard file format and a protocol is necessary. Standard settings
are not absolutely necessary but would probably be a set of basic stuff
common to most systems, with the possibilities open to expansion. Both
the format and the protocol need to be extensible as well. Keep in mind
the example that Gordon mentioned with SPITBOL - the extension mechanism
needs to be flexible enough to accommodate such scheme.
I think the "mechanisms" as I listed would be orthogonal to the
"components" that you speak of - so instead of placing them into one
category or the other, we have to see which mechanisms need part of
their implementation in each component.
You are correct about orthogonal nature of this - there are some tools
that will only fit one category, while others will cross over.
Most of the items mentioned above would be source tracing components
with the whitelist possibly being the policy enforcement component.
No... only two of them attempt to "trace" the source of the message.
The remainder are used to find out about the "worth" of the message
itself. The final filtering decision is presumably based upon
information from all of the mechanisms.
I would think that a source tracking component category would apply to
e-postage as well, specifically when verifying whether the e-stamp is
valid and the authority that issued it is valid as well.
Not necessarily. Conceptually, an e-postage system could preserve the
anonymity of the sender, as all the issuer really has to say is whether
the stamp's valid or not. Also conceptually, e-stamps could have
intrinsic value - and could therefore be re-used for future messages by
the recipient. That's not to suggest such implementations would be
easy, however...
Right - anonymous digital cash, forgot about that. I think that
anonymous digital cash has a bank signature on it also, it is just
issued anonymously. If e-stamps actually have an intrinsic value, then
they might belong in a different category.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
|
|