The "remailer-in-a-box" solution seems to be on its way to solving the ebbing number of remailers problem. The next step is to think of remailers in a supply and demand context. From a "maximizing your resources" standpoint, it doesn't make sense to have one hundred remailers available (aside from the chaining implications), if the usage/demand needs are met by twenty. It's important to create an infrastructure for a large scale remailer network, but the next step is to actually drive demand (obvious benefits of increasing privacy levels, blunting traffic analysis, creating a large enough population that will vocally protest if attempts to restrict remailers are made, etc.). I see two ways of doing this. The first step is education. Net users, especially the new ones, need to be educated about the use and benefits/limitations of remailers. Web pages are a good start. The information needs to be easy to understand yet compelling. Users need to be shown why remailers are important and be encouraged to at least try using them once ("want some candy little boy/girl"). The second step is access. With the advent of commercial Internet providers, the defacto Net access points are becoming GUI PCs and Macs. It is critical that tools be built for these platforms that make using remailers a transparent and simple task. (I don't want to belittle GUI users, I'm using Windows as I write this, but most would rather click a few buttons and use a list box rather than remember the :: syntax for embedding remailer commands in their e-mail.) This was part of my motivation for writing Private Idaho for Windows Eudora. I see good GUI premailers or integrated e-mail scripts as a critical element of remailer success. Joel McNamara joelm@eskimo.com - finger for PGP key