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
Rick Busdiecker <rfb@lehman.com> writes: 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