Getting spam to the okopipi network

0 views
Skip to first unread message

Journeyman

unread,
Aug 7, 2006, 5:43:33 PM8/7/06
to okopipi-dev
Seeing as alot of the okopipi group has gone dormate I have been trying
to pick up the slack with the support of a few of the
steering-committee. I have working on how the okopipi protocol, and am
almost finished with the basic design but one detail I have yet to
figure out is getting the spam email onto the okopipi network, one idea
is to have each okopipi client run a simple mail server to receive mail
from the user, it would only accept mail from the users email
address(es) preventing abuse, but I don't see this as being the best
option, as some networks wouldn't allow the port to be open and then
other networks might already have a mail server running on it and it
would only confict with it. another idea would to have a very simple
pop3 client that would let you connect and select the spam email, this
would also allow for automatic filtering, of course that would be a
problem for webmail users, so an add-on for web browsers would be a
must for them. Both of these ideas have several flaws so please
express your ideas and thoughts

Kevin Winter

unread,
Aug 7, 2006, 5:46:32 PM8/7/06
to okopi...@googlegroups.com

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

Journeyman

unread,
Aug 7, 2006, 10:09:16 PM8/7/06
to okopipi-dev
the problem isnt the email(s) being sent across the network but getting
TO the network, ie the user to the okopipi network, and yes the spam
will be signed, I am not sure there is a need to encrypt it

Kevin Winter

unread,
Aug 7, 2006, 10:15:41 PM8/7/06
to okopi...@googlegroups.com
On 8/7/06, Journeyman <C130c...@gmail.com> wrote:
>
> the problem isnt the email(s) being sent across the network but getting
> TO the network, ie the user to the okopipi network, and yes the spam

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?

Journeyman

unread,
Aug 8, 2006, 8:48:40 AM8/8/06
to okopipi-dev
how does the user report the spam? that is the problem I am looking at
here, how does it go from spam in the users mail box to the okopipi
client. plugins would work but then we have to make a plug in for
every webbrowser and mail client. With BF you just forwarded the spam
to the report spam email they gave you, we need somthing similar. from
your example the problem we are looking at is at number 2 the reporting
process.

Omry Yadan

unread,
Aug 8, 2006, 9:52:51 AM8/8/06
to okopi...@googlegroups.com
1. command line client, for exmaple:
okopipi --import spam.txt

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.

Kevin Winter

unread,
Aug 8, 2006, 9:16:12 AM8/8/06
to okopi...@googlegroups.com

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

Journeyman

unread,
Aug 8, 2006, 9:31:52 AM8/8/06
to okopipi-dev
yeah thats what I was thinking, all you have to do is configure your
mail client to use the okopipi mailserver, and yeah a plugin/extension
would work great for grabbing webmail client. but we are going to make
an extension for FF IE netscape opera seamonky etc...?

Omry Yadan

unread,
Aug 8, 2006, 11:01:50 AM8/8/06
to okopi...@googlegroups.com
what difference does it make?

lets get one generic way to get the spam in, further convenience methods
will come later.

Kevin Winter

unread,
Aug 8, 2006, 11:01:03 AM8/8/06
to okopi...@googlegroups.com
Journeyman and I had a lengthy conversation about okopipi.

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

Roger Filomeno

unread,
Aug 8, 2006, 1:36:57 PM8/8/06
to okopi...@googlegroups.com
i have may own mail hosting so id like it if i can forward the email to sp...@mydomain.com then a script
checks is the sender belongs to the same domain then sends it away to the okopipi network thru whatever means
--
--
MSG GODIE <YOUR MESSAGE>
then send to 2948 for Globe/Sun and 3940 for Smart. Get yours FREE at www.TxtDomain.com
--
Roger P. Filomeno
Mobile Specialist / R&D
Finger Apps Inc, http://fingerapps.com
Blog: http://corruptedpartition.blogspot.com/

Journeyman

unread,
Aug 8, 2006, 7:09:45 PM8/8/06
to okopipi-dev
pretty good document. One thing is how we don't deal with the headers
and all, this would be useful if we where to work with other agencies
to shutdown spambots, but that may be to much for the okopipi project
to take on, atleast for now, wounder if we could work with spamcop to
forward our spams to them to look at *shurg*

Flash

unread,
Aug 17, 2006, 6:28:14 PM8/17/06
to okopipi-dev
I am not a techie but as a user I am very interested in this particular
question. I use Mailwasher to trap spam at my ISP's server, and a
similar mechanism for Okopipi would be ideal in that spam identified at
that stage would be sent straight to the Okopipi client before wasting
bandwidth going down the line to the users own mail client or web
browser. A plugin would simply pick up the email already identified as
spam, so no extra work for the user!

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.

Reply all
Reply to author
Forward
0 new messages