From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <1375223f3c7bef6420b98302686aca19@plan9.bell-labs.com> From: David Presotto To: 9fans@cse.psu.edu Subject: Re: [9fans] pathetic In-Reply-To: <139eb44874bee2237034401996735c24@collyer.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-csdnkcibbfqrvluwjcgtohsgql" Date: Fri, 27 Feb 2004 08:07:56 -0500 Topicbox-Message-UUID: ffe8fc22-eacc-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-csdnkcibbfqrvluwjcgtohsgql Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit So just take it to its logical connclusion and make it a pull protocol. You get a note with a URL and grab it at your leasure. This is exactly what MMS (cell phones that send/rcv pictures) do for reception. The message is kept on a server that other phones can pick it up from. The notification is sent to the phone via a short message. Only if sent as email is it wrapped up as a MIME email containing SMIL instructions, html text, and jpg pictures. We could do the same for email, sending a pick up URL, and some 'secret' for decoding the message or logging on or whatever. If you broadcast (like mailing lists) only the notification goes out. AOL/Yahoo/etc mail relays turn into web repositories. Your mailbox server can still yank some stuff automagicly if you like the identity of the sender. Use TLS on all connections, if the web can do it, so can email. Slowing things down isn't that bad. It changes the nature of spam somewhat, i.e., it would become a short message containing nothing but a URL and a subject. Oops, that's what most of my spam already is but at least it means they can't fire and forget, they have to leave servers up. And we're now reduced to a previously unsolved problem with the same solutions. If we're unwilling to accept any solution that identifies the sender more than trusting the From: we're still stuck with our Bayesian filters etc. If we're willing to put up with some caller id, then we have to live with a public key infrastructure, SPF, or something similar. I personally like public keys, just not the infrastructure. If someone has introduced themselves to me once and left a public key, that's good enough for me. --upas-csdnkcibbfqrvluwjcgtohsgql Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Fri Feb 27 05:53:40 EST 2004 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Fri Feb 27 05:53:38 EST 2004 Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id 0DB9C19E1C; Fri, 27 Feb 2004 05:53:26 -0500 (EST) Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id A5E8519B9A; Fri, 27 Feb 2004 05:53:21 -0500 (EST) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id C464B19DCE; Fri, 27 Feb 2004 05:52:26 -0500 (EST) Received: from collyer.net (mail.collyer.net [63.192.14.226]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 2D6BF19B9A for <9fans@cse.psu.edu>; Fri, 27 Feb 2004 05:52:25 -0500 (EST) Message-ID: <139eb44874bee2237034401996735c24@collyer.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] pathetic From: Geoff Collyer In-Reply-To: <022101c3fd10$4f6eee80$0b00a8c0@SOMA> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Fri, 27 Feb 2004 02:52:15 -0800 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psuvax1.cse.psu.edu X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Level: Just getting most systems to strongly encourage TLS under SMTP would impose a CPU tax on bulk mailers, though I don't know if it would be high enough to really slow them down. Yeah, caller-id for mail: when we find those weasels, oooh, we're gonna moidalize 'em! Not. The NSA has bin Laden's phone number but they still haven't caught him. Our current model of e-mail is a dump truck pulling up to your front door and pouring unfiltered, unsorted mail through your mail slot, in a vast heap all over your floor, scaring your cats. I think it would be improved by moving to a model more like someone knocking at your door and trying to persuade your butler to let him (the stranger) talk to you. If the butler knows the person at the door, he might let him in, or might toss him out and bar the door. If the butler doesn't know the person, he might take the person's calling card, leaving you to decide if you want to establish contact. Over time, the butler comes to know which people you want let through and which you want him to call the police to remove / shoot / disappear. Instead of one trying to drink from a fire-hose (or cement chute!), each message would result in a negotiation (perhaps very brief!), which is a more orderly process, the rate of which can be controlled. --upas-csdnkcibbfqrvluwjcgtohsgql--