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 dattier@ripco.com 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 foo@bar.com 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 foo@bar.com, 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
Follow-Ups:
|
|
