Re: [Asrg] Re: 4d. Consent Framework - making it clearer
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
>>> 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
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
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.
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
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.
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.
Asrg mailing list