[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Frothing remailers - an immodest proposal
-----BEGIN PGP SIGNED MESSAGE-----
- -----BEGIN PGP SIGNED MESSAGE-----
In article <[email protected]>, <[email protected]> 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
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
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
Absolutely, that's what I was trying to express.
- - --
Todd Masco | "Let me get this straight. You're making a crypto toolkit,
[email protected] | and you're worried about it being _obscure_?" - Eric Hughes
<a href="http://www.hks.net/~cactus/cactus.html">Cactus' Homepage</a>
- -----BEGIN PGP SIGNATURE-----
- -----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-----
Comment: Gratis auto-signing service
-----END PGP SIGNATURE-----