David Tamkin replied to my earlier message off-list but gave me permission to move it back to the list. I'll do so for the purpose of including my response below.
I'll be the first to admit that my concept is incomplete and may present serious technical challenges, and that's before you get into how to change the Internet to support a transfer-of-payments system. When the topic came up several years ago Norbert Bollow offered to set up a separate discussion list for it, since it is something that could get off-topic for list-managers quite quickly. That list never really got off the ground, unfortunately. Maybe he would be willing to try again. I think it would be far better for the net community to come up with a solution than to have one dictated to us by governments. The inadequacy of S.630 is sufficient proof. -- Mike Nolan > From [EMAIL PROTECTED] Sun May 19 17:11:05 2002 > | For _solicited_ > | e-mail it would be the recipient who was charged, with the sender then > | sharing in the revenue pool. > > There is something here I don't understand. > > What proves whether the message was solicited or not? If the recipient says, > "I neither asked for this nor want it, so I won't pay for it," and the sender > says, "the recipient asked for this, so I won't pay," aren't the transmitting > sites left holding the bag? And how can the recipient decide whether to > accept a piece of mail sent collect without seeing it and being able to > capture a copy locally? Often the headers are information enough for the > recipient to make the decision, but not always. So you must have some other > idea in mind for proving [or disproving] solicitation, and I'm wondering what > it is. > > Perhaps it is obvious to the others on list-managers and that the explanation > would bore them, so I've written off-list. If you wish to move the discussion > back onto list-managers, you are welcome to quote this message there. > > David Tamkin As I said, I'm not an expert on public/private key encryption and validation systems, but I do know that these are used to authenticate messages in other contexts. What follows may be a gross simplification or misunderstanding of how SMTP and key validation works, but I think it is close enough for conceptual purposes. Assume that a messsage is tagged as 'solicited'. This means that the originator has been given an authentication key by the recipient. This key must be unique to every combination of message originator and recipient. (The list is the originator for List Managers.) During the SMTP negotiations, the key would be used in a challenge/response scenario initiated by the receiving system. (Prove to me that you are the same [EMAIL PROTECTED] that I agreed to accept messages from or I won't accept your message as 'solicited'.) This presupposes that SMTP has already established who the sender is and who the recipient is and that both addresses are valid. I'm not sure how to accomplish this, it may require an independent return path from the receiving SMTP system to the sending address to verify that the address isn't being forged. (Hey, SMTP for [EMAIL PROTECTED], are you trying to send me e-mail? If so, send me back this approval code.) Is an independent return path unworkable? I think FTP uses something similar though far simpler. I'm not sure how mail relays and gateways would enter into this, though I think that may be related to some earlier discussions here. -- Mike Nolan
