From: hfinney@shell.portal.com
Date: Wed, 15 Sep 93 06:09:17 PDT
To: cypherpunks@toad.com
Subject: caching scripts
Message-ID: <9309150646.AA29593@jobe.shell.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

I am very excited to hear about Karl's progress in experimenting with
caching (batching) mail messages.  Karl, if it becomes convenient, I'd
appreciate seeing a copy of your scripts.

I have two thoughts about batching.  The first regards the mechanism
for arranging for activation of the batch scripts at regular intervals.
Karl mentioned at and crontab as two ways of arranging for this.  Some
users may not be allowed use of these functions.  I am not sure I can
use them on the systems which I use.

Another possibility, it occurs to me, would be an "activation" message
sent to each remailer from some system where crontab usage is allowed -
one of the systems which is owned by a remailer operator, for example.
This system would send out an activation message at midnight every night
to each remailer which had requested this function.  The activation
message would have a special header field which could be trapped by the
slocal program and cause it to run the batch script.

The other idea I had was to increase the volume of messages passing
through the remailers.  This way we could batch at more frequent intervals
while still having good "mixing" at each step.  Suppose some remailer
system took on the task of periodically injecting messages into the remailer
web.  Each message would be a large chain, perhaps through a dozen randomly-
chosen remailers, which would end up disappearing by being sent to a
"bit bucket" address like nobody@soda.berkeley.edu.  With the new
scripts appearing for producing random remailer message chains such a
program would be quite easy to write.

The message injection rate would be adjusted to give each remailer in
the system an average load large enough that batching would usually
have (say) ten or more messages to work with.  Perhaps nine of those ten
would be these dummy messages, while one is an actual user message.  But it
would not be easy to tell these apart, at least for user messages which
are in the middle of their chain; each message, dummy and real, is from
another remailer and to another remailer.  There is no hint as to which
are the actual messages.

It is true that user messages can be distinguished from dummy ones when
they are on their first or last stage in the chain; on the first stage,
they are the only messages coming from non-remailer addresses, and on the
last stage they are the only messages going to non-remailer addresses.
One way to fix this would be, instead of having the final destination
of the message be a "bit bucket" address, to instead choose a random
Internet address (say, from one of the "whois"-type databases), and to
send a message whose body starts with "Test message, please ignore".
With the tens or hundreds of thousands of addresses available (and with
the geometric growth of the Internet), it should not be necessary ever
to repeat an address.  So perhaps this slight annoyance to Internet users
would be tolerable.  Only a small fraction of users would ever receive
such a message.

The increase in traffic brought about by this dummy message source would
not be large in terms of the net as a whole.  It would only need to
introduce messages at the rate of (# messages per batch) * (# of remailers) /
(size of chain per message) per (batch interval).  Plausible values might
be:
# messages per batch:      10
# of remailers:            20
size of chain per message: 10
batch interval:             6 hours

This works out to about 3 messages per hour, not too large a load.

Of course, this message injection system would only be maintained as long
as user message traffic remained too low to provide good mixing in a
batch system.  As user message traffic increases, the injection rate would
be decreased to compensate, until finally it might be possible to eliminate
the dummy-message injection completely.

Comments are appreciated, as usual.

Hal Finney
hfinney@shell.portal.com

-----BEGIN PGP SIGNATURE-----
Version: 2.2

iQCVAgUBLJaN5agTA69YIUw3AQECnwP9F+0gMxoL4xoLPyAJS4/owHOmTGW2OE0a
nOLkjop+vT388LyZjbj40cRwm0OWpjNXwvsxsmY+Uhc8EYyTu/H1wKn2N2PR0Ufu
TD/EYxLFuvXQGviGKftMfM/VbwRXUf1SiUnPovZ7jVaBhacp62y4+C6BQtFSZIft
l3T2U1KI+Y4=
=11AS
-----END PGP SIGNATURE-----