[Top] [All Lists]

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

2003-10-03 07:27:45
Apologies for my delays... I am currently heavily involved in some
critical and urgent work. I will address this at my earliest

|-----Original Message-----
|From: Jonathan Morton 
|Sent: Wednesday, October 01, 2003 5:43 AM
|To: Yakov Shafranovich
|Cc: asrg(_at_)ietf(_dot_)org; Andrew Akehurst; Pete (Madscientist)
|Subject: Re: 4d. Consent Framework - making it clearer
|>> The "Consent Framework", while presently documented in an extremely
|>> formal and opaque manner, is nothing more than a "system of 
|>> 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 
|>> - Trust directories (identifying which payment and/or 
|>> 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.
|> 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.
|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 
|  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.
|> 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.
|>> - 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.
|>> 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.
|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 
|from:     Jonathan "Chromatix" Morton
|mail:     chromi(_at_)chromatix(_dot_)demon(_dot_)co(_dot_)uk
|tagline:  The key to knowledge is not to rely on people to 
|teach you it.

Asrg mailing list