Re: Support for 'folder' capability keys for Mutt. Assistence needed.
This sounds a lot like what TMDA already does. And I don't see why it
needs to patch mutt to work.
On Monday, 26 February 2007 at 09:12, Rob Meijer wrote:
> 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