I was thinking some about remailers and means to create more effective ones. I think the idea of padding messages has been kicked around (has anyone implemented it?), but what about random compression? Some messages are compressed, others are padded, some are left alone, perhaps shooting for a median message size (everything coming from this mailer tries to be 9k, or as close as possible). Of course, this requires a standard so that other remailers downstream can make the message readable. Another thing that occured to me is the thought that if there were an organized web or remailers, remailers could bounce messages between them automatically- a header could identify the number of bounces perhaps, I haven't thought too much about the implications of doing so, but if every message through the web bounced around 30 times with reordering, padding/compression, PGP, etc. then traffic analysis would be pretty damn hard, I would think, even for someone monitoring the entire web of remailers' traffic. This all assumes that: - remailers can agree on a standard for the above needed features - a semireliable web of remailers can be maintained - some method fordealing with denial of service attacks can be found (a coredump sent to the web could play all sorts of hell, as could an 'evil' remailer that sneaks in and changes the how-many-times-through identifier). The third problem could be delat with by deciding on a size limit- if a message is over 65k (or whatever) it is bounced- if you're sending something big, split it. The first one could probably be done- if someone (grin- if I find any time soon, this is a project I'd like to do) wrote a nice package that was easy to install and use with a feature set that could be agreeable to most. The second one is the problem, but could be dealt with by the first by establishing automated communication- when someone installs the package, send a control message another remailer already part of the web which 'registers' it, and then the web consistently tries to maintain itself by checking on the others and dropping ones that go down off the list. Some sort of method would have to be found for ones that drop off then later come online again so that control messages didn't have to be manually initiated every time, but that shouldn't be that hard. What are the problems in the above? Would Perl be a good choice for doing this? I saw some code from a remailer some time ago, but lost my mailbox a while back (which could also mena that this is a dry rehash of an old discussion... apologies if I am rewriting someone elses thoughts). Anyone still have this? Am I talking out my ass? -j -- "Blah Blah Blah" ___________________________________________________________________ Jamie Lawrence <jamiel@sybase.com>