It includes full LDAP support now, can anyone test if it really works? It has worked with some of my tests, but I don't know too much about LDAP so I might have missed something important. The authentication problem in test1 and test2 is also fixed now.
Timo Sirainen wrote: > It includes full LDAP support now, can anyone test if it really works? > It has worked with some of my tests, but I don't know too much about > LDAP so I might have missed something important. ohh? and is there any doc about this part? did you see http://jamm.sourceforge.net/howto/html/ we plan to use it, but I'm not realy like courier... -- -- Levente "Si vis pacem para bellum!"
Hi Bit of a newbie to imap servers re: the article on webmonkey! http://hotwired.lycos.com/webmonkey/03/04/index3a_page4.html?tw=backend Been trying to set up SSL support with the latest ver. of dovecote I'm guessing that the following line from STDOUT is the problem. How to fix it is beyond my grasp currently. checking for SSL_read in -lssl... (cached) no Any ideas. ttfn Mark
On Tue, 4 Feb 2003, Timo Sirainen wrote: > Sorry, I just got a bit disappointed after reading the the web page first. > Your lines of code comparisions just seemed to imply that your server does > everything that others would but with only a fraction of code. Well, it doesn't claim to support other than Maildir, but it does claim to be a full IMAP4rev1 implementation. > When you write something from scratch, I think it's a good idea to design it > so that it's superior to existing implementations in at least some ways Are you suggesting that Andreas hasn't done this? > just make a clone with slightly different coding style. If all you wanted > was a clone with some changes (and better maintainer), forking the project > would be much smaller job. Who would want a clone of Courier IMAP?(Continue reading)> Separating the pre-login process from post-login process would probably be a > good idea to keep their functionality completely separated. It would also be > easier to audit the pre-login code if you knew exactly what there is. > After logging in, you could just exec() the post-login process. Agreed. Given that qmail-pop3d was an inspiration, I'm surprised this hasn't been done. You might look at http://www.untroubled.org/mailfront/imapfront.html for a
On Sun, 16 Feb 2003, Charlie Brady wrote: >On Tue, 4 Feb 2003, Timo Sirainen wrote: >> Sorry, I just got a bit disappointed after reading the the web page first. >> Your lines of code comparisions just seemed to imply that your server does >> everything that others would but with only a fraction of code. >Well, it doesn't claim to support other than Maildir, but it does claim to >be a full IMAP4rev1 implementation. The lines on comparison on Binc's web page are there as an example of how com it is completely possible to write an IMAP4rev1 compliant server with only a few lines of code, yes. >> When you write something from scratch, I think it's a good idea to design it >> so that it's superior to existing implementations in at least some ways >Are you suggesting that Andreas hasn't done this? I beleive that the first and most important stage in writing a good IMAP server is to implement the full unextended protocol in such a way that it serves perfectly as a drop-in for its competitors. The fancy features come easily later on when the design is modular. >> just make a clone with slightly different coding style. If all you wanted >> was a clone with some changes (and better maintainer), forking the project >> would be much smaller job. >Who would want a clone of Courier IMAP?(Continue reading)
On Fri, 2003-02-14 at 14:19, Mark Lancaster wrote: > Been trying to set up SSL support with the latest ver. of dovecote I'm guessing > that the following line from STDOUT is the problem. How to fix it is beyond my > grasp currently. > > checking for SSL_read in -lssl... (cached) no Install OpenSSL. Depending on your os/distribution it's likely in libssl* packages. libssl-dev is also needed. Or you could get the sources from www.openssl.org Also remove config.cache file after installing so that the check runs again.
On Mon, 2003-02-17 at 08:28, Andreas Aardal Hanssen wrote: > I wonder what the motives for the author of Dovecot IMAP was when he > started his project. Lack of securely written code in other servers, although Courier did prove to be quite secure after all. > I wouldn't want to comment on Dovecot's design, since I'm no fan of > trolling. I don't think commenting is trolling, as long as there's truth in it, or at least honest opinions. > The project clearly has different goals than Binc. Dovecot wants > excellent features, indexing and an advanced security promoting design. Implementation security as well. I'm not sure about features. It's more about trying to be fast and light. Indexes make Dovecot comparable to Cyrus in speed, but updating them isn't required so it's still drop-in replacement for UW imapd and Courier. Index files themselves aren't really required either, but there's no option currently to disable them. > It even recently included a POP server. What's the reasoning there? Someone wanted it so it'd be easy to run both POP3 and IMAP servers without having to configure them twice. I don't see any harm in it anyway, it took only few hours to write, it's optional and doesn't take much space in sources.(Continue reading)
On Mon, 2003-02-17 at 05:01, Charlie Brady wrote: > Timo, my preferred way to run network servers is to have tcpserver > running under supervise, and logging to multilog. bincimap is designed to > run this way. I don't know how dovecot executes - there's no mention of > either init.d or inetd in the documentation AFAICT. Can dovecot be used in > a supervise/tcpserver/multilog environment, and if so, how? I haven't looked too deeply into daemontools, but CVS supports logging into /dev/stderr (it was before closed or used for other purposes) which I've heard is enough for multilog. I don't think it could be made to run with tcpserver without changes. Dovecot is executed by running a master binary (imap-master before, dovecot in CVS) which creates rest of the required processes (authentication, pre-auth imap, post-auth imap)
On 17 Feb 2003, Timo Sirainen wrote: >On Mon, 2003-02-17 at 08:28, Andreas Aardal Hanssen wrote: >> I wonder what the motives for the author of Dovecot IMAP was when he >> started his project. >Lack of securely written code in other servers, although Courier did >prove to be quite secure after all. Binc IMAP's approaches are to use a secure programming language with secure well-known contructs, and with an as-simple-as-possible design, making it very easy for everyone to grasp how the server works. This will also help the community find and fix bugs. >> I wouldn't want to comment on Dovecot's design, since I'm no fan of >> trolling. >I don't think commenting is trolling, as long as there's truth in it, or >at least honest opinions. I agree to this, by all means, so let's keep our arguments exact and correct. >> It even recently included a POP server. What's the reasoning there? >Someone wanted it so it'd be easy to run both POP3 and IMAP servers >without having to configure them twice. I don't see any harm in it >anyway, it took only few hours to write, it's optional and doesn't take >much space in sources. Here's where I would say - there are hundreds of working POP3 servers around, both in closed and open source, so adding a POP3 server to the Dovecot project just introduces more lines of code where bugs may appear ;).(Continue reading)
On Mon, 2003-02-17 at 11:33, Andreas Aardal Hanssen wrote: > Binc IMAP's approaches are to use a secure programming language with > secure well-known contructs, and with an as-simple-as-possible design, > making it very easy for everyone to grasp how the server works. This will > also help the community find and fix bugs. I kind of agree, but not at the expense of security. I have tried to keep my code clean and ugly-optimization-free anyway. > Here's where I would say - there are hundreds of working POP3 servers > around, both in closed and open source, so adding a POP3 server to the > Dovecot project just introduces more lines of code where bugs may appear > ;). Yes, and I wouldn't have done it if it hadn't been so easy. I don't really encourage people to use it anyway, it's even disabled by default. If it has bugs, it doesn't affect the IMAP side. If people really need to run both IMAP and POP3 servers, it is simpler to use the same configuration for both, especially if the configuration isn't "standard" (eg. LDAP or SQL authentication, mailboxes in special locations, etc). All other major IMAP servers provide their own POP3 servers as well, if you haven't noticed :) > Donald Knuth said in a seminar that I attended that the best way to keep a > program free from bugs it to complete it. Finish off the project, work on > fixing bugs. That's Binc IMAP's philosophy.(Continue reading)
RSS Feed474 | |
|---|---|
640 | |
686 | |
636 | |
450 | |
384 | |
547 | |
661 | |
542 | |
536 | |
681 | |
654 | |
535 | |
629 | |
790 | |
736 | |
619 | |
523 | |
561 | |
313 | |
599 | |
456 | |
355 | |
639 | |
557 | |
510 | |
682 | |
578 | |
954 | |
813 | |
864 | |
1020 | |
1003 | |
1200 | |
927 | |
831 | |
794 | |
616 | |
778 | |
821 | |
826 | |
730 | |
667 | |
999 | |
616 | |
778 | |
949 | |
769 | |
792 | |
778 | |
626 | |
872 | |
880 | |
567 | |
564 | |
960 | |
667 | |
763 | |
764 | |
652 | |
735 | |
632 | |
617 | |
634 | |
783 | |
576 | |
706 | |
601 | |
718 | |
673 | |
599 | |
658 | |
855 | |
814 | |
1308 | |
987 | |
764 | |
471 | |
655 | |
757 | |
599 | |
804 | |
539 | |
838 | |
707 | |
702 | |
464 | |
549 | |
676 | |
470 | |
302 | |
474 | |
503 | |
514 | |
478 | |
333 | |
300 | |
455 | |
399 | |
186 | |
305 | |
445 | |
248 | |
326 | |
316 | |
198 | |
352 | |
400 | |
284 | |
158 | |
100 | |
139 | |
93 | |
72 | |
196 | |
98 | |
174 | |
232 | |
195 | |
202 | |
223 | |
200 | |
156 | |
64 | |
1 |
