Simplification
Timothy Mieszkowski
I've been following progress and I have a few suggestions that might
simplify the design.
First, the gnunet idea was great. That right there made the whole
project about 100 times easier. But what I got from that last thread
was that you are planning on forking the gnunet code? Why not just
design this as a plugin to GNUnet? The GNUnet project is already
portable to probably any system you can think of. This might be seen
as piggybacking on the network, but I think that is the point, I
believe the advantages of becoming a part of the GNUnet project would
become apparent down the line.
Second, I think I have a good idea about how to handle different mail
clients. Cutting and pasting as was suggested as a temporary fix is
just "wrong" in my opinion. I have about 100 spam in my spam folder
right now and that's just not going to happen. However, its too easy.
If you are familiar with the "menu" program from debian it could be
just like that. Basically you have a script directory, with a script
for each mail client you have. There is a standard responsibility for
the script to get the spams, and put them in another directory
somewhere that the program can do its thing with them. And all the
program has to do is run the scripts at a certain interval.
On that note I use gmail, and there is a python library called
libgmail which would work great for that. The other advantage of this
approach is you can use any language for the scripts. You simply need
an executable file for each client.
Third, is the whole gui thing. I really believe that the program
shouldn't be planned around a gui. For example sending the messages
to the gui and such. A supernode should have another directory where
the messages go to be classified or whatever. Of course
a gui will happen, it should just be a pretty interface to the true
workings of Okopipi. I think
that this would keep the design clean.
Anyway thats my two cents, sorry for the length but I've been thinking
about this for a while now.
-Tim
Mosinu
> Hi guys,
>
> I've been following progress and I have a few suggestions that might
> simplify the design.
> First, the gnunet idea was great. That right there made the whole
> project about 100 times easier. But what I got from that last thread
> was that you are planning on forking the gnunet code? Why not just
> design this as a plugin to GNUnet? The GNUnet project is already
> portable to probably any system you can think of. This might be seen
> as piggybacking on the network, but I think that is the point, I
> believe the advantages of becoming a part of the GNUnet project would
> become apparent down the line.
I have suggested we take advantage of GNUnet on a couple of occasions.
I think it would lessen the complexity. GNUnet already has security
features built in and an established network working.
>
> Second, I think I have a good idea about how to handle different mail
> clients. Cutting and pasting as was suggested as a temporary fix is
> just "wrong" in my opinion. I have about 100 spam in my spam folder
> right now and that's just not going to happen. However, its too easy.
> If you are familiar with the "menu" program from debian it could be
> just like that. Basically you have a script directory, with a script
> for each mail client you have. There is a standard responsibility for
> the script to get the spams, and put them in another directory
> somewhere that the program can do its thing with them. And all the
> program has to do is run the scripts at a certain interval.
> On that note I use gmail, and there is a python library called
> libgmail which would work great for that. The other advantage of this
> approach is you can use any language for the scripts. You simply need
> an executable file for each client.
While I like this idea, I think it would be easier for something
similar to a proxy design. This would let you report to the "proxy"
from any client, with no modification to the actual e-mail client. Just
use a local address (127.0.0.1) to report spam (i.e.
repor...@127.0.0.1). This removes the need for plugins for every
client, though they could be written to make it easier. The proxy part
would pass it off to the P2P functions and away it went. This would
also let us grab spam from webmail much easier and with less effort.
>
> Third, is the whole gui thing. I really believe that the program
> shouldn't be planned around a gui. For example sending the messages
> to the gui and such. A supernode should have another directory where
> the messages go to be classified or whatever. Of course
> a gui will happen, it should just be a pretty interface to the true
> workings of Okopipi. I think
> that this would keep the design clean.
>
I agree, a gui from the start is the wrong way to go, which is part of
the reason I am against targetting a specific platform from the start.
This locks the project to much early on. I guess the concern is that
windows users don't know much about computing, and won't know what to
do with a command line. If they plan this out right, a wizard could be
written by anyone to do the configurations for users but seperate from
the main code.
> Anyway thats my two cents, sorry for the length but I've been thinking
> about this for a while now.
>
> -Tim
Good ideas though. It is good to see at least some traffic again, I am
starting to think the project has lost the enthusiasm it had after the
fall of bluefrog....
Kevin Winter
> Hi guys,
>
> I've been following progress and I have a few suggestions that might
> simplify the design.
> First, the gnunet idea was great. That right there made the whole
> project about 100 times easier. But what I got from that last thread
> was that you are planning on forking the gnunet code? Why not just
> design this as a plugin to GNUnet? The GNUnet project is already
> portable to probably any system you can think of. This might be seen
> as piggybacking on the network, but I think that is the point, I
> believe the advantages of becoming a part of the GNUnet project would
> become apparent down the line.
I understand your point, however, i do not beleive this is polite. It
would be rather rude to make an okopipi plugin and use their
infrastructure/network without their permission. I think a better way
to do it (going along with keeping GNUnet a core componenet instead of
a fork) is to make okopipi a series of patches based on GNUnet. These
patches would add portability (as of right now they only official
support debian linux; windows porting has "reports" of success), add
new features, and allow a slightly modified GNUnet client to become an
okopipi client, joining our "web of trust". That way, we can submit
all of our patches to the GNUnet project in case they wish to
incorporate our changes into their project.
--
Open Source, Open Mind
Kevin Winter
> Timothy Mieszkowski wrote:
> > Second, I think I have a good idea about how to handle different mail
> > clients. Cutting and pasting as was suggested as a temporary fix is
> > just "wrong" in my opinion. I have about 100 spam in my spam folder
> > right now and that's just not going to happen. However, its too easy.
> > If you are familiar with the "menu" program from debian it could be
> > just like that. Basically you have a script directory, with a script
> > for each mail client you have. There is a standard responsibility for
> > the script to get the spams, and put them in another directory
> > somewhere that the program can do its thing with them. And all the
> > program has to do is run the scripts at a certain interval.
> > On that note I use gmail, and there is a python library called
> > libgmail which would work great for that. The other advantage of this
> > approach is you can use any language for the scripts. You simply need
> > an executable file for each client.
>
> While I like this idea, I think it would be easier for something
> similar to a proxy design. This would let you report to the "proxy"
> from any client, with no modification to the actual e-mail client. Just
> use a local address (127.0.0.1) to report spam (i.e.
> repor...@127.0.0.1). This removes the need for plugins for every
> client, though they could be written to make it easier. The proxy part
> would pass it off to the P2P functions and away it went. This would
> also let us grab spam from webmail much easier and with less effort.
Unfortunately, this won't work for either webmail or imap/pop3. The
127.0.0.1 address is the loopback interface. This is unique to the
machine doing the reference. When either a pop3/imap client such as
out/thunderbird/mutt sends an email (to spamr...@127.0.0.1), it
contacts its SMTP server (or in the webmail client, also contacts some
SMTP server). After connecting, it then send "send email to
spamreports located on server 127.0.0.1. the SMTP server then tries
to deliver the email to itself, presenting the obvious problem. The
only way around it for a non-webmail client would be to temporarily
change the SMTP server to localhost/127.0.0.1. This isn't universally
easy. Eventually, we need to create plugins/wrappers for every
client. In the meantime, copying and pasting is a simple workaround
for a proof-of-concept.
Mosinu
loopback. For instance I have the firefox bluefrog extension working
just that way now. I have a stripped down version of apache installed
with a simple python cgi that accepts posts from 127.0.0.1, and then
reports them to my configured reporting addresses (spamcop, ftc, acma,
etc).
In this case, my suggestion was to make an smtp server that listens on
127.0.0.1, once it has the messages it processes it locally, like any
smtp server would be. In the Unix world for example it might be
delivered locally by procmail. In this case, it would be handled by
Okopipi, which would pass it off to the P2P network rather than to an
inbox. With this route, you wouldn't need to write plugins for every
client, nor would you have to reconfigure the mail client. It would be
no different that reporting spam to sp...@uce.gov. You would send an
e-mail to your locally running smtp which would do the processing.
Plugins could be written to handle mass reporting or make it easier,
but it all boils down to an E-mail to an e-mail address. The webmail
piece would simply be a matter of a say a cgi like I am currently doing
reporting to 127.0.0.1 as well.
In my opinion this would be much quicker and easier than copy/paste,
and could be used for the long term. It is the simplest thing to ask a
user to simply forward e-mail to an address, what happens after would
be up to the application. No changes to the client are needed, and
honestly, no plugins would be required for local clients. That was one
of the things about bluefrog, it was simple to use and if you plan to
succeed you need to be as well.
Another reason for this, is that down the road it would let you tie in
more functions for parsing the e-mail when it is reported to the
client. This would let you push a lot of analysis back on the reporting
clients. If it has already been reported 1000 times before, do you
really want it going out over the network again or would you rather
just get the information of another hit of XXX spam? We can still track
who reported it and all the information we need without loading down
the network. It could also be used for statistics on what the user has
reported, all kept locally for each client.
Oh well just an idea, never expected it to be accepted.
Kevin Winter
> Actually that is the idea, I want it to report to itself over local
> loopback. For instance I have the firefox bluefrog extension working
> just that way now. I have a stripped down version of apache installed
> with a simple python cgi that accepts posts from 127.0.0.1, and then
> reports them to my configured reporting addresses (spamcop, ftc, acma,
> etc).
Well yes, this works fine, because the webbrowser contacts the server
(127.0.0.1) and submits the request. The difference is that a mail
client contacts an smtp server to send the email. You'll also find
that many users who have to use proxies wouldn't be able to do that
without turning the proxies off.
>
> In this case, my suggestion was to make an smtp server that listens on
> 127.0.0.1, once it has the messages it processes it locally, like any
> smtp server would be. In the Unix world for example it might be
> delivered locally by procmail. In this case, it would be handled by
> Okopipi, which would pass it off to the P2P network rather than to an
> inbox. With this route, you wouldn't need to write plugins for every
> client, nor would you have to reconfigure the mail client. It would be
> no different that reporting spam to sp...@uce.gov. You would send an
> e-mail to your locally running smtp which would do the processing.
> Plugins could be written to handle mass reporting or make it easier,
> but it all boils down to an E-mail to an e-mail address. The webmail
> piece would simply be a matter of a say a cgi like I am currently doing
> reporting to 127.0.0.1 as well.
This won't work - you'd have to change the sending smtp server to be
localhost in order to send. Here's another idea: make the okopipi
client an SMTP proxy. Then all the user needs do is reconfigure their
mail client once, to use 127.0.0.1/localhost. Then, have the smtp
proxy check the address for our spamr...@127.0.0.1 address, process
if it is spam, otherwise forward it on the the user's usual smtp
server (to get around ISPs like optimum online who require their users
use their own SMTP servers, blocking all others).
> In my opinion this would be much quicker and easier than copy/paste,
> and could be used for the long term. It is the simplest thing to ask a
> user to simply forward e-mail to an address, what happens after would
> be up to the application. No changes to the client are needed, and
> honestly, no plugins would be required for local clients. That was one
> of the things about bluefrog, it was simple to use and if you plan to
> succeed you need to be as well.
This is very true - a psuedo-smtp-proxy may turn the trick.
> Another reason for this, is that down the road it would let you tie in
> more functions for parsing the e-mail when it is reported to the
> client. This would let you push a lot of analysis back on the reporting
> clients. If it has already been reported 1000 times before, do you
> really want it going out over the network again or would you rather
> just get the information of another hit of XXX spam? We can still track
> who reported it and all the information we need without loading down
> the network. It could also be used for statistics on what the user has
> reported, all kept locally for each client.
Actually, the spam won't be transmitted more than once. Upon client
receiving a spam, it computes a hash of the message body, and sends to
hash to the network to find if the spam is a new spam, or an old one
with many hits.
> Oh well just an idea, never expected it to be accepted.
It'll work - just with a slight modification. You are perfectly
right, running an smtp server is a great idea, vastly simplifying
things. We just need to make it a proxy so it can handle all emails,
not just spam submissions.
Mosinu
written up on my website.
http://www.ibiblio.org/shadow/labs/
I even have working code already that does just this.
It proxies all incoming and outgoing smtp, pop3 and imap traffic. It
scans the message before it gets to your inbox, checks the rbls, uses
some baysien(sp?) filtering. You can white list addresses you
communicate with regularly so they dont get trapped. It even has P2P
capablities to check messages against other users for comparisons. It
does more, but I'm to lazy to explain it all right now.
Kevin Winter
>
> This was what I was saying for a long time, in fact even have it
> written up on my website.
>
> http://www.ibiblio.org/shadow/labs/
>
> I even have working code already that does just this.
> It proxies all incoming and outgoing smtp, pop3 and imap traffic. It
> scans the message before it gets to your inbox, checks the rbls, uses
> some baysien(sp?) filtering. You can white list addresses you
> communicate with regularly so they dont get trapped. It even has P2P
> capablities to check messages against other users for comparisons. It
> does more, but I'm to lazy to explain it all right now.
Well, that code could certainly prove useful. I notice that you have
not provided any code, nor chosen a license to provide code under.
Will that code be available for okopipi use/review?
~Kevin
Mosinu
better term, I am building. The rest of the system is under the GPL. So
yes, it is and will be available for Okopipi to use, modify or
whatever.
If you would like the code e-mail me.