Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Feb 2003 12:58:40 +0100
From:      Brad Knowles <brad.knowles@skynet.be>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        Brad Knowles <brad.knowles@skynet.be>, Rahul Siddharthan <rsidd@online.fr>, freebsd-chat@freebsd.org
Subject:   Re: Email push and pull (was Re: matthew dillon)
Message-ID:  <a05200f44ba6fe5dff1a0@[10.0.1.2]>
In-Reply-To: <3E49C434.D8D497EE@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>

next in thread | previous in thread | raw e-mail | index | archive | help
At 7:49 PM -0800 2003/02/11, Terry Lambert wrote:

>  Why did you cut out my arguments against actually doing it, in your
>  reply?

	I wasn't disagreeing with them, it's just that this is an issue 
that I think is also important, and you hadn't addressed it.

>>          Why not just give everyone in the world an IMAP account on your
>>  mail server and make everyone use shared folders?
>
>  Security.  Privacy.  Concurrent access.  Storage.  Backup.
>
>  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.

>                              But you have to be willing to change
>  IMAP4 semantics, slightly.

	In what way does IMAP4 need to be changed?

>>          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.

>>          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.

	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.

-- 
Brad Knowles, <brad.knowles@skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)


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?a05200f44ba6fe5dff1a0>