From: hfinney@shell.portal.com (Hal Finney)
Date: Tue, 21 Sep 93 03:46:29 PDT
To: cypherpunks@toad.com
Subject: Re:  REMAIL: policy
Message-ID: <9309210156.AA16050@jobe.shell.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


Remailers:
  hfinney@shell.portal.com
  hal@alumni.caltech.edu

I keep logs only of the date/time at which my remailers get used; no
logging is kept of the message contents.  I do this only to get a
picture of the overall volume of messages passing through my remailer.

The Unix systems on which I run these remailers may also do some
logging; I haven't been able to determine exactly what is done.  I
presume this might include incoming and outgoing addresses as well as
message date/time and possibly size.  (I am familiar only with uucp
mail and don't know where to look on these net-connected Unix systems
for sendmail logs.)

My account on alumni.caltech.edu is free, based on my membership in the
school alumni association (for which I paid some $300 about fifteen years
ago for a life membership).  My account on shell.portal.com costs my about
$20 a month in fixed costs, plus $2/hour connect charges which typically
run another $30 a month or so.  So I am paying these people quite a bit and
I hope therefore that this will give me some bargaining strength if political
problems arise from the remailers.

However, due to the large number of users on these systems, there are many
restrictions on my usage.  I cannot leave daemon processes running, nor can
I use at or cron to schedule periodic jobs.  The nice thing about the
current remailer scripts is that they can be triggered by incoming mail
without having a high profile to system administrators.

Both of these systems appear to be well connected on the net and are almost
always available.  Both support PGP encryption.

I am hoping to add batch capabilities to the remailers soon, based on Karl's
scripts.  I also like Karl's suggestion to add message padding to outgoing
messages.  If this system were used in conjunction with batching then if
all messages in a batch were outgoing-padded (undetectably) to the size of
the largest message in the batch then there would be total hiding of the
incoming-to-outgoing message mapping.

Earlier I had assumed that both incoming and outgoing messages would have to
be standardized in size but now I see that padding of outgoing-only messages
would be sufficient.

Hal Finney
hfinney@shell.portal.com