Apologies for my delays... I am currently heavily involved in some
critical and urgent work. I will address this at my earliest
opportunity.
_M
|-----Original Message-----
|From: Jonathan Morton
[mailto:chromi(_at_)chromatix(_dot_)demon(_dot_)co(_dot_)uk]
|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
|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.
|
|> 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
|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.
|
|> 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
|megaproposals.
|
|--------------------------------------------------------------
|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