From: rarachel@prism.poly.edu (Arsen Ray Arachelian)
Date: Tue, 26 Jul 94 06:51:49 PDT
To: gtoal@an-teallach.com (Graham Toal)
Subject: Re: My anonymous remaile
In-Reply-To: <199407261030.LAA14216@an-teallach.com>
Message-ID: <9407261338.AA19987@prism.poly.edu>
MIME-Version: 1.0
Content-Type: text


Again, the best way to build a secure remailer is to have one that sends a
fixed "remailer-packet" to other mailers for internal communication with other
remailers on the "network"

These packets should all be super-encrypted and of a fixed size.  This size
should be as small as possible.  Say around 200K or so.  Why?  Because this
serves to prevent email spamming by severly delaying a message.   Also if there
is some quota of say, no more than 100 messages a day from a user, it serves
to limit spamming quite a bit.

Basically all incoming mail is spooled on the remailer's hard drive in encrypted
form by the remailer.  When a new message is sent to the remailer, the remailer
will go through all the received messages and look for duplicate messages and
also count the number of messages sent by the user who just submitted another
one.

At the end of the day, at a certain hour agreed upon by the remailer operators,
the remailer will split up its cached messages and split them among several
remailers with a RANDOM number of hops set in the message.  These packets will
then be randomly padded inbetween messages with null messages which would be
eaten by the receiving remailer.  The padding serves to limit traffic analysis
and the automatic hop number helps idiot users from being caught.

The packets will then be compressed and then would be encrypted with the 
respective public key of the target remailer and sent as a fixed sized block
again with rand padding at the end... perhaps via ftp or some other protocol,
but not necessarily via sendmail.  Having them as binary makes them easier to
handle than by sendmail...

When the packet is received by a remailer it would first decrypt it, then
decompress it, then remove null messages, then decrement the number of hops
and if it's zero, it would invoke sendmail to send them.

I strongly suggest that the remailer packet protocol be openly published so that
users can build their own packets to forward to remailers in encrypted form
rather than using sendmail.  I suppose that using sendmail to a remail should
still be allowed, but slowly phased out so as to force users to encrypt their
email.  Client software can be written for Windoze and Macs to use TCP/IP or
even Zmodem a packet into a remailer.

You may think that spamming can still occur by allowing users to send packets
themselves, however if the recepient remailer will limit the size of a packet
it will receive to a very small size (especially if it's coming from an unknown
site,) and refuse to receive more than one packet per day from that site, it
would prevent a lot of spamming and creeping detweilerism.

Perhaps remailers can work out a set of special private keys which they share
between them to speed up mail, or the size of the packet can be increased for
remailer-remailer transfers.

Anyhow, the system has to be balanced so that mail gets there in at most a
day or so, at best only a few hours depending on how often remailers talk to
each other.  If traffic at a remailer should suddenly increase, the remailer
should issue instructions to the other remailers that it'll send larger packets
or send more often.  But only after it receives permissions from the other
remailers should it send.

Perhaps if a remailer is too filled it should bounce a message to the sender
(if it knows his/her address...) or perhaps they can be polled to see if they're
busy, or better yet, the message can be forwarded to another remailer in the
old fashioned way (losing some security I guess)