From owner-freebsd-hackers Thu Aug 27 15:04:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA10546 for freebsd-hackers-outgoing; Thu, 27 Aug 1998 15:04:01 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA10488 for ; Thu, 27 Aug 1998 15:03:48 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id PAA23272; Thu, 27 Aug 1998 15:02:53 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp04.primenet.com, id smtpd023229; Thu Aug 27 15:02:49 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id PAA27570; Thu, 27 Aug 1998 15:02:43 -0700 (MST) From: Terry Lambert Message-Id: <199808272202.PAA27570@usr02.primenet.com> Subject: Re: Imap4 To: lyndon@esys.ca (Lyndon Nerenberg) Date: Thu, 27 Aug 1998 22:02:42 +0000 (GMT) Cc: tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: from "Lyndon Nerenberg" at Aug 26, 98 10:51:53 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The wire protocol is similar to LISP: lots of silly parenthesis. > > With lots of lists of things flowing around. What's wrong with parens? If it > works for Lisp ... :-) You cut out the part where I told you what was wrong with it: it's much more complex than it should be to build a parser for the thing. > > Many ISPs dislike IMAP4 because it takes a lot of storage, and only > > gives back increased modem usage and wire traffic in return for > > the extra storage it consumes -- wait a minute, I get why they > > don't like it... ;-). > > You mean your IMAP server doesn't implement quotas? Both the U of W and the Cyrus code support quota. Quotas are not the point; the point is that if you store information on the server, there is less space available on the server for other tasks. This is rather like a spammer asking "So what's wrong with me putting SPAM in your mail queue? I'm not running you out of space...". There are quotas, and then there are expectation values for amount of usage. The expectation values are less than the quota in most cases, but in the IMAP4 case, the protocol strongly encourages you to take up space on the server. > Disk is cheap, and the security of having the mail backed up is a big win. Perhaps you can convince people to pay an extra $5/month for this security... ISP disk costs are amortized across customers. > > One of the most annoying this is that, without a full IMSP implementation, > > of which there is not one of, there is no provision for fanning out > > envelope information into sub-mailboxes (which would make IMAP4 > > useful for virtual domain hosting, where POP3 fails to retain > > envelope information because of a stupid agrument between Eric Allman > > and Eric Raymond about "who is the MTA"), nor is there provision for > > client specification of server side filtering rules (which would make > > it otherwise more useful than POP3). > > I'm not sure how IMSP helps with virtual domains. It allows for client mobility (the standard reason IMAP4 is sited as being useful) and it allows the setting of "post" ACL's, which could prohibit mail from specific sources. In addition, there are drafts for extensions to support client management of server filter lists; this draft was specifically what I was referring to, where you would take the envelope-to information (passed the Cyrus "deliver" command on the command line) and use it to select a subfolder name to implement virtual domain fan-out using envelope information, instead of having to second-guess it and attempt to reconstruct it from header contents. > As for filtering, SIEVE is getting close to > being reality (there are three prototypes running that I'm aware of). References, please... > > Basically, it's an interesting "also ran" that won't displace POP3 > > any time soon until its flaws are noted and corrected. > > I'm going to take great pleasure in quoting that back to you in a couple of > years :-) Please do... > My prediction is that IMAP is going to displace the majority of POP3 > implementations over the next 2-3 years. POP3 just can't handle the mobile > community that represents more and more of the e-mail users out there today. ...So long as you don't mind me quoting this... 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message