ietf-asrg
[Top] [All Lists]

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

2003-10-01 13:48:36
Jonathan Morton wrote:
>>> The "Consent Framework", while presently documented in an extremely
>>> formal and opaque manner, is nothing more than a "system of systems",
>>> aimed at combining the best-of-breed proposals (the exact ones to be
>>> determined at some time in the future) into a single, cohesive,
>>> implementable e-mail system.  Preferably, of course, leveraging the
>>> existing SMTP infrastructure, because that makes implementation
>>> several orders of magnitude easier.
>>
>>
>> Jonathan is correct - the consent framework seeks to tie in all of the
>> existing and future solutions into one system. The central tie-in
>> point to the whole framework is the notion of consent which is
>> presently absent from the email system while being present in some
>> form in other messaging systems such as Instant Messaging (IM).
>>
>> What the consent framework tries to do is to introduce this notion in
>> a standard way with protocols and formats, that can be carried over
>> all anti-spam tools. But I think Jonathan has expressed this in much
>> better way than me :)
>>
>>> I believe another goal is for additional components to be added to
>>> the framework as and when necessary, and therefore the system will be
>>> governed by some extensible protocol and/or message formatting
>>> standards.
>>
>>
>> Correct.
>>
>>> The main components of the framework might be:
>>> - Sender identification
>>> - Whitelist for stable sender/recipient relationships
>>> - Monetary payment (using tokens issued by trusted authorities, eg
>>> e-stamps)
>>> - Computational payment (generating tokens autonomously, eg hashcash)
>>> - Trust directories (identifying which payment and/or authentication
>>> authorities are trustworthy)
>>> - Message category labelling
>>
>>
>> The charter summarizes it into three components:
>
>

Excuse me while I reshuffle these...

o Source Tracking Component: This component provides deterrence to parties that consider violating the policy by facilitating identification and tracking of senders that violate the policy


This is covered by "sender identification" and "trust directories".

o Policy Enforcement Component: This involves subsystems within the communication system that enforce the policy.


The remaining mechanisms in my list (except the BCPs) fill this role.

But really, I think the distinction between the two is pretty slim. I'd rather have one Consent Verification Component with all the mechanisms put together.


That's open to discussion. Keep in mind that the charter is only suggesting, not dictating, as stated:

"POSSIBLE components of such a framework may include:"

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?

To be honest, I'm not sure that the MTA is usually in a position to receive filtering commands from the recipient's MUA. An MUA usually retrieves mail using POP3 or IMAP, not SMTP, which rather disconnects it from the inbound MTA - which in large ISPs is frequently disconnected from the outbound smarthost which the MUA *does* connect to via SMTP.

However, a logically separate MFA (Mail Filtering Agent) would perhaps be plausible - SpamAssassin run in "spamd" mode might be an example of this role. The MFA might be attached to the MTA, or be a plugin to the MUA, or even reside on a separate server (potentially run by the ISP or a third party) and be called by the MUA.


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.


Also, I think there's a fourth component missing from your list - the sender has to attach the relevant metadata/tokens to the message at (or near) origin. Most of the mechanisms I suggest must interact with this component, in addition to the others. This component probably has to include the concepts of mail-forwarding and listservs. Perhaps it might be called the Message Introduction Component?

Or was this what you originally meant by the Source Tracking Component? If so, 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 - they may be part of source tracking components in cases such as digital signatures or e-postage. However, in other cases this maybe reside in the policy enforcement component. What complicates this more is that the sender's tagging behavior might be looked at his expression of consent or response to one.

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.

For example, the lack of strong traceability of a particular message would normally cause the whitelist information to be treated as less reliable, but the lack of a strong whitelisting would probably be offset if it carried a (monetary or computational) payment token. Also, if the credentials carried by the message were found to have been generated by a discredited authority, this would probably reflect negatively on the message as a whole, whatever it carried.


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.

- BCPs for effective recipient filtering based on above facilities
- BCPs for senders (of various categories) for efficient use of above facilities


BCPs are basically the policy documents to make sure that the framework is used properly - kind of like manuals.


Still an essential part of the system.


Correct.

With any luck, that should make things a heap clearer for everyone (myself included), unless of course Yakov is going to point out how incorrect I am. :-)


Jonathan - your explanation has been extremely heplful. As a matter of fact, it seems that I will need additional help rewriting the framework document, specifically on how to rewrite it so "normal" humans can understand it :) If you wish to help with the writing and the editing, please contact me.


Yes, I think I could do that.


Thanks! Please contact me off-list.

But in particular, I hope that more list members now realise that the Consent Framework is in fact an important and useful document. There are a lot of proposals coming in which try to cover multiple aspects of the system at once (usually doing one well and others poorly), and I suspect this is due to ignorance of the framework and it's intentions.

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.

Yakov



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