[Asrg] 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
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
- 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
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
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
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
tagline: The key to knowledge is not to rely on people to teach you it.
Asrg mailing list