[cap-talk] charging for spam. What are the implications

[John McCabe-Dansted]

On 1/28/07, Rob Meijer <rmeijer at xs4all.nl> wrote:
> On Fri, January 26, 2007 04:13, John McCabe-Dansted wrote:
> I think I will thus start of with making a patch to mutt for the sending
> part. I was thinking about the folowing, that I would like to hear if
> I'm on the right track.
>
> 1) We add a config 'capgen_secret' that sets the global variable CapSecret
>    string.
> 2) We add a config 'known_mailinglists' that defines the path of a file
>    that lists any known mailinglists.

And we add xyz at a.com to known_mailinglists if a message comes in from
xyz-request at a.com with a valid cap?

Also we should bind the outgoing cap to be the incoming cap from the
subscription notification.

> 3) In send_message we call a function mutt_add_capability(env) that updates
>    the sender,from and replyto fields with a capability.
> 4) In mutt_add_capability we call a new function
>    mutt_check_known_mailinglist(env) that checks for any target being
>    in the file indicated by 2. If one is found than only the replyto
>    is updated with a capability.

The from field should contain the cap we subscribed to the mailing
list under, if any.

> 5) To create a cap the folowing algoritm is used:
>    A) All target adresses are sorted.
>    B) A SHA1 digest D1 is calculated over the sorted addresses.
>    C) A low granularity (multiple days or weeks) time string T is
>       determined from the current time.
>    D) A SHA1 check D2 is created using D1,T and CapSecret as data.
>    E) The cap key is created using the base64 encoding of D1,T,D2

Why does it matter how we generate the data/password cap? Couldn't we
just pull stuff from /dev/random?

> Do you agree this would be a good way to implement it?
> The filtering program (maybe a patch to procmail) could use the same
> secret to validate the keys, and could use a list of D1,T combinations
> as revocation lookup.

Also I'd have a function to output a new cap (+key??? address) so that
you can easily cut and paste it into a web page.

> If noone thinks this is a bad way to go I could look at patching Mutt like
> this.

I'm just glad someone has some energy.

> Maybe someone else on the list could bother looking at procmail?

Maybe later ;)

There should probably be a way in mutt to push unread mail from a
revoked cap back to procmail to be spam filtered again. Although
discussing that would be developer gold plating at this point :)

-- 
John C. McCabe-Dansted
PhD Student
University of Western Australia