Date: Wed, 12 Feb 2003 09:26:20 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Brad Knowles <brad.knowles@skynet.be> Cc: Rahul Siddharthan <rsidd@online.fr>, freebsd-chat@freebsd.org Subject: Re: Email push and pull (was Re: matthew dillon) Message-ID: <3E4A83BC.8A15E7C3@mindspring.com> References: <20030211032932.GA1253@papagena.rockefeller.edu> <a05200f2bba6e8fc03a0f@[10.0.1.2]> <3E498175.295FC389@mindspring.com> <a05200f38ba6f51f20eff@[10.0.1.2]> <3E49C434.D8D497EE@mindspring.com> <a05200f44ba6fe5dff1a0@[10.0.1.2]>
next in thread | previous in thread | raw e-mail | index | archive | help
Brad Knowles wrote: > > You can actually get around all but "storage" and "backup", and > > those can be brute-forced. > > There's no way to get around the storage issue. This stuff has > to be stored somewhere, and if we're not allowed to store it on the > machine owned by the recipient, then we have to store it on the > machine owned by the sender. Thus, we create huge SPOFs throughout > the system. "all but storage and backup"... > > But you have to be willing to change > > IMAP4 semantics, slightly. > > In what way does IMAP4 need to be changed? Add domain support. There is no support in it in the login process, which asks only username and password. The trick of specifying "username@domain" will not work for a number of mail clients, such as some versions Netscape, strip trailing "@*" before sending it to the server, on the assumption that they know better than you do. > >> No, not really. Besides, we all know how poorly LAN e-mail > >> packages scale. Been there, done that. > > > > Just because the code you are familiar with was written by idiots, > > doesn't tar all code with the same brush. 8-). > > I've seen quite a few LAN e-mail systems. Not a one of them > scaled. They were all written under many false assumptions. > > I'm not saying all code is bad, but I have seen enough LAN e-mail > systems to say that, in general, they don't scale. Well, the Open Source answer would be "Send Patches, and if they don't step on anyone's toes, we'll think about commiting them". > >> Again, not really. Nice idea, but the OP said that the messages > >> themselves were never sent, only notices -- the message bodies would > >> then be retrieved via a pull mechanism. > > > > From a flood-filled, replicated store. I didn't say that the nodes > > containing the message replicas had to be local to the recipient. The > > usenet model is a good flood-fill replicated transport model. > > No, a flood-fill replicated store can't be used for the actual > messages. The OP stipulated that they were stored only on the system > belonging to the sender. You could flood-fill the notices all you > want, but if the original system on which this stuff is stored goes > tango-uniform, then you are well and truly screwed. Well, the "OP" in this case is actually a reference to a DJB document, and what we're interested in here is solving the problem. We don't have to accept both the data store and the "don't send messages" parts of the document, all or nothing. > Of course, if you flood-filled the notices, you'd have to find > some way to force everyone to actually subscribe to the appropriate > newsgroups or something, so that they'd actually see the notices. No, you'd direct-send notices. You'd flood-fill the messages the notices referred to, to address the scalability and availability problems, and to partially address the "revisionist history" and "delete before receipt" problems. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E4A83BC.8A15E7C3>