First of all, thanks for the rapid response!

I grant that my perceptions of scalability issues might be faulty here.
And I've also taken a brief look at Cyrus without getting a clear sense
of whether that is best for me.  So I think maybe I ought to make a
clearer statement of my requirements, and then take your direction about
where I should go from here..

What I would like to build is a simple, but scalable, voicemail system
that uses IMAP for the message store and meets the following
requirements:
  
- Each voicemail subscriber would have an account on the IMAP system
- All access to the message storage would be through IMAP only
- Messages would be deposited through SMTP only
- The server itself will be dedicated to this purpose; i.e no other
general purpose computing or user accounts would be on it
- Voicemail messages will be stored as attachments to message
(base64-encoded wave files) in INBOX
- Greetings would be stored as attachments to messages in another
mailbox (which means I need a way of getting a message into a mailbox
other than INBOX through some automated process)
- The server would be provisioned with lots of disk space and lots of
users
- Since it's voicemail, the number of messages per mailbox is far less
than email
- Since it's voicemail, the average daily number of accesses per user is
far less than email (hence one server would support many more users, I
think, as long as sufficient storage is available)
- Since it's voicemail, response time to IMAP requests is perhaps a bit
more important than email
- Incoming IMAP connections will all be from a separate set of servers
that I control, which provide the interactive voice response menus and
play/record with customers.

So it's kind of a locked-down environment, and a bit different set of
requirements than pure email messaging.

I have previously built such an application on a commercial IMAP
product, and while it worked fine, the cost and licensing terms were
both prohibitive.

Do you think I am on the right track to be considering UW IMAP for this?
Or should I take a second look at Cyrus, or even some other product?

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Mark Crispin
Sent: Tuesday, October 03, 2006 4:18 PM
To: Horton, Dave
Cc: [email protected]
Subject: Re: [Imap-uw] Don't want a unix user per account - is there an
alternate security model

For what it's worth, the University of Washington has a six-digit user 
community for its IMAP service, and many of these users thousands if not

tens of thousands of messages in their mailboxes.

I am curious why you feel that it "doesn't seem scalable".  For each
IMAP 
user, what is needed is:
  . a user ID
  . a password
  . a designated directory to store mailboxes (don't forget, there is
more
    than just INBOX)
  . access control precluding unauthorized access to other user's
    mailboxes, and perhaps also sharing access.

All this is precisely what a UNIX account provides; and it does so with 
familiar tools that you already know how to use.  There is no "overhead"

with a UNIX account that you don't already have to face with IMAP.

Without using a UNIX account, you need to have a database of each user 
with user ID, password, the user's directory (perhaps this can be 
calculated), and above all access control rules (particularly if shared 
access is permitted).  The main reason for doing this is NOT to save 
"overhead" over a UNIX account, but rather to do things that UNIX
accounts 
don't do (in particular, provide much more complex access control than 
UNIX allows).

There are excellent servers (notably Cyrus from CMU) which work
precisely 
that way.  If you feel that this is what you want, then consider Cyrus:
        http://cyrusimap.web.cmu.edu/

UW imapd is not targeted at that type of audience; Cyrus is.  However,
the 
UW and Cyrus folks work closely, so if you are really a Cyrus kind of
guy 
then I'm happy to refer you to them.

Good luck!

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

Reply via email to