Re: [Asrg] 4. Consent Framework - General

[Andrew Akehurst <A.D.Akehurst-99@student.lboro.ac.uk>]

Quoting John Fenley <pontifier@hotmail.com>:

>>> It seems to me that no matter what language the consent famework
>>> is writen in, the limiting factor is still the tests that can be
>>> performed. It does no good to have even a perfect consent >
>>> defenition if the tests that must be perfomed are not possible.

>> We're obviously limited by the bounds of conventional computation...
>> However there are plenty of tests that are readily computable and
>> the power of such a framework lies in the ability to logically 
>> combine tests and to enforce policy decisions at multiple points 
>> in the network. 

> I agree that there are many tests that could be used without
> Choicelist, but those tests are mostly "natural tests" such as 
> content analysis and the use of existing systems to clasify mail.
> I find that these tests are insufficient to define the types of
> consent i feel that people would want to define. ie...friends of
> friends, or personal vs commercial.

In that case we really should consider how to make Choicelist tests
available to anyone via the standard framework.

There could be a test to determine if the sender has the 
receiver's Choicelist consent via an opt-in. This could be used
for whitelisting messages.

There could also be a test to determine if a given sender is the
subject of a receiver's Choicelist opt-out, which could be used
for blacklisting messages.

In the light of your change of attitude (below) towards the 
commercial versus personal mail issue, maybe these will be
refined in future.

>>> I have created a consent framework that i feel is simple, 
>>> complete,and relies on tests that i know would be possible
>>> with the choicelist system I have been working on.

>> Re-reading your PDF at:
>>   http://www.ftc.gov/bcp/workshops/spam/Supplements/fenley.pdf
>>
>> ... I see Choicelist as being an implementation of a specific
>> consent system. (I don't mean that as a criticism of its 
>> generality,just an observation)

...8<...

>> Have I interpreted this correctly?
 
> Yes you have. At the time I wrote that, I believed that seperating 
> commercial mail would be suficient to solve most problems with 
> spam. I have since changed my view, and now see it as vital that
> personal mail be separated and protected.

Out of curiosity, what made you change your opinion?

> I have incorporated many of the views put forth on this list over 
> the last 4 months into an updated system. as you can imagine it 
> has evolved quite a bit. I do not at this time have a single 
> comprehensive overview of the current system available on the web 
> though i am working on one.

When you have another draft of it, please post a URL on the list.
I'm sure it will help us clarify some of the issues around the
consent framework.
 
>> The "Choicelist Database Query Protocol" you refer to at:
>>   http://www.choicelist.com/Personal.html
>>
>> ... would be a kind of consent protocol as defined in section 2.5
>> of the ASRG framework.
>>
>> Choicelist could be one of the implementation options available
>> in a standard framework, or else could become part of the
>> standard. If it is as powerful as you suggest then perhaps the
>> work on XML-CPDL ought to define standard test(s) for checking the
>> Choicelist status of a sender.

> The database query protocol is mostly a way to speed requests by 
> communicating behaviors to the requesting MUA. the protocol would 
> automatically refer requesting MUAs to open public mirrors to 
> distribute the load. it would also allow a "shimmering mirror"
> connection between mirror servers allowing the list of canceled 
> Ids to propagate almost instantly across all servers. all this 
> would happen seamlessly because of the nature of the protocol.

Sounds good. Load balancing is definitely a requirement for 
anything that provides a centralised consent lookup service.

> I am currently working on creating a working system. in it's most
> current incarnation there realy only need to be 4 types of tests,
> and these will be keyed lookups in a database. In this sense the
> "tests" have already been done and all that is required is a
> lookup of the test results.

What were these 4 types of test?

> I realy need to update my stuff and make it more readable... that page
> is something i meant to update a while ago.

Ok, well I'll wait until you have a newer draft.

>>> The attached file would be read as is by a Choicelist MUA.

>> Thanks, it's worth a read. There's definitely an elegant simplicity
>> about the way it looks.

...8<...

>>   - in your whitelist/blacklist command entries you specify some
>>     IP addresses to match against. Which IP address are you
>>     intending to match? And how would a Choicelist system
>>     deal with DHCP or NAT configurations, in which IP addresses
>>     are either unstable or not those of the machine you expect?
  
> Ip address compatability here would work the same way that Ip based
> lists are used currently... actually I don't realy know but i wanted 
> to allow the option for those who would choose to use it. 

I can see why it might be useful to have the feature in an 
implementation. However in the context of an overall consent framework
the definition of IP-based blocklisting could (and probably would) be
done using separate tests.

Such tests would probably make no reference to Choicelist data but
could be logically combined with Choicelist tests to produce some
quite sophisticated policies.

I can imagine wanting to have policy rules which state the equivalent
of:
   "Block all mail from 172.254.0.0/16 unless it originated from a
    Choicelist sender I have chosen to opt-in to"

Or if you defer to your favourite blocklist (say "Acme"):
   "Block all mail from Acme-DNSBl addresses unless it originated 
    from a Choicelist sender I have opted-in to"

Admittedly I've not stated these in a form very predicate-like. They
probably resolve to structures like:

 <AND>
   <TEST id="Acme-DNSl" method="Acme()">
   <NOT><TEST id="Choicelist-OptIn" method="Choice_OptIn()"></NOT>
 </AND>

 ("Sender is blocklisted by Acme and is not Choicelist whitelisted")

... which would map onto an action to reject the message.

This is just an example, but that's what it *might* look like in
XML-CPDL. I'm still pondering some ideas about the syntax in this
area of XML-CPDL and will mail out some ideas over the next couple
of days.

You could use the above kind of rule to get around some of the 
problems if a DNSBl service "goes bad". If a whole network IP block
gets a bad reputation because of a few spammers, users would still be
able to receive messages from the senders on that network whom they
have consented (via Choicelist) to communicate with.

And if Choicelist consent is expressed "out of band" (i.e. not via
e-mail messages or SMTP) then the use of e-mail blocking services
would not prevent such innocent senders on "bad" network blocks 
from establishing consent with new receivers.

> I personally see little use for these as the number of entries 
> in the database increases.

Yes, but until it does increase you need other tests in the meantime
to try and control the problem long enough for a full consent-based
system to become effective.

At least you have tried to allow for some short-to-medium term
solution so that the system could be phased in. Too many proposals
require an immediate massive change in internet practice in order
to have any chance of success.

Anyway there's plenty to think about while we await your new 
Choicelist documentation.

Thanks

Andrew

_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg