Although I think there may be numerous details to be worked out, I think
Ron has the germ of a viable idea going.
Some form of public key identifier in a header is the only viable validation
scheme I've come up with when I've thought about it.
However, I'd like to see the whole concept taken much further, well beyond
just mailing list issues. Pardon me while I philosophise online here,
and if anyone thought Ron's proposal had a lot of details to be resolved
this one has even more!
What I think is needed is some kind of central 'transfer of payments'
authority for the entire Internet, analagous to what the long distance
phone carriers have. (This is a very radical proposal, it probably
involves completely restructuring both the packet forwarding and the cost
system for the Internet, but that's something that has already happened
once in the past few years, more or less by default, this time it would
have to happen by conscious design.)
Under my idea, EVERY Internet packet would carry a cost with it, to be
assumed by either the sending or receiving party and debited against the
account. Intermediate carriers could conceivably get a share of this fee,
and that fee might ultimately replace many other connect charges. (And if
that means that carriers begin to fight over the right to carry traffic, as
opposed to the current system where they dont' seem to care much whether
they have MY business or not, much like the long distance phone carriers
fight for my account, then I see this as a potentially VERY Good Thing.)
The trick becomes establishing who is paying for each transaction.
Consider a mailng list. In general it would be paid for by the recipient,
with each recipient supplying an encrypted validation tag back to the
list software, possibly as part of the subscription confirmation process.
There could also be examples of mailing lists where the sender pays for the
transaction, or even ones where the POSTER of each message pays for its
distribution.
One problem deals with bounced/forwarded messages, which for sender/author
paid transactions could represent a problem and could represent a means of
avoiding the accounting for recipient paid messages. I'm not sure how to
resolve that one yet.
Payment for individual e-mail (not list traffic, so not encoded with
a payment validation tag) could be negotiated as part of the SMTP
exchange. If I was running a tech support operation, I'd probably be
willing to pay the inbound mail fee for every e-mail. Otherwise that fee
would have to be paid by the sender, effectively ending the current
situation where a spammer can send millions of messages for essentially
nothing. If each e-mail costs something, even if as little as 1/100th of
a cent, sending a million messages at least costs SOMETHING. And having
some kind of payment tag would give mail filters one more thing to use
in trying to route traffic or filter out UCE, even if the sender is
paying the freight.
I think this would even work for relayed or gatewayed messages, because if
the mail was tagged as 'recipient must pay for' it would be rejected for
non-payment some time before it reached the addressee. There would be
some 'lost revenue' for this, but I think it would be a small percentage
compared to the amount of properly 'paid for' traffic processed. And there
would be a certain amount of administrative traffic to deal with the
negotiation for e-mail, but I don't see that as any worse than the current
spam problem in terms of bandwidth requirements.
Now consider WWW requests. The recpient would pay for the hits requested.
This might generate sufficient revenue to the web page owner that information
providers might even be able to become self supporting without resorting
to annoying advertisements, which seems to me to be the reason that Java
applets were created, or at least their most common use. Would I pay 1
cent to get today's 'DILBERT' comic strip? Sure. Would I pay a small fee
for the baseball box scores? Sure. And if I don't want to pay for graphics,
I make that part of my request, possibly forcing more web designers to THINK
about page content. Even though I've got a 64K connection to the net now,
I still find far too many pages that take forever to load up because some
designer get carried away with graphics, sounds, etc.
Things like Realaudio, telnet and USENET traffic get a lot tricker to
incorporate into this proposal, in part because I'm reaching the limit of
my knowledge about how these work at the packet level.
OK, now everybody tell me how crazy I am!
--
Mike Nolan
