I wrote:
>> Hmmm. There are two issues here: configurability and usability.
>> Requiring that all users separately configure a general mechanism to
>> meet the same goals seems silly. Usability requires that there be some
>> common base (code or configurations) that users can enable easily to
>> get policies that other people have carefully thought out.
rartym@??? wrote:
>Hmmm, that's an interesting idea. If I understand what you're suggesting,
>policies ought to be components, and individual users should be able to
>pick and choose and mix and match whichever policies they want, to create
>a tailored package that implements their individual requirement. In turn,
>each component may itself be a package of more primitive components, like
>basic header line matching rules, and typically an expert would carefully
>craft combinations of primitives for selection by end users. So, at the
>lowest level of expertise, a beginner might trivially pick just the bog
>standard "nospam" component, while more competent users might take that
>component and various others and combine them in some individual way, and
>experts could create totally original policies if they wished to do so.
>
>That's very much in the spirit of object-oriented design. I think it
>merits investigation. It certainly has the potential to place choice
>in the hands of the end user while also harnessing the skills of experts.
>Sounds good.
Although I was thinking sort of along these lines in terms of the
underlying implementation, my requirement suggestions could have been
satisfied by a single user-configurable bit (I want or do not want as
much spam as I can get), or by a lofty set of configuration parameters
that could be turned on by the end-user (or administrator) by setting
as many or as few bits as the user wants to understand. It should be
possible to get reasonable behavior with a small number of configured
bits.
There are some other issues. What I would think is also needed is
policies that the user can get, configure, and keep up-to-date with an
absolute minimum of fuss on his/her part.
An existing example of this would be the personalized web censorship
tools, which allow parents or kids to restrict what their kids or
parents can see by subscribing to a service that does most of the work
for them (and keeps violations of free speech up-to-date with a minimum
of fuss from the end user). My guess is that these services aren't as
easy to use as their advertisement's suggest, but that is more the
model I am thinking about.
The primary issue, as I see it, is that once user A has agreed to let
group B, with some political or other agenda, control what mail comes
into user A's little part of the electronic world, group B should be
able to react to changes in the behavior the nasty outside world to
continue to protect user A. User A should not have to continue
spending lots of time to understand or react to the changing outside
world. User A should make the basic choice to trust group B (which
could involve just downloading exim, thus giving trust to the exim
developers) and should then define some basic parameters (user A
doesn't want spam unless it contains dirty pictures of polititions).
Presuming the above model, it would be convenient if users could
somehow be updated as the nasty outside world changed. For example,
spamming pattern lists could be downloaded periodically, rather than
requiring downloading of a new exim release. It would be cute if
netnews could be used as a transport for this, together with some shell
scripts that run automatically from cron once a week. We used to do
this with UUCP network maps. It could work for anti-spam configuration
distribution, as well (though we would probably have to use secure
authentication nowadays).
--
Ronald S. Karr
tron |-<=>-| tron@???
