Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
--On Saturday, June 22, 2002 02:36:44 PM +0200 Neil Blakey-Milner [EMAIL PROTECTED] wrote: There is always the option to use SSL, which is my preference, but unfortunately neither SSL nor SASL have widespread IMAP client support yet. Most IMAP clients I know of support SSL. Outlook, Outlook Express, Eudora, Netscape, Evolution, mutt, pine, ... Mulberry, ... Which IMAP clients don't? I believe that Eudora's SSL support is broken - it will not work with standards-compliant IMAP+SSL servers. -Pat msg35289/pgp0.pgp Description: PGP signature
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
On Sat, Jun 22, 2002 at 02:36:44PM +0200, Neil Blakey-Milner wrote: On Sat 2002-06-22 (00:06), Chris Dillon wrote: There is always the option to use SSL, which is my preference, but unfortunately neither SSL nor SASL have widespread IMAP client support yet. Most IMAP clients I know of support SSL. Outlook, Outlook Express, Eudora, Netscape, Evolution, mutt, pine, ... Which IMAP clients don't? MacOS X's Mail.app prior to about 10.1.2 or .3 - about 6 months back. -- You can't do maths without e -- David Walters To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
Chris Dillon wrote: While I appreciate the positive support of Cyrus, I guess I need to point out that this approach only works if you are willing to send passwords over the wire in plaintext. Yes, but this is the case with any IMAP server and doesn't really have anything to do with Cyrus in particular. Unlike other IMAP servers, however, Cyrus supports SASL which offers plenty of non-plain-text authentication options, unfortunately none of which work with a local FreeBSD password database that I know of. There is always the option to use SSL, which is my preference, but unfortunately neither SSL nor SASL have widespread IMAP client support yet. SASL requires a shared secret, not a crypt(3) hash of a shared secret. That's why the passwords have to be stored plaintext on the mail server, and why, if you use the UNIX password database as the account database for Cyrus, you must pass the passwords over the wire in plaintext. Personally, I think SASL should have specified that you crypt(3) the passwords, and then use the resulting hash as the password value for the shared secret on both ends. At least that way, you would not have to pass cleartext to use the UNIX account database. This is a client problem. Or you could assign paswords to the client, so that the user sees the hashed value as their mail password, and the unhashed value as their shell account password. But in actuality, the issue is still a client issue (because clients don't hash shared secrets before using them in SASL exchanges). Pretty obvious, really. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
On Sat 2002-06-22 (00:06), Chris Dillon wrote: Yes, but this is the case with any IMAP server and doesn't really have anything to do with Cyrus in particular. Unlike other IMAP servers, however, Cyrus supports SASL which offers plenty of non-plain-text authentication options, unfortunately none of which work with a local FreeBSD password database that I know of. Courier-IMAP supports SASL (PLAIN, LOGIN, CRAM-MD5, CRAM-SHA1). There is always the option to use SSL, which is my preference, but unfortunately neither SSL nor SASL have widespread IMAP client support yet. Most IMAP clients I know of support SSL. Outlook, Outlook Express, Eudora, Netscape, Evolution, mutt, pine, ... Which IMAP clients don't? Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
Terry == Terry Lambert [EMAIL PROTECTED] writes: Terry Personally, I think SASL should have specified that you Terry crypt(3) the passwords, and then use the resulting hash as Terry the password value for the shared secret on both ends. At Terry least that way, you would not have to pass cleartext to use Terry the UNIX account database. The problem with this is that if you serve up your password database via NIS an attacker can grab the crypt()ed password and use it to perform a forged authentication. Note that in the next revision of the IMAP4 spec STARTTLS will be mandatory to implement. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
On Sat, 22 Jun 2002, Neil Blakey-Milner wrote: On Sat 2002-06-22 (00:06), Chris Dillon wrote: Yes, but this is the case with any IMAP server and doesn't really have anything to do with Cyrus in particular. Unlike other IMAP servers, however, Cyrus supports SASL which offers plenty of non-plain-text authentication options, unfortunately none of which work with a local FreeBSD password database that I know of. Courier-IMAP supports SASL (PLAIN, LOGIN, CRAM-MD5, CRAM-SHA1). I should have said unlike some other IMAP servers. Thanks to the simple BSD-like license on the Cyrus SASL implementation, it has found its way into a lot of places. There is always the option to use SSL, which is my preference, but unfortunately neither SSL nor SASL have widespread IMAP client support yet. Most IMAP clients I know of support SSL. Outlook, Outlook Express, Eudora, Netscape, Evolution, mutt, pine, ... I know Netscape didn't have that ability for a long time, and neither did Outlook or OE. Mutt and Pine have had it since around 1999, though. Which IMAP clients don't? If all of the above now support SSL for IMAP connections, then I can't think of any. -- Chris Dillon - cdillon(at)wolves.k12.mo.us - cdillon(at)inter-linc.net FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64, PowerPC, UltraSPARC, and ARM architectures under development - http://www.freebsd.org No trees were harmed in the composition of this message, although some electrons were mildly inconvenienced. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
Lyndon Nerenberg wrote: Terry Personally, I think SASL should have specified that you Terry crypt(3) the passwords, and then use the resulting hash as Terry the password value for the shared secret on both ends. At Terry least that way, you would not have to pass cleartext to use Terry the UNIX account database. The problem with this is that if you serve up your password database via NIS an attacker can grab the crypt()ed password and use it to perform a forged authentication. I understand this. Which is why you don't use NIS, or at least do not make it externally accessible. The exchange would have to include the salt, anyway, or the client couldn't crypt the value to the correct hash. The point is really to allow all the SASL methods to be used by a client, when all the server has is a UNIX password database. Even you've got to admit that storing crypted passwords on the server is better than permitting unprivilged applications access to the plaintext passwords. 8-). Note that in the next revision of the IMAP4 spec STARTTLS will be mandatory to implement. Yeah, this is incredibly bogus. The proper way of handling this is SSL. It's very easy to man-in-the-middle a session that starts out unencrypted when a STARTTLS goes by for SMTP; it is just as easy for anything else that uses that rather bogus method. 8-(. -- TErry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
On Thu, 20 Jun 2002, Terry Lambert wrote: Lamont Granquist wrote: Cyrus imapd is a real pain in the ass to administer local user accounts with though. You mean that it doesn't integrate well with the UNIX credentials system. THe issue here is that Cyrus needs to be able to hook create/delete actions on accounts, and UNIX fails to provide a means of doing this. I look at this as a UNIX deficiency. You can actually get around it by using pw and utilizing the script hooks it has. Well, that's trying to place blame on how it should get fixed. From my perspective I don't care, it is just more difficult to use. The easiest real fix for this would be to write a PAM module to cause the UNIX users to authenticate against the Cyrus database. Creating mailboxes is also a PITA, I like procmail to be able to do this and not have a 2nd configuration step... The cyradm program is extremely deficient. Not a big issue, I think. Writing scripts to encapsulate it and be less deficient is really very trivial. Yeah, these days I don't have that much time to script... If I did have more scripting time, I'd be fixing more shit at work to help me sleep through the night when I'm on call... Its great if you want to offer people imap e-mail without offering them shell access. For local access, though, there's a higher administrative overhead. I'm back to using the UW imapd even though I know it is a poorer codebase... I recommend you do not publicize the IP addresses of the servers, if they are net accessible outside your organization. 8-). Nope. Well protected by firewall in one case, and I'll be updating my ipf rules when I convert scriptkiddie... I never use remote IMAP anyways... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
Lamont Granquist wrote: Cyrus imapd is a real pain in the ass to administer local user accounts with though. You mean that it doesn't integrate well with the UNIX credentials system. THe issue here is that Cyrus needs to be able to hook create/delete actions on accounts, and UNIX fails to provide a means of doing this. I look at this as a UNIX deficiency. You can actually get around it by using pw and utilizing the script hooks it has. Well, that's trying to place blame on how it should get fixed. From my perspective I don't care, it is just more difficult to use. It has functionality that can not be implemented without adding to how UNIX does things. Basically, it needs to be able to hook the account constructor/destructor. I think that it you are running shell acounts on your mail server, you are in trouble anyway. The easiest real fix for this would be to write a PAM module to cause the UNIX users to authenticate against the Cyrus database. Creating mailboxes is also a PITA, I like procmail to be able to do this and not have a 2nd configuration step... You mean new mailboxes. THat's an issue of a client program that you could run from procmail on a user's behalf, based on a credential correspondance. You have to establish that correspondance first. Actually, there are patches that let you auto-create mailboxes, but, like your procmail fix, they are subject to denial of service attacks from people who know the process is automatic. Probably if you have particular problems with Cyrus, you should take them up with the Cyrus mailing lists. This has really gotten away from the request for a recommendation of which IMAP server to run on a FreeBSD system. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
On Fri, 21 Jun 2002, Terry Lambert wrote: It has functionality that can not be implemented without adding to how UNIX does things. Basically, it needs to be able to hook the account constructor/destructor. It's quite simple to integrate Cyrus IMAP with the local system. Cyrus will by default use the system password database for its authentication, all that is left is to write up a script to your liking to manage the IMAP folders (I wrote one in PERL using the IMAP::Admin and Mail::IMAPClient modules, but please don't ask me for them, I'm not that proud of them :-). You can hook that script in to whatever you're using to create the system user accounts. In the near future, however, I plan to move the authentication database into LDAP and have Cyrus use that so that I can get rid of all of the local system accounts which are there for nothing other than authentication (the shells are just /sbin/nologin). All in all, I love the Cyrus design, and it hasn't given me a bit of trouble in over 6 years. It makes doing a secure black-box mail server very easy. -- Chris Dillon - cdillon(at)wolves.k12.mo.us - cdillon(at)inter-linc.net FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64, PowerPC, UltraSPARC, and ARM architectures under development - http://www.freebsd.org No trees were harmed in the composition of this message, although some electrons were mildly inconvenienced. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
Chris Dillon wrote: On Fri, 21 Jun 2002, Terry Lambert wrote: It has functionality that can not be implemented without adding to how UNIX does things. Basically, it needs to be able to hook the account constructor/destructor. It's quite simple to integrate Cyrus IMAP with the local system. Cyrus will by default use the system password database for its authentication, While I appreciate the positive support of Cyrus, I guess I need to point out that this approach only works if you are willing to send passwords over the wire in plaintext. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
Terry Lambert wrote: Chris Dillon wrote: It's quite simple to integrate Cyrus IMAP with the local system. Cyrus will by default use the system password database for its authentication, While I appreciate the positive support of Cyrus, I guess I need to point out that this approach only works if you are willing to send passwords over the wire in plaintext. There's no support for SSL in Cyrus? What about secure authentication? Speaking of which, what does it take to get secure authentication to work on FreeBSD? Courier supports it, but the port compiles with options to disable the secure authentication methods. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
On Fri, 21 Jun 2002, Terry Lambert wrote: Chris Dillon wrote: On Fri, 21 Jun 2002, Terry Lambert wrote: It has functionality that can not be implemented without adding to how UNIX does things. Basically, it needs to be able to hook the account constructor/destructor. It's quite simple to integrate Cyrus IMAP with the local system. Cyrus will by default use the system password database for its authentication, While I appreciate the positive support of Cyrus, I guess I need to point out that this approach only works if you are willing to send passwords over the wire in plaintext. Yes, but this is the case with any IMAP server and doesn't really have anything to do with Cyrus in particular. Unlike other IMAP servers, however, Cyrus supports SASL which offers plenty of non-plain-text authentication options, unfortunately none of which work with a local FreeBSD password database that I know of. There is always the option to use SSL, which is my preference, but unfortunately neither SSL nor SASL have widespread IMAP client support yet. -- Chris Dillon - cdillon(at)wolves.k12.mo.us - cdillon(at)inter-linc.net FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64, PowerPC, UltraSPARC, and ARM architectures under development - http://www.freebsd.org No trees were harmed in the composition of this message, although some electrons were mildly inconvenienced. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Cyrus vs. UW IMAP (was: Re: I Volunteer)
Jason Andresen wrote: Brandon D. Valentine wrote: On Tue, 18 Jun 2002, Darren Pilgrim wrote: It's not exactly FreeBSD, but how about rewriting pine and uw-imap? Last I heard they could use a little work. It would have to be a complete reimplementation thanks to the retarded pine license. Besides, pine has been surpassed and it's called mutt. uw-imap has also been quite surpassed, it's called cyrus. I thought the strength of uw-imap was that it was fairly easy to configure for a machine with local users. The same certainly couldn't be said for Cyrus. Heck, I nearly slit my own wrists out of frustration trying to get Cyrus working. Doesn't help that its online documentation is poo either. The online documentation sucks, but once you understand that you have to use an admin program (cyradm) that has to be able to authenticate to the server in order to manage it, it's not very hard at all. The main problem with UW-IMAP is that it has some serious bugs; not only are there security bugs, but there are tons of bugs in the user libraries -- which is what most people are using for web based mail clients, and other programs... like Pine. The main problem is that there are a lot of instances where it is possible to result in calling unintialized function pointers when you attempt to access a mailbox provider type. The easiest way to see this is to make the function pointer containing struct into a pure virtual base class, each provider into a implementation class for that base class, and then pass around pointers to the provider class coerced to the virtual base class. You'll see all sorts of errors reported by the compiler about the use of a member of a class that can't be, or for which there is not a member function defined. A long time ago, I did this exercise for a commercial company, and found no less than 150 instances where this type of problem existed in the UW IMAP code. My personal recommendation, having contributed patches to both server maintainers, and used both servers in a commercia setting, is that the Cyrus IMAP server is far and away the better code base. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
Cyrus imapd is a real pain in the ass to administer local user accounts with though. The cyradm program is extremely deficient. Its great if you want to offer people imap e-mail without offering them shell access. For local access, though, there's a higher administrative overhead. I'm back to using the UW imapd even though I know it is a poorer codebase... On Thu, 20 Jun 2002, Terry Lambert wrote: Jason Andresen wrote: Brandon D. Valentine wrote: On Tue, 18 Jun 2002, Darren Pilgrim wrote: It's not exactly FreeBSD, but how about rewriting pine and uw-imap? Last I heard they could use a little work. It would have to be a complete reimplementation thanks to the retarded pine license. Besides, pine has been surpassed and it's called mutt. uw-imap has also been quite surpassed, it's called cyrus. I thought the strength of uw-imap was that it was fairly easy to configure for a machine with local users. The same certainly couldn't be said for Cyrus. Heck, I nearly slit my own wrists out of frustration trying to get Cyrus working. Doesn't help that its online documentation is poo either. The online documentation sucks, but once you understand that you have to use an admin program (cyradm) that has to be able to authenticate to the server in order to manage it, it's not very hard at all. The main problem with UW-IMAP is that it has some serious bugs; not only are there security bugs, but there are tons of bugs in the user libraries -- which is what most people are using for web based mail clients, and other programs... like Pine. The main problem is that there are a lot of instances where it is possible to result in calling unintialized function pointers when you attempt to access a mailbox provider type. The easiest way to see this is to make the function pointer containing struct into a pure virtual base class, each provider into a implementation class for that base class, and then pass around pointers to the provider class coerced to the virtual base class. You'll see all sorts of errors reported by the compiler about the use of a member of a class that can't be, or for which there is not a member function defined. A long time ago, I did this exercise for a commercial company, and found no less than 150 instances where this type of problem existed in the UW IMAP code. My personal recommendation, having contributed patches to both server maintainers, and used both servers in a commercia setting, is that the Cyrus IMAP server is far and away the better code base. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
Lamont Granquist wrote: Cyrus imapd is a real pain in the ass to administer local user accounts with though. You mean that it doesn't integrate well with the UNIX credentials system. THe issue here is that Cyrus needs to be able to hook create/delete actions on accounts, and UNIX fails to provide a means of doing this. I look at this as a UNIX deficiency. You can actually get around it by using pw and utilizing the script hooks it has. The easiest real fix for this would be to write a PAM module to cause the UNIX users to authenticate against the Cyrus database. The cyradm program is extremely deficient. Not a big issue, I think. Writing scripts to encapsulate it and be less deficient is really very trivial. Its great if you want to offer people imap e-mail without offering them shell access. For local access, though, there's a higher administrative overhead. I'm back to using the UW imapd even though I know it is a poorer codebase... I recommend you do not publicize the IP addresses of the servers, if they are net accessible outside your organization. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
