-----BEGIN PGP SIGNED MESSAGE----- - -----BEGIN PGP SIGNED MESSAGE----- In article <9502020017.AA00895@toad.com>, <kevin@elvis.wicat.com> wrote:

...

1. Broadcasting every couple of minutes isn't necessary and is undesirable

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;

I had the USENET model of propogation in mind when I wrote this. Delivery is considerably better assured with such a store-and-forward over

and second, that remailers never go down for unexpected reasons.

True, if you append "for extended periods of time." The key detail is the boundary condition: IE, how long does it take a "downed" remailer to come off the web. Since each site has the best idea of their own stability, they are in the best position to set the time-out period. A very flaky site might set a time-out to 6 hours. I'd suggest that a site flakier than that shouldn't be running a remailer.

...

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

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);

No, not at all. The attempted connections to your sendmail with fail and the mail will attempt redilvery for some period of time (usually 3 days) at a certain interval (usually 30min. - 1 hour).

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.

Sure. It's important to note that you've got two seperable problems to address here: 1) a recurring limited window of up-time, and 2) handling permanent down-times. My suggestion only covers the first. The USENET model I'm pushing is designed to cover the second.

[PGP web-of-trust] strikes me as critical;... 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.

Absolutely, that's what I was trying to express. Best regards, - - -- Todd Masco | "Let me get this straight. You're making a crypto toolkit, cactus@hks.net | and you're worried about it being _obscure_?" - Eric Hughes Cactus' Homepage - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLy/1gRNhgovrPB7dAQGZCQQA47ADvvuXRvlq5Qw3MSZaUJqqk2KJbUKk nV1mnTVIbvBbCt5PczoSFKkO/O6wMfS/4zzkoTqpvpIvwYvZ6ds75yBwhIyxvTvx gygKFi5ZwysYGz/49vs0BdJSHMqUA+/HVHE2zfcYP+yvbnbTdryQJXLrOdlGhH3a R0LvGJVgCSw= =k+vP - -----END PGP SIGNATURE----- - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLzAuayoZzwIn1bdtAQFa4gF8Cl9yuHttaTqmcy9Be+9EWa4qp3zHCP5n pgWiNvOt7reobq42ZluxFgTlWrFG0SKa =oFTV -----END PGP SIGNATURE-----