OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: pop-before-smtp (was Re: FreeInet and checking mail?)
From: Russ Allbery (rrastanford.edu)
Date: Wed Jun 07 2000 - 21:33:13 CDT

Brad Knowles <blkskynet.be> writes:

> 9000 unique logins? We have over 600,000 mailboxes on one of our
> servers, with over 400,000 active accounts. Maybe I don't understand
> how you're counting unique logins, but this would seem to me to be a
> loss of scalability of about two orders of magnitude.

IMAP connections are heavier-weight than NNTP connections, with the same
issues (or even worse issues) with some clients opening up a large number
of simultaneous connections. Part of the problem is that IMAP mailbox
writes, under a lot of standard usage patterns, are considerably more
frequent than NNTP posts.

> The problem is that you have limited numbers of connections that can
> remain open at any one point in time.

And a lot of clients open up a separate connection for *every mailbox*
that the user has.

>> www.mirapoint.com IMAP appliances, meant to scale horizontally

> I'm familiar with them. They have two installations so far, of which
> their largest is ~80k mailboxes. The hardware is slightly hacked-up
> FreeBSD 2.x, and the software is slightly hacked-up older releases of
> sendmail (some of which is being used in violation of the licensing
> terms, etc...).

> These guys are really slimy. Sorry, not interested.

Hm. I wouldn't go that far, but then I know a lot of people who work for
them from various places. What I will say about them, however, is that
their boxes may work well in the situations for which they were designed
but they have a serious flexibility problem. Dealing with other
authentication methods, other UIs for the clients for administrative
functionality, and so forth is hard to impossible.

We evaluated their boxes very early on and thought they might be
promising, but they didn't work out in practice. We're switching to
Cyrus, which works quite well in our environment, and which is *far*
easier to customize and administer. 

-- 
Russ Allbery (rrastanford.edu)             <http://www.eyrie.org/~eagle/>