Re: Qwerty Remailer Delays

[Rob P. Martin <rpmartin@acs.ucalgary.ca>]

> 
> It's not very clear how long the delays should be; depends on traffic
> to/from your remailer and to some extent to/from the other sites
> your remailer cooperates with and the machine it runs on.
> 
> If the delay is near-zero, relative to the rest of your traffic,
> traffic-analysts can see mail going to your remailer,
> followed quickly by similar-sized mail going to another location,
> and guess that the two are related, especially if they're
> reading the mail itself.  (For instance, if netcom is a bunch of

I have an idea I don't think has been proposed before.  There has
been a lot of discussion of having "background noise" by having
remailers mail random messages to various bit-buckets and other
remailers on a constant basis.  But why not do it this way.  If a
remailer recieves a message of size N, it holds that message for
a short (< 15min) period of time, and then it sends out X (5 <
rnd X <15) messages of size N, some going to remailers as noise
messages, some going to bit buckets as dummy recipients, and of
course one heading on it's origional route.  One problem with
this is that messages would multiply, ie. 'A' sends to remailer
'B' whichs sends 10 messages out, 5 to other remailers who in
turn send out 10 messages a piece, 5 of which goes to other
remailers who again multiply this.  And you end up with one of
those annoying commercials, where, he tells 5 friends, and they
tell 5 friends until the network shuts down.  So Remailers must
establish some code (which would be send pgp encrypted) that
would give a message a max possible life span of say 5-10
generations. (even that may be too much) 

	Well it is just my $.02 (and Canadian cents at that!)

	Rob

"Remeber, the day after tomorrow is the second day of the rest of
your life." 
     Unknown.