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)
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 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)
> "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 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)
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 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
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)
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)
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: I Volunteer
"Brandon D. Valentine" wrote: > > On Thu, 20 Jun 2002, Darren Pilgrim wrote: > > >Personally I'm all for courier-imap. IMAP and POP3, Maildirs, SSL, and > >the ability to access both real and virtual mailboxes. > > See my other recent message about the security implications of running > courier-imap. Also, maildirs are a mediocre idea for general use, and a > horrible idea for high volume mail spools. The whole idea behind IMAP > is for the mail to reside on the mail server, not a user's workstation. > Maildirs eat inodes like nobody's business. If you're using FFS to host > a fairly high traffic mail spool you'll probably need to newfs your > filesystem with a /ton/ of inodes. The only solution is to use a > filesystem which dynamically allocates inodes like XFS. Cyrus uses a > much more efficient storage mechanism. That's exactly where the difficulties come from. Cyrus is a royal PITA to convince to run on a machine that also has shells. For instance: in my case my local mail provider doesn't support IMAP (and their mailserver is quite a long way away from me and behind some rather laggy and slow pipes). I wanted to be able to run Sylpheed when I'm on the X console and pine when I'm remotely logged in. The only option (given that they use different mail formats) seemed to be to dump all of my mail into a local IMAP server (it's not a ton of mail either) so both programs could see it. While the uw-imap can do this with a bit of prodding (you have to change a variable in a dependancy to get it to no spew your imap directories all throughout your home directory), it works OK. I originally tried Cyrus IMAP (because it was supposedly better), but nearly pulled my head off trying to get all of the authentication/permission/configuration/login/etc issues worked out. I never actually did successfully create a subdirectory on the Cyrus server, and after poring over the tons of not-very-helpful docs, I eventually gave up and went to the uw solution. UW might not be the best technically, but I wasn't going to have to spend 6 weeks learning the intricacies of the permissions system on my IMAP server to get it working. -- \ |_ _|__ __|_ \ __| Jason Andresen[EMAIL PROTECTED] |\/ | ||/ _| Network and Distributed Systems Engineer _| _|___| _| _|_\___| Office: 703-883-7755 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 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. 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
Re: I Volunteer
Darren Pilgrim wrote: > Personally I'm all for courier-imap. IMAP and POP3, Maildirs, SSL, and > the ability to access both real and virtual mailboxes. Courrier is derived from one of the two under discussion, just like the Netscape IMAP server. -- 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
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: I Volunteer
On Thu, 20 Jun 2002, Darren Pilgrim wrote: >Personally I'm all for courier-imap. IMAP and POP3, Maildirs, SSL, and >the ability to access both real and virtual mailboxes. See my other recent message about the security implications of running courier-imap. Also, maildirs are a mediocre idea for general use, and a horrible idea for high volume mail spools. The whole idea behind IMAP is for the mail to reside on the mail server, not a user's workstation. Maildirs eat inodes like nobody's business. If you're using FFS to host a fairly high traffic mail spool you'll probably need to newfs your filesystem with a /ton/ of inodes. The only solution is to use a filesystem which dynamically allocates inodes like XFS. Cyrus uses a much more efficient storage mechanism. Brandon D. Valentine -- http://www.geekpunk.net [EMAIL PROTECTED] ++[>++<-]>[<++>-]<.>[>+<-]>[<+>-]<+.+++..++ +.>>+[<++>-]<++.<<+++.>.+++.--..>+. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: I Volunteer
On Thu, 20 Jun 2002, Jason Andresen wrote: >I thought the strength of uw-imap was that it was fairly easy to >configure for a machine with local users. The strength of uw-imap is clearly that it's fairly easy to allow remote users to root your machine. courier-imap has a bit better track record but still isn't stellar. This month there were exploits for both uw-imap and courier-imap. >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. Configuring Cyrus isn't any more difficult than any sufficiently useful piece of software like a good MTA, amanda, BIND, etc. The Linux Cyrus HOWTO is helpful as is the O'Reilly Managing IMAP book. Brandon D. Valentine -- http://www.geekpunk.net [EMAIL PROTECTED] ++[>++<-]>[<++>-]<.>[>+<-]>[<+>-]<+.+++..++ +.>>+[<++>-]<++.<<+++.>.+++.--..>+. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: I Volunteer
Jason Andresen wrote: > "Brandon D. Valentine" wrote: > > 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. > > On the other hand, dkimap is perfect as long as you don't mind your > mail databases slowly corrupting themselves. :P Personally I'm all for courier-imap. IMAP and POP3, Maildirs, SSL, and the ability to access both real and virtual mailboxes. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: I Volunteer
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. This message posted by a pine user via pine who's desperately been trying for months to find enough hours in the day to learn mutt well enough that he can migrate his primary email accounts over to it. Brandon D. Valentine -- http://www.geekpunk.net [EMAIL PROTECTED] ++[>++<-]>[<++>-]<.>[>+<-]>[<+>-]<+.+++..++ +.>>+[<++>-]<++.<<+++.>.+++.--..>+. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: I Volunteer
- Original Message - From: "Evan Dower" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 18, 2002 11:35 PM Subject: I Volunteer > I don't know who might have use of my services (or what my services might be > for that matter), but I hereby offer them up. I'm a student at the > University of Washington and I'll be applying to the Computer Science major > in February. I'd like to get involved with the OS that is serving me so > well. I'll do what I can to help with whatever. Just let me know if anyone > needs a minion. I could use the experience. Probably the best thing you can do for the project is to show some initiative. The problem reports database (accessible over the web at http://www.freebsd.org/prstats/index.html) can always use a good looking-over. Some reports are outdated and just need to be closed; some have a working patch included but have fallen through the cracks; and depending on your interests and level of coding ability, some could be relatively easy to fix. Do some work, make some noise, and express your interests and then whoever wants you as a minion will be more likely to find you. Whether or not coding is your forte, you can support the project in other ways as well. FreeBSD has great documentation, but it can always be improved or added to. I tend to proofread everything I read, so I've sent in a couple "bug" reports about manpage typos. I've been pleasantly surprised at both the promptness with which they were addressed and the gratitude expressed for my filing the reports. Evangelism and peer support are other great things you can do. Educate people at your school about FreeBSD and suggest ways that using FreeBSD might improve a lab/program/service. Answer questions on the -questions mailing list and/or the comp.unix.bsd.freebsd.misc newsgroup. FreeBSD is a great platform with an even greater user/developer community, so letting people know about it is always a good thing. Just a few ideas from my own experience... :) JN To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: I Volunteer
Evan Dower wrote: > > I don't know who might have use of my services (or what my services might be > for that matter), but I hereby offer them up. I'm a student at the > University of Washington and I'll be applying to the Computer Science major > in February. I'd like to get involved with the OS that is serving me so > well. I'll do what I can to help with whatever. Just let me know if anyone > needs a minion. I could use the experience. It's not exactly FreeBSD, but how about rewriting pine and uw-imap? Last I heard they could use a little work. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message