Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 27 Aug 1998 22:02:42 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        lyndon@esys.ca (Lyndon Nerenberg)
Cc:        tlambert@primenet.com, hackers@FreeBSD.ORG
Subject:   Re: Imap4
Message-ID:  <199808272202.PAA27570@usr02.primenet.com>
In-Reply-To: <SIMEON.9808261053.E18812@warhol.esys.ca> from "Lyndon Nerenberg" at Aug 26, 98 10:51:53 am

next in thread | previous in thread | raw e-mail | index | archive | help
> > 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808272202.PAA27570>