[Top] [All Lists]

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