In order for the MTA to be able to do this, the end user must
be able to communicate policy decisions to it, so that the MTA
knows which messages are "unwanted".
If there were a standard for expressing and communicating such
policies, it would allow any MUA to communicate policy with any
compliant MTA. Then far more people would have the benefit of
using such a system.
I'm willing to volunteer to help draft such a standard, in line
with Section 2.6 of the Consent Framework. Who wants to help?
Can you be more specific as to what you wish to work on? Below is the
relevant section from the consent framework document. Keep in mind that
Eric Dean's CRI protocol for connecting C/R systems together is relevant
to 2.5, item #2 (protocols for sharing consent tokens).
Before defining a protocol to exchange consent information, we need to
define how consent is expressed in machine-readable form. This requires
taking care of all the the items in 2.6 before moving on to the
protocols.
I'm interested in creating a machine-readable format for
expressing consent policy. Clearly this is a pre-requisite to
defining protocols, because a protocol needs to have some data
to exchange.
Starting from the consent framework document:
2.6. Formats.
[Ed. We need to define:
1. Language and format for CONSENT AND SCOPE RULES
2. Format for CONSENT POLICIES.
3. Format for CONSENT TOKENS.
]
A few definitions to remind ourselves...
CONSENT POLICY ? a set of CONSENT RULES and SCOPE rules for
a specific RECEIVER
CONSENT TOKEN ? a piece of data that is used by the POLICY
ENFORCEMENT COMPONENT to grant or revoke CONSENT based on
the CONSENT POLICY
SCOPE RULES ? rules defining how CONSENT POLICIES are shared
I see the requirements for such a format as being:
- it should be capable of being efficiently parsed by a machine.
The grammar should not be ambiguous if possible
- it should be relatively easy for a human being to read.
This will aid debugging of protocol design and also allow
advanced users to write their own policy by hand
- it should be extensible, because new ways of detecting
spam will arise in future, possible involving new types of
rule or new consent token formats. This will allow some
adaptation when spammers change their tactics
If anyone wishes to suggest additional requirements, please do.
Once we get the requirements agreed, I have a list of other
things I'd like to iron out, starting with some definitions
of scopes and policy enforcement decisions.
Comments? Suggestions?
Andrew
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg