Support for 'folder' capability keys for Mutt. Assistence needed.
After first having looked at creating patches for mutt for the full
implementation, I am now actively working on making a separate library
for implementing 'folder' capability keys, that when finished could be called
from more lightweight patches to mutt.
As these patches will need to go to many places, and I would not want to
violate any overall design doing so, I would like to know if someone on the
list who has a thorough understanding of mutt's design would be interested
in working with me on this.
The 'mail capability key' or mck library is meant as an anti-spam solution
using a 'folder extended' e-mail address as a capability key.
The mck library aims to implements the concept of using key-extended
e-mail addresses as capabilities in order to countermeasure the SPAM
problem.
The idea for this library came to be as a result of a discussion on the
cap-talk mailing list about using capabilities to solve the SPAM problem.
The concept is that by using the folder notation <user>+<folder>@<domain>
where instead of a regular folder we use a password capability, we can
make e-mail addresses that can be used according to capability
paradigms. That is, the e-mail address becomes a single unforgeable
and sharable reference to the target, that can be revoked when at
any time SPAM is received trough it, without the high impact of actually
requiring a new e-mail address.
The libmck library tries to implement the address as key in such a way
that the following specifications are met:
1) A mailkey should be unforgeable.
2) It should be possible to trace back a mailkey to the entity to what
it was originally issued.
3) It should be possible and simple to filter (revoke) 'all' mailkeys
issued to a single entity.
4) It should be possible to trace back 'when' a mailkey was issued.
5) It should be possible to give a mailkey a certain validity period.
6) It should be possible and simple to filter (revoke) a single mailkey.
7) Sharing mailkeys as way of introduction should be encouraged, thus
new mailkeys should be created in some quantities in communication with
known peers.
8) It should be possible to use mailkeys with 'unpatched' mailing list
servers.
9) It should be possible to periodically start using a replacement master
secret key for mailkey generation without implicitly invalidating
mailkeys generated with the old key.
10) It should be possible to 'petname' individual keys in order to keep
track of keys used for introduction by peers.
Libmck is not yet completed, I am actively working on the implementation.
As the prime goal for this library is usage from a patched version of mutt
(and possibly procmail), I am searching for someone who would be
interested in working with me on this. Especially looking at the interface
libmck offers and finding the cleanest way to patch libmck usage into
mutt, while
not violating the overall design.
Rob
Rob