ietf-asrg
[Top] [All Lists]

Re: [Asrg] Re: 4d. Consent Framework - making it clearer

2003-10-01 19:33:38
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*.

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...

It would be overall better if proposal authors were more aware of the Consent Framework, and were thus able to design their mechanisms as single-purpose plugins to it, instead of jack-of-all-trades megaproposals.

Awareness of the consent framework may have been bad because of the "opaque" nature of the document. There are some proposal guidelines in the works that will include a requirement to consider the consent framework. HOWEVER, as per my other post it is possible that there are other ways to look at spam solutions beside consent.

Noted.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi(_at_)chromatix(_dot_)demon(_dot_)co(_dot_)uk
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg