From: wcs@anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
Date: Thu, 18 Aug 94 17:38:19 PDT
To: rfb@lehman.com
Subject: Re: Remailer ideas
Message-ID: <9408190036.AA24242@anchor.ho.att.com>
MIME-Version: 1.0
Content-Type: text/plain




>     From: Hal <hfinney@shell.portal.com>
>     . . . I still think that there would be real utility in the
>     ability to specify that a particular piece ofmail should be
>     re-transmitted if it does not get delivered to the destination
>     machine within a certain period of time.
>     That's one reason I like the "enabledmail" approach.  All we have to do
>     is persuade everyone . . . .

You *can't* get everybody to agree on anything, or limit themselves
to anything.  It'll be a long time before everybody starts
supporting all the X.400 semantics, especially since people keep
introducing useful competitors like MIME or painful ones like
MicroSoft Mail - I'd be happy to get people to all agree to support
RFC822 and SMTP...  In the context of this discussion,
automatic replies are probably unacceptable for many remailer-users,
and don't work very well for replying to anonymous senders.
Confirmation really does have to come from the user,
and can only work if the user is able to build a return path.

A useful surrogate for end-to-end replies are link-based bouncegrams.
I'm not sure how much security you lose if you get remailers to 
support even one-hop NAKs, since the delays inherent in reordering
mean you need to keep a return path step around in the remailer
at least until you can do address validation; perhaps you could
at least bounce on invalid syntax, but even that means decrypting
incoming messages a while before sending and keeping them around
in cleartext, which is Bad (or doubling the decryption work.)

		Bill