Great Circle Associates List-Managers
(May 2002)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: charge per email (fwd)
From: nolan @ celery . tssi . com
Date: Sun, 19 May 2002 13:23:46 -0500 (CDT)
To: list-managers @ GreatCircle . com (List Managers)

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:
Indexed By Date Previous: Re: how to handle... large ISPs blocking mailing lists/charge per email (fwd)
From: nolan @ celery . tssi . com
Next: Re: e-postage again
From: "John R Levine" <johnl @ iecc . com>
Indexed By Thread Previous: Re: how to handle... large ISPs blocking mailing lists/charge per email (fwd)
From: nolan @ celery . tssi . com
Next: Re: charge per email (fwd)
From: Paul Hoffman / IMC <phoffman @ imc . org>

Google
 
Search Internet Search www.greatcircle.com