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?
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.
OK, so you're saying that we need some kind of standard group of
settings - I'd suggest a standard file format which can be interchanged
between implementations - and a protocol to communicate those settings
*where necessary*.
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 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.
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.
Not necessarily. Conceptually, an e-postage system could preserve the
anonymity of the sender, as all the issuer really has to say is whether
the stamp's valid or not. Also conceptually, e-stamps could have
intrinsic value - and could therefore be re-used for future messages by
the recipient. That's not to suggest such implementations would be
easy, however...
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.
Noted.
--------------------------------------------------------------
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