The single most basic problem with mail development that we have is that we don't have enough mail volume through the remailers we have in order to be able to experiment with better systems. In particular, we need to examine other reordering algorithms for the case where volume is low and delivery latencies would be too high with the simple gather-and-permute algorithm.
Well, I hate to point out the obvious but can we organise with the list maintainer to have our mail routed through random machines until it gets to us? I'd only recommend this for the more email aware members as it might prove confusing. Also, to save my own sanity and others certain header munglings might be desirable to ensure that the mail is still filterable. I'd suggest either an addition to the remailer scripts to allow a predefined header line through, or the Subject: line of each message is prefixed with CRYPTO: so the end users can still filter the messages as they now do. Currently I use 'procmail' to filter out various things and it works on the contents of the mail header as so: --------.procmailrc-------------------------- IFS="" PATH=/home/coombs/mark/bin:/usr/local/bin:/usr/bin:/bin MAILDIR=$HOME/mail DEFAULT=/usr/mail/$USER # Filtering for cypherpunks :2 # Two 'if' clauses (^To:.*cypherpunks@toad.com.*|^Cc: .*cypherpunks@toad.com.*) (^Subject: .*(UNSUBSCRIBE|nsubscribe).*) /dev/null # If a match send mail here. --------.procmailrc-------------------------- If we were to route all the mail through remailers I would lose the functionality of filtering as I wouldnt know where the email was coming from, nor would I be able to know it was cypherpunks mail until I read the message body. thats why a Subject: line change or a modification to the remailer scripts (if needed) should be made. Assuming the above was made, all the maintainer would have to do is change my mark@coombs.anu.edu.au line in the alias file to a: |/bin/random-remail -dest mark@coombs.anu.edu.au or |/bin/random-pgp-remail -dest mark@coombs.anu.edu.au -key mark@coombs.anu.edu.au where 'random-remail' is a short program that scans a list of remailers and randomly selects some, puts the addresses and remail triggers into a file, appends the message and changes the "Subject: blah" line to "Subject: CRYPTO: blah". 'random-pgp-remail' does the same and encrypts the whole message before sending, possibly encrypting again a few times with remailer keys. This approach would (dramatically :) increase the remailer traffic to levels where mail re-ordering is possible. Padding would be the next step, add the lines on the end to bring the message to 512 bytes, 1024 bytes, 2048 bytes or greater. Maybe pad all messages to the nearest 1024 bytes? (see below for a method :) The only problem I can see after the programs are debugged etc is the extra overhead on toad.com, wther it's a non encrypted mail out or not. But if that is acceptable to the maintainer in the intrests of giving remailer operators some fodder then we can implement it I dont see any of the random-[pgp-]remailer programs being longer than 30 or 40 (perl script) lines. I'd write them myself if I could get some mail aliases installed on this host. Admittedly they aren't essential but I'd like them for testing purposes. Mark mark@coombs.anu.edu.au PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PADDING PA <---- end of padding to make this 2048 bytes long