-----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-----