IIRC, in the Audrey draft nano is working on, emails are sent between
nodes as the data payload of the standard packet. Which of course is
encrypted/signed (forget which) for security.
--
Open Source, Open Mind
Why don't we go from the top down? At the very top, is the spam being
received. Right below that, is the okopipi client, be it
extension/plugin or standalone program. Under that is the connection
from this client to the network (done in p2p fashion). Under that, at
the very bottom, is the routing/transport protocol for communicating
between clients.
Spam -> Okopipi client -> network connection -> routing/transport.
Looking at it this way, we can proceed like this:
1) User identifies spam received.
2) User starts up okopipi client and reports the spam.
3) okopipi client connects to network.
4) okopipi client uses the underlying transport/routing protocol to
transport spam to other nodes for analysis, etc.
Eh?
where spam.txt is a dump from the mail client.
2. plugins to the common mail clients, that will rely on:
3. a okopipi dev lib, with binding to common languages.
Alrighty, let's gui-fy it a tad. Just make a big text input box and
allow the user to copy and paste the email (with full headers) from
their mail client. We can include instructions on how to obtain full
headers for the various mail clients. Thats a nice mail-client
agnostic solution.
Or better yet we WILL run the mail server on the local machine.
Except the email address they forward to will be a localhost address
(sp...@127.0.0.1, spam@localhost), and the mail server running as part
of the client will only accept connections from localhost. The
okopipi client, listening for mail, will then process and autosubmit
the spam message to the okopipi network.
This has the slight disadvantage of not working with webmail clients.
But in that case, we can use a browser extension to lift the entire
email message directly from the webmail client, a la greasemonkey.
~Kevin
lets get one generic way to get the spam in, further convenience methods
will come later.
We'd like to try and write an okopipi client, just to get some working
code and some progress. Hopefully a working client with stimulate
interest and development. I have done a small writeup on my wiki,
please respond to this message with any comments and changes.
http://www.therebelcountry.net/techdocs/index.php/Okopipi_Draft
Okopipi could of course develop something similar to Mailwasher, but
that seems a lot of unecessary work when some sort of plugin solution
could circumvent this and would add to the product cost. The plugin
does not have to be 100% universal to begin with, begining with the
most popular web browsers and mail clients. It also has to be simple
for the user, to overcome user inertia. Okopipi will need a large user
base to become successful in its aims.