1. Broadcasting every couple of minutes isn't necessary and is undesirable due to the real limitations of the Internet. A remailer could broadcast its location with a time-out on the location without a constant stream of availability announcements. In your position for example, you'd broadcast a message at 5 pm with a 16 hour valid time.

True, but this has two basic assumptions that I disagree with: first, that we can guarantee delivery of a broadcast message to all interested sites; and second, that remailers never go down for unexpected reasons. When the day comes that both networks and software are perfect, this method will be reliable. Of course, you are also right that broadcasting is undesirable; that is why I am pondering a way to minimize the impact.

2. This is actually unnecessary for your situation: All you need to do is advertise your location as a "real" remailer and then have a cron job that kill sendmail at 5pm on your remailer machine (assuming you have a spare machine that doesn't need to run sendmail). The mail network is flexible enough that things will Just Work. Mail won't go through instantly during the day, of course, but that just helps to muddy up the mix.

But, if my understanding of remailer operation is correct, this has two potential problems: first, I will still receive mail during the day, causing a bandwidth concern (I know, it's probably not a problem right now, particularly since users will probably choose to avoid a remailer with a possible 16 hour delay); and second, the machine delivering mail to me simply has to trust that a remailer will in fact pop up on this machine to process the stored mail. There is no way of determining that mail is not simply going into a black hole. And even if I try to be nice when the mailer goes down permanently and tell everyone not to route mail through it any more, that news still has to travel via word of mouth to all users of the web.

3. Broadcasting over live IP isn't all that great a model. Ideally, you'll use a mechanism that doesn't require instant communication among hosts. I favor USENET for this: messages have a naturally long life- time and the network is self-adjusting. If a direct route is temporarily unavailable, an indirect one will often manifest itself. I also favor using USENET store-and-forward for the messages themselves for the same reasons: traffic analysis is impossible inside the web and direct routes are not necessary.

I am not happy with my proposed advertising methods, and was quietly hoping for some guidance from internet gurus in this point (the irc suggestion in particular is a pretty shaky straw man). However, see my earlier message (on some other thread) about Usenet propagation times. Propagation times in days do not seem to be rare (post to misc.test and see when the last reply comes back). While this is better than word-of-mouth propagation, it does not offer the very low latency I was looking for.

4. Using a PGP-style web-of-trust is important. In the ideal situation, one human in an extended web can certify individual remailers and all other remailers close enough on the same web of trust would pick up the message immediately.

It strikes me as critical; right now, a user has to choose to trust a set of remailers, given no assistance other than a list of "reliable" ones. Given an extended web of trust between remailers, the user can choose to trust one remailer (I have no idea how to make this process more palatable) and immediately gain the security of a large web of remailers (maybe you are right about that instant gratification thing...) Kevin