My school offers a "group e-mail account" facility to allow groups of
two or more people (e.g., office staff, or a professor and his/her AA)
to share access to a mailbox on a Cyrus IMAP server.
Some aspects of the implementation of this group account facility are
painful. I'd like to ask some questions in order to get an idea of what
sorts of improvements could be proposed (and hopefully implemented by
our campus IT people, or maybe implemented in my department if we can't
get a better campus-wide solution).
The main snag, in my view, has to do with the authentication scheme for
accessing group accounts. Rather than have a separate password for the
group account (which would have to be known by all accessors, would need
to be changed whenever any accessor left, and is essentially dismissed
out of hand as an unacceptable security flaw), each user logs in to the
group account IMAP server using his/her own individual ID (user name)
and password. A separate, web-based utility exists to allow owners of
a group account to manipulate the account's ACL info and control who can
access the account.
The group accounts are set up on the IMAP server under a separate name
hierarchy (e.g., an account named "ourgroupaccount" is filed on the IMAP
server under group.ourgroupaccount). Since users are authenticating to
the server via their own user names (e.g., I would log in as "richw",
not as "ourgroupaccount"), it doesn't appear to be possible to make the
group accounts live in the regular "user" namespace -- the IMAP server
wouldn't understand that I (having authenticated as "richw") want to
see user.ourgroupaccount as the account's inbox (and not user.richw).
And since the group mailbox isn't named "user.XXX" (where "XXX" is the
user's individual account name which was used for authentication), some
mail clients have a really hard time working with group accounts in a
seamless fashion. In Eudora and Thunderbird, for example, the user is
confronted with an "Inbox" on the group account server that really isn't
used for anything at all -- and if a user is set up to access more than
one group account, all the group mailboxes show up as separate entities
gathered under a single account. Problems also exist with checking for
the arrival of new mail in a group account -- again, because the group
account's inbox is not in the normal location. Curiously, one mail
client which does seem to do a half-decent job of presenting group
accounts as separate entities that look the same as the user's individual
Inbox is Outlook (!).
I imagine that if there were some way for a mail client to tell the IMAP
server that the account user name was "ourgroupaccount", but that the
user would be logging in as a different user (e.g., "richw") and with
such-and-so password, it might be possible to put the group mailboxes
in the "user" namespace on the server, and things would be much cleaner.
But I'm not aware of any non-kludgy way to do such a thing.
I suppose one possibility would be to tell people to use the group
account name as the user name -- and then use a "group password"
consisting of their individual ID, a colon or other punctuation mark,
and their own individual account password -- something like this:
User name: ourgroupaccount
Password: richw:myownindividualpassword
and then write a SASL mechanism to deal with this composite user name /
password thingy. But this might very possibly be too complicated and
confusing for some users to deal with.
Has anyone else out there dealt with group accounts of this type? How
do you handle the authentication issue (allowing multiple users to log
in to a single group account, each using his/her own individual user
ID and password)? I'd be very interested in hearing any suggestions.
--
Rich Wales === Palo Alto, CA, USA === richw@richw.org
http://www.richw.org === http://en.wikipedia.org/wiki/User:Richwales
"The difference between theory and practice is that, in theory,
theory and practice are identical -- whereas in practice, they aren't."