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
