Re: Remailer ideas
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
participants (1)
-
wcs@anchor.ho.att.com