[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Remailer ideas
> From: Hal <[email protected]>
> . . . 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