Throw away the Internet and start over?
jbone at deepfile.com
Tue Apr 22 02:28:58 PDT 2003
On Tuesday, Apr 22, 2003, at 17:02 US/Central, Justin Mason wrote:
> Yeah, but the problem of spam would not be fixed by such a beast.
> the issue that's driving this idea of replacing SMTP, and unless a new
> protocol can actually solve that issue, it won't have made any
> apart from a lot of upgrade pain.
I think you missed the point. Go re-read Paul's write up: it's a
substantial change from "fire-and-forget" to "notify me that I need to
come get something."
It's a lot harder for you to spam me when all you can do is give me a
notification that you've stored a message on *your* server that I need
to come and get. The onus is on you, for storage, for retrieval
bandwidth, etc. It changes the economics of spam dramatically,
providing negative incentives. Any unsuccessful spammer would simply
get ignored, and any successful spammer would be strangled by their own
Plus, it's a lot easier to filter / avoid bogus structured metadata
content in the notification (i.e., I only accept notifications with the
following fields, containing the following values (white list) etc.)
than it is to try to semantically classify the content itself by which
time I've already received and stored it.
> In SMTP, the sender is not authenticated. In SMTP-over-HTTP, there'll
> still be spam, unless the sender is authed. And who does the authing
> across the entire internet? Verisign? ;)
Yeah, that's a point. But I think you can make stone soup w/o the rack
of lamb. ;-) (It takes a tough man to make a tender chicken, etc. ;-)
To the point, though, you can do presence, FOAF, white listing, etc.
all w/ HTTP. Authentication, authorization, and principal management
are all orthogonal to the push / pull, sync / async, and direct vs.
"routed" nature of the underlying protocol. A non-toy proposal should
of course address some of these concerns as well.
Extra credit: contemplate implications of an end-to-end HTTP-based
mail solution on: mailing lists, mailing list management, mailing list
archival, ***groupware*** (what's a message? what's a group?),
calendar coordination, contact information and contact management, etc.
I will simply not ReST (bah-dump-bump) until every piece of information
I touch can be created, accessed, and searched, sorted, filtered,
edited if appropriate, annotated, referred to, and otherwise fiddled
with via HTTP. ;-) :-)
More information about the FoRK