[cap-talk] charging for spam. What are the implications
gmatht at gmail.com
Sun Jan 28 07:46:37 CST 2007
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
> 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
> 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
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
University of Western Australia
More information about the cap-talk