Re: Remailer ideas

[Hal <hfinney@shell.portal.com>]

Rick Busdiecker <rfb@lehman.com> writes:

>I think that many of the simple cases are conceptually easy, but even
>slightly complicated ones are non-trivial.  For example, I tend to
>include Return-Receipt-To: lines in my messages, so I get a bunch of
>responses.  Interpreting those responses and deciding what action
>would be appropriate raises some interesting questions, not the least
>of which is ``What does it mean for a message to be successfully
>delivered to the cypherpunks list?''.  Just as an example how easily
>the issue can become confused, I'll throw in, ``How is the meaning of
>successful delivery affected by changes in list membership during
>transmission?''  Considering that some of the addresses to which
>cypherpunks is distributed are also distribution lists, any list
>related problems are multiplied.
I can see that there may be difficult cases, but 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.  As I said,
this would help with the implementation of cryptographic protocols that
worked via email, not to mention the many other applications.



>Practical issues make this whole thing more difficult.  The ``getting
>people to build it into their Mail User Agents'' part in particular.
>The idea of a Return-Receipt-To: field has been around for a while,
>but the semantics have never been pinned down.  Some mailer daemons
>generate replies meaning that the bits were delivered.  Some readers
>(MUAs?) generate replies based on end-user actions.

That's one reason I like the "enabledmail" approach.  All we have to do
is persuade everyone to run a system which allows anyone on the network
to get your computer to run an arbitrary program for them.  Then everything
will be fine.  One nice thing is that enabledmail scripts can
trigger either on delivery to the dest machine, or on being read by the
recipient.  This gives even more flexibility in how you want to define
a "received" message.

Hal