1995-02-03 - Re: Remailer Unreliability

Header Data

From: jordyn@alinc.com (Jordyn A Buchanan)
To: cypherpunks@toad.com
Message Hash: 97ebe8bdc59f159eab78377b73197cdffcf072be742e401c4a5602d3a6221d6b
Message ID: <ab57699300021004facc@[204.99.128.203]>
Reply To: N/A
UTC Datetime: 1995-02-03 05:11:34 UTC
Raw Date: Thu, 2 Feb 95 21:11:34 PST

Raw message

From: jordyn@alinc.com (Jordyn A Buchanan)
Date: Thu, 2 Feb 95 21:11:34 PST
To: cypherpunks@toad.com
Subject: Re: Remailer Unreliability
Message-ID: <ab57699300021004facc@[204.99.128.203]>
MIME-Version: 1.0
Content-Type: text/plain


>> Date: Thu, 2 Feb 95 18:00 EST
>> From: nobody@myriad.pc.cc.cmu.edu (Anonymous)
>>
>> What if it was possible to specify an alternate remailer?  In the case that
>> a remailer went down, you could specify an alternate.  For example:
>
>  Well, *I* think it is a good idea.  But how does remailer1 know that
>remailer2 is both a remailer and down?

The issue of whether or not the alternate address is a remailer seems to
be largely irrelevant.  It doesn't really hurt anyone to be able to specify
an alternate address, and the feature would even seem to have some practical
value as you could specify alternate addresses for an end-recipient if
you suspect an address might be unreliable.

As long as the alternate address is only invoked if the first mail delivery
fails, the problem of the exponentially-growing message is avoided as well.

Jordyn

-------------------------------------------------------------------------
Jordyn A. Buchanan                      Environmental Studies (B.U.S.)
jordyn@alinc.com                        University of Utah -- '95 (hope)

PGP Public Key: 0xADEEC1 ED 3D 36 5A 98 CE 9D B4  4B 37 0B 9B B5 D6 F3 4B







Thread