Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 4 Dec 1998 10:40:17 -0500 (EST)
From:      Robert Watson <robert@cyrus.watson.org>
To:        Andrew McNaughton <andrew@squiz.co.nz>
Cc:        FreeBSD Security <security@FreeBSD.ORG>
Subject:   Re: IMAP (was Re: mail.local)
Message-ID:  <Pine.BSF.3.96.981204103543.19902A-100000@fledge.watson.org>
In-Reply-To: <Pine.BSF.4.05.9812041935300.27408-100000@aniwa.sky>

next in thread | previous in thread | raw e-mail | index | archive | help

I personally like the CMU Cyrus server, but it's not designed to be a drop
in replacement for an existing UNIX-style mail system; instead it assumes
a sealed server machine and manages its own file trees and spool code.  It
performs quite well, and supports spiffy things like shared folders, ACLs
on directories, quotas, integration with newspools so as to push
newsgroups into IMAP-style message folders, direct delivery to a
particular folder if the ACL is set right (see my reply-to above), etc. 
However, because of its design, it may not be appropriate for all users
(not a drop-in replacement, requires some sendmail.cf changes)  It's
kerberos support is nice -- the users don't need accounts on the machine,
you can just tell the server to auto-create folders for users who
authenticate against a kerberos identity.

There are also PAM and radius patches around (or maybe PAM is included by
now) so it can fit well into a lot of the larger authentication
environments available.  It supports KerberosIV-based encryption and
authentication (as well as passwords), and someone wrote an SSL proxy so
that it may be used with the secure IMAP options in IE and Netscape.

On Fri, 4 Dec 1998, Andrew McNaughton wrote:

> On Fri, 4 Dec 1998, Gary Palmer wrote:
> 
> > Robert Watson wrote in message ID
> > <Pine.BSF.3.96.981203123334.12137A-100000@fledge.watson.org>:
> > > On Thu, 3 Dec 1998, Bill Woodford wrote:
> > > say, pine.  My feeling is more and more that we should be using protocols
> > > such as IMAP for mail access rather than try to fit everything into the
> > 
> > Please don't use IMAP. It is a bloated ``designed by committee'' protocol and 
> > looks like a nightmare to impliment in an efficient (scalable) fashion. Makes 
> > me want to write my own protocol :(
> 
> When I read the IMAP rfc some time back, It took me about 15 minutes
> to realise that there'd be lots of machines out there with open guest
> accounts for things like ftp:ftp and guest:guest and that logging in as
> one of these would give (unpriviledged) read access to any file in the
> system.  These users would normally not be expected to have access to the 
> whole file tree, and in many cases the systems running mail servers are
> configured without the expectation of untrusted users rummaging through
> the file system.
> 
> I've been told that some IMAP servers have good restrictions on what file
> areas can be accessed by what users, but I don't know which ones.  I
> contacted the people that put out the imap-uw software and the guy was
> pretty prickly about my suggesting it was a problem.  He was of the
> opinion that world read perms on files mean that it's OK for the world to
> have read access.
> 
> So, does anyone know an IMAP server which can be set up to limit which
> areas of the file system are accessible, and preferably that can run of a
> passwd file other than the system one?
> 
> Andrew McNaughton
> 
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-security" in the body of the message
> 


  Robert N Watson 

robert@fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: 03 01 DD 8E 15 67 48 73  25 6D 10 FC EC 68 C1 1C

Carnegie Mellon University            http://www.cmu.edu/
TIS Labs at Network Associates, Inc.  http://www.tis.com/
SafePort Network Services             http://www.safeport.com/


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.981204103543.19902A-100000>