Date: Thu, 3 Dec 1998 11:44:46 -0700 From: Lyndon Nerenberg <lyndon@execmail.com> To: robert+freebsd@cyrus.watson.org Cc: robert@cyrus.watson.org, woodford@cc181716-a.hwrd1.md.home.com, security@FreeBSD.ORG Subject: Re: mail.local Message-ID: <199812031844.LAA14212@rembrandt.esys.ca> In-Reply-To: <Pine.BSF.3.96.981203123334.12137A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3 Dec, Robert Watson wrote: > It might be interesting to rewrite an imap daemon to use > UNIX daemon sockets and ephemeral credential information to authenticate > the user, and similarly have a local SMTP-style domain socket also using > ephemeral data for authentication. I'm not sure that's necessary (or wanted). If the mail clients talk to the IMAP server by doing a fork/exec of imapd, and uses pipes to communicate with it, you can always use pre-authentication based on the real uid that imapd was execed as. The U of Washington server already supports this. Not that I'm a big fan of pre-authentication. You still have to support communication with remote servers no matter what, so you have to have the code to handle AUTHENTICATE. If you want cached credentials, use Kerberos. (This is how we run our email in-house.) And you're now saying "but Kerberos is a pain to administer." As it's deployed, I agree. That argument vanishes if someone writes a user-friendly administration front-end to Kerberos to hand-hold a site through the intial setup of the Kerberos environment. Make that part easy, and lots of people will start using it. (And the recent PAM work will make the use of Kerberos much more attractive.) The other part of the equation is the rewrite of the existing mail client (/usr/bin/Mail) to speak IMAP. I don't see that being a really big problem. (Usenet already proved this in the filesystem newsstore to NNTP migration.) A couple of times now I've actually started on adding IMAP to /usr/bin/Mail, however because I develop commercial IMAP software for a living, I wouldn't be able to release the source freely (the "tainted code" problem). This shouldn't prevent someone with a good understanding of how the c-client library works from doing the work, though. -- Finger lyndon@execmail.com for PGP key. 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?199812031844.LAA14212>