Graham's spam filter

[Heiko Wundram]

Am Fre, 2002-08-23 um 06.53 schrieb Erik Max Francis:
> You're missing my point.  If the spam filter involves connecting to a
> remote server and sending it each of your emails in order for the server
> to determine whether it is spam or not and respond, that server can be
> hijacked by a third party in order to record other peoples' emails.

This can be resolved quite easily, by using a secure tunnel to the
server (I was going to look into this anyway). This is actually no big
deal by itself, as the server will be positioned in our internal network
(134.96.56.*), whose packets aren't routed outside (except those
destined to go out), and at the moment internally everybody can read
everybody's emails anyway, as I stated in my last post.

If the mail-server itself gets compromised, there's even less point in
hiding data, as the people compromising it will be able to look into
/var/spool/mail anyway. That's my philosophy.

> Even when you're debugging the server, you yourself could be looking at
> clients' emails in order to determine whether or not the server is
> working properly.  The design _itself_ is what's suspect, not your
> motives in particular.

I'll debug this thing on my own computer. A field trial will only be
done when I and several other geeks here have found the program to be
sufficiently neat enough to be put to general use.

And as I said: The final destination of the project is certainly not
going to be something like JunkBuster tries to be, contacting a central
server for updated information, but rather a program that can be put to
use in internal networks that are pretty secure by itself, and where
people generally don't have enough privileges to position sniffers on
the network.

And as long fetching mail involves using POP3 (not SPOP), why hide data?
It's visible anyway!

Yours,

	Heiko Wundram
	Netzwart Wohnheim-D
	Zimmer 2206 - Universität 18 - Saarbrücken