syncnews gone in cyrus-iampd-2.19 ???
Hi, today i've successfull (so far as i can see :-)) upgradet from 1.6.24 to 2.1.9. But i can not find syncnews anymore?! In the manuals the part for integrating NetNews still talks about syncnews for synchronizing news and imap folders. Uh? Any suggestions? B.Rgds Reinhard Proessler Reinhard Proessler, Hanjin Shipping ::: EDP/Telecommunikation ::: Admiralitaetsstr. 56, 20459 Hamburg ::: Tel.: 0049 40 37685 443 mailto:[EMAIL PROTECTED]
Remove fro Cyrus mailing list
On Mon, 9 Dec 2002, Reinhard Proessler wrote: Date: Mon, 9 Dec 2002 09:53:03 +0100 From: Reinhard Proessler [EMAIL PROTECTED] To: Cyrus Maillinglist [EMAIL PROTECTED] Subject: syncnews gone in cyrus-iampd-2.19 ??? Hi, today i've successfull (so far as i can see :-)) upgradet from 1.6.24 to 2.1.9. But i can not find syncnews anymore?! In the manuals the part for integrating NetNews still talks about syncnews for synchronizing news and imap folders. Uh? Any suggestions? B.Rgds Reinhard Proessler Reinhard Proessler, Hanjin Shipping ::: EDP/Telecommunikation ::: Admiralitaetsstr. 56, 20459 Hamburg ::: Tel.: 0049 40 37685 443 mailto:[EMAIL PROTECTED] -- - \\\/// / _ _ \ (| (.)(.) |) ---.OOOo---()--oOOO.- Rajat Bhatia Email: [EMAIL PROTECTED] --.oooO-- ( ) Oooo. \ (( ) \_)) / (_/
Re: Outobox, Sent Items, Deleted Items folders
try putting the following line in your imapd.conf: altnamespace: yes I use mozilla and it works for me. Su Li wrote: Thanks, That works. I did creat those folders in IMAP, but they will show up under Inbox. Su -Original Message- From: Bryntez [mailto:[EMAIL PROTECTED]] Sent: December 6, 2002 3:22 PM To: Su Li Subject: Re: Outobox, Sent Items, Deleted Items folders If you go into the properties of the mail account in the client MS Outlook Express, you must go to the IMAP tab and make sure that the root folder path is INBOX Should work... _ Regards _ bryntez - Original Message - From: Su Li [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 06, 2002 9:01 PM Subject: Outobox, Sent Items, Deleted Items folders : Hi, : : I set up MS Outlook Express to get mail from Cyrus IMAP. When I creat a user, I only get Ibox folder. How can I get Outobox, Sent Items, Deleted Items? Is there any thing in Cyrus IMAP, I should turn it on to enable this? : : Thanks, : : Su : : : : -- Best Regards, Alessandro Oliveira Nuno Ferreira Cargas Internacionais Ltda. Phone: +55-11-3241-2000 Fax : +55-11-3242-9891 --- It's trivial to make fun of Microsoft products, but it takes a real man to make them work, and a god to make them do anything useful.
How to use non-ascii charsets with sieve?
Hi, (B (BCan someone give me "how to" pointer... (B (BI need to know how to use non-ASCII text in sieve scripts. (BFor example: using Japanese in message headers or mailbox names. (B (BFor example a message has a subject as follows: (B (B$BBjL>(B: $B%"%/%;%7%S%j%F%#%;%_%J!
Re: Fwd: pre-login buffer overflow in Cyrus IMAP server
On Tue, 3 Dec 2002, Rob Siemborski wrote: We'll be officially deprecating 1.x as of now (removal from the web and ftp sites except for the archives, etc). If anyone on the list is running 1.6.25 still I'd be interested in comparing fixes to this overflow bug in 1.6.25 code. T.
what isn't safe to run while master/imapd are up?
Occasionally I get messages stuck in my MTA, because lmtpd doesn't appear to return 250 aftger the DATA phase. They always unstick by restarting master. So, I'd like to try ctl_cyrusdb -r while it's running--is this a safe, recommended or very silly thing to do? I'm running 2.1.11. Matt
Re: Problems with cyrus-imapd 2.1.11 under Solaris 8
Henrique de Moraes Holschuh wrote: There is a more complete solution to the SIGCHILD problems in master, that fixes all the race conditions that cause the process count to be lost. I call it the pid morgue :-) It is in the bugzilla, and it is being used in production by the fastmail.fm people, AND all Debian users without a glitch for a long while now... Is there any reason why this SIGCHILD patch should not be applied to 2.1.11 under Solaris 8? Why is this not in recent releases of cyrus-imapd? The patch dates to May 02. http://bugzilla.andrew.cmu.edu/show_bug.cgi?id=1261 -- Stephen Grier Systems Developer Computing Services Queen Mary, University of London
Re: Problems with cyrus-imapd 2.1.11 under Solaris 8
--On Monday, December 09, 2002 4:39 PM + Stephen Grier [EMAIL PROTECTED] wrote: Henrique de Moraes Holschuh wrote: There is a more complete solution to the SIGCHILD problems in master, that fixes all the race conditions that cause the process count to be lost. I call it the pid morgue :-) It is in the bugzilla, and it is being used in production by the fastmail.fm people, AND all Debian users without a glitch for a long while now... Is there any reason why this SIGCHILD patch should not be applied to 2.1.11 under Solaris 8? Why is this not in recent releases of cyrus-imapd? The patch dates to May 02. Because making changes to master like this is fraught with race conditions. I'm not going to apply the patch until I've done a very careful review and I just haven't had the chance to do a very careful review. It hasn't been all that important for us since our master processes don't lose track of the number of children. Larry
Re: How to use non-ascii charsets with sieve?
Lawrence Greenfield wrote: You bring up good questions. First, our Sieve implementation currently doesn't deal with RFC 2047 encoded headers---or rather, it just compares the undecoded headers against the UTF-8 string. This is obviously a bug which sadly isn't in bugzilla. Ken and I talked (a long time ago) about this. The main issue is that Cyrus's character comparison routines remove whitespace and always perform casemapping, and this is probably inappropriate for Sieve's use. Fixing this is probably not difficult, but I'd prefer not to have multiple different canonicalization tables. I _think_ I still have the code around which implements the Sieve charset tables and does the rfc2047 decoding. I don't recall why we had to have the separate tables however. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Question: How to specify path to saslauthd mux socket in imapd.conf?
Hi, With the recent Cyrus IMAP buffer overflow exploit, its time to upgrade our mail server. I've been sitting on a Cyrus IMAP 2.1.X CVS install from right before the SASL2 requirement went into effect and have been holding off on upgrading until I can figure out a decent path to go from SASL1 - SASL2 and still keep LDAP authentication working. Currently, I'm using Simon's LDAP authentication patch for SASLv1. I have four different domains, all being served out of different trees on the same directory server. With sasl_auto_transition turned on, CRAM-MD5 and DIGEST-MD5 authentication works after an initial plaintext login (done at account setup on a local network). Since saslauthd only supports plaintext passwords for LDAP authentication, I'm thinking that if I trade the stronger SASL authentication off for requiring TLS for the entire IMAP conversation (via , I don't give anything up security-wise. In other words, I can rely on the transport layer to provide encryption, instead of a higher layer and that way email can't be sniffed either. So I upgraded to the latest versions of Cyrus SASL (2.1.10) and Cyrus IMAP (2.1.11) today on my test server. I got saslauthd working fine with LDAP for one Cyrus IMAP virtual domain (the altconfig type meaning I specify a full set of services per domain, bound to a unique IP address and I have a unique imapd.conf for each domain, I'm not talking about the newer virtual domain support). What I still need to figure out is how to specify which saslauthd mux socket for each domain's imap process to connect to. I know how to start multiple saslauthd's and specify which socket for them to create but I need to know how to specify in /etc/imapd.conf which of those sockets to connect to. I can't seem to find that documented anywhere (probably because its only in this special case scenario that you'd even need to use it :) Also, is it reasonable to think that most major IMAP clients could handle talking to a server that only listens on imaps (basically my forcing of TLS idea above)? I know my webmail client, IMP, can handle that but can most other standalone clients handle imaps well and will they barf over self-signed certificates? As always, if there's a simpler way to do this whole thing, I'd like to hear about it. What I have now works extremely well, so I'm not inclined to change it too much but I could be missing something very obvious too. I know there's supposedly an OpenLDAP 2.X internal auxprop plugin in the works but that won't help me too much since our directory server is iPlanet DS. Maybe its time to bite the bullet and migrate directory server platforms too... Thanks, Kevin -- Kevin M. Myer Systems Administrator Lancaster-Lebanon Intermediate Unit 13 (717) 560-6140
Re: Question: How to specify path to saslauthd mux socket inimapd.conf?
On Mon, 9 Dec 2002, Kevin M. Myer wrote: conversation (via , I don't give anything up security-wise. In other words, I can rely on the transport layer to provide encryption, instead of a higher layer and that way email can't be sniffed either. You do of course realize that email is transmitted plaintext to your MX server anyway from the rest of the world, right? So I upgraded to the latest versions of Cyrus SASL (2.1.10) and Cyrus IMAP (2.1.11) today on my test server. I got saslauthd working fine with LDAP for one Cyrus IMAP virtual domain (the altconfig type meaning I specify a full set of services per domain, bound to a unique IP address and I have a unique imapd.conf for each domain, I'm not talking about the newer virtual domain support). What I still need to figure out is how to specify which saslauthd mux socket for each domain's imap process to connect to. I know how to start multiple saslauthd's and specify which socket for them to create but I need to know how to specify in /etc/imapd.conf which of those sockets to connect to. I can't seem to find that documented anywhere (probably because its only in this special case scenario that you'd even need to use it :) From SASL's doc/options.html: saslauthd_path is the SASL option you want, so sasl_saslauthd_path is the imapd.conf option. Leave off the /mux You're right, this is really the only case I've ever heard of this support actually being useful ;) Also, is it reasonable to think that most major IMAP clients could handle talking to a server that only listens on imaps (basically my forcing of TLS idea above)? I know my webmail client, IMP, can handle that but can most other standalone clients handle imaps well and will they barf over self-signed certificates? Pine, Mulberry, Outlook, Mozilla, Netscape, etc should all have no trouble with TLS. There may be a certificate warning about your self-signed certificate. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
can't find acap.h while building imapd-2.1.11
I'm trying to build imapd-2.1.11 I unpacked the source tarball into a direction and then I build from another directory (since I have multiple architectures). I configured like this: $ ../../src/configure \ --prefix=/opt/cyrus-imapd-2.1.11 \ --with-cyrus-prefix=/opt/cyrus-imap-2.1.11 \ --with-cyrus-user=cyrusadm \ --with-cyrus-group=mailer \ --with-dbdir=/opt/BerkeleyDB.3.3 \ --with-auth=unix \ --enable-murder \ --disable-sieve \ --enable-fulldirhash \ --with-openssl \ --with-sasl=/opt/local $ make ### Making all in /src/mail/cyrus/cyrus-imapd-2.1.11/obj/solaris9/acap make[1]: Entering directory `/src/mail/cyrus/cyrus-imapd-2.1.11/obj/solaris9/acap' gcc -c -I/opt/BerkeleyDB.3.3/include -I/usr/local/include -I/opt/local/include -I. -I.. -I../lib -DHAVE_CONFIG_H -Wall -g -O2 \ ../../../src/acap/acapsieve.c ../../../src/acap/acapsieve.c:20: acap.h: No such file or directory make[1]: *** [acapsieve.o] Error 1 make[1]: Leaving directory `/src/mail/cyrus/cyrus-imapd-2.1.11/obj/solaris9/acap' make: *** [all] Error 1 acap.h does exist in ../../../src/acap/acap.h Should configure have added '$srcdir/.' to CPPFLAGS instead of '.' in the acap/Makefile?
Re: Question: How to specify path to saslauthd mux socket in imapd.conf?
As usual, I find the answer in the documentation shortly after I release my question to the list. You can specify sasl_saslauthd_path in imapd.conf and that works. What doesn't work is that the SASL documentation claims that: saslauthd_path SASL Library Path to saslauthd run directory (not including the /mux named pipe) system dependant I couldn't get it to work without including the /mux named pipe, both when launching saslauthd with the -m option and in imapd.conf. I'm not subscribed to the sasl list so maybe someone who straddles both lists can commit a fix (or maybe I'm reading the documentation wrong, in which case I need to commit a fix to my brain). Ex: Directory is /var/test named pipe should be /var/test/mux If I start saslauthd with: saslauthd -m /var/test -a ldap and include in imapd.conf: sasl_saslauthd_path: /var/test saslauthd complains that: FATAL: /var/test: Address already in use Including the mux named pipe causes this to work so I think the documentation should read that you DO need to include the mux named pipe or maybe the saslauthd_path option should be changed to saslauthd_mux_path. Now I just need to test and make sure multiple different instances of saslauthd don't clobber each other's internal structures. FWIW, this is on Red Hat Linux 7.1 (and a half because I ended up backporting so many packages from newer releases) on Intel hardware. Kernel is 2.4.9-smp-34 - I'll probably be updating to RedHat 7.3 over Christmas break. Kevin -- Kevin M. Myer Systems Administrator Lancaster-Lebanon Intermediate Unit 13 (717) 560-6140
Re: Question: How to specify path to saslauthd mux socket inimapd.conf?
On Mon, 9 Dec 2002, Kevin M. Myer wrote: Including the mux named pipe causes this to work so I think the documentation should read that you DO need to include the mux named pipe or maybe the saslauthd_path option should be changed to saslauthd_mux_path. Yes. This is what I get for believing my own documentation. I'm updating this now. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Question: How to specify path to saslauthd mux socket inimapd.conf?
On Mon, 9 Dec 2002, Kevin M. Myer wrote: Hi, With the recent Cyrus IMAP buffer overflow exploit, its time to upgrade our mail server. I've been sitting on a Cyrus IMAP 2.1.X CVS install from right before the SASL2 requirement went into effect and have been holding off on upgrading until I can figure out a decent path to go from SASL1 - SASL2 and still keep LDAP authentication working. Currently, I'm using Simon's LDAP authentication patch for SASLv1. I have four different domains, all being served out of different trees on the same directory server. With sasl_auto_transition turned on, CRAM-MD5 and DIGEST-MD5 authentication works after an initial plaintext login (done at account setup on a local network). Since saslauthd only supports plaintext passwords for LDAP authentication, I'm thinking that if I trade the stronger SASL authentication off for requiring TLS for the entire IMAP conversation (via , I don't give anything up security-wise. In other words, I can rely on the transport layer to provide encryption, instead of a higher layer and that way email can't be sniffed either. So I upgraded to the latest versions of Cyrus SASL (2.1.10) and Cyrus IMAP (2.1.11) today on my test server. I got saslauthd working fine with LDAP for one Cyrus IMAP virtual domain (the altconfig type meaning I specify a full set of services per domain, bound to a unique IP address and I have a unique imapd.conf for each domain, I'm not talking about the newer virtual domain support). What I still need to figure out is how to specify which saslauthd mux socket for each domain's imap process to connect to. I know how to start multiple saslauthd's and specify which socket for them to create but I need to know how to specify in /etc/imapd.conf which of those sockets to connect to. I can't seem to find that documented anywhere (probably because its only in this special case scenario that you'd even need to use it :) Also, is it reasonable to think that most major IMAP clients could handle talking to a server that only listens on imaps (basically my forcing of TLS idea above)? I know my webmail client, IMP, can handle that but can most other standalone clients handle imaps well and will they barf over self-signed certificates? As always, if there's a simpler way to do this whole thing, I'd like to hear about it. What I have now works extremely well, so I'm not inclined to change it too much but I could be missing something very obvious too. I know there's supposedly an OpenLDAP 2.X internal auxprop plugin in the works but that won't help me too much since our directory server is iPlanet DS. Maybe its time to bite the bullet and migrate directory server platforms too... OpenLDAP internal auxprop plugin works for OpenLDAP only. You will need to build your own or try a few plugins available on the web. One is available in the contrib directory of the latest OpenLDAP tarball. -- Igor
Re: can't find acap.h while building imapd-2.1.11
Matt Selsky wrote: I'm trying to build imapd-2.1.11 I unpacked the source tarball into a direction and then I build from another directory (since I have multiple architectures). I configured like this: $ ../../src/configure \ --prefix=/opt/cyrus-imapd-2.1.11 \ --with-cyrus-prefix=/opt/cyrus-imap-2.1.11 \ --with-cyrus-user=cyrusadm \ --with-cyrus-group=mailer \ --with-dbdir=/opt/BerkeleyDB.3.3 \ --with-auth=unix \ --enable-murder \ --disable-sieve \ --enable-fulldirhash \ --with-openssl \ --with-sasl=/opt/local $ make ### Making all in /src/mail/cyrus/cyrus-imapd-2.1.11/obj/solaris9/acap make[1]: Entering directory `/src/mail/cyrus/cyrus-imapd-2.1.11/obj/solaris9/acap' gcc -c -I/opt/BerkeleyDB.3.3/include -I/usr/local/include -I/opt/local/include -I. -I.. -I../lib -DHAVE_CONFIG_H -Wall -g -O2 \ ../../../src/acap/acapsieve.c ../../../src/acap/acapsieve.c:20: acap.h: No such file or directory make[1]: *** [acapsieve.o] Error 1 make[1]: Leaving directory `/src/mail/cyrus/cyrus-imapd-2.1.11/obj/solaris9/acap' make: *** [all] Error 1 acap.h does exist in ../../../src/acap/acap.h Should configure have added '$srcdir/.' to CPPFLAGS instead of '.' in the acap/Makefile? I had problems with the sieve and perl part too when trying to build out of the source directory. Acap and sieve were fixed with these patches, but I couldn't get the perl part to build. Seems I need to patch MakeMaker for this 8-( $ diff -u acap/Makefile.in.orig acap/Makefile.in --- acap/Makefile.in.orig Sat May 25 21:57:41 2002 +++ acap/Makefile.inSat Dec 7 20:40:04 2002 @@ -51,7 +51,7 @@ RANLIB = @RANLIB@ DEFS = @DEFS@ -CPPFLAGS = @CPPFLAGS@ @SASLFLAGS@ -I. -I.. -I../lib +CPPFLAGS = @CPPFLAGS@ @SASLFLAGS@ -I. -I.. -I$(srcdir) -I../lib LIBS = @LIBS@ CFLAGS = @CFLAGS@ diff -u sieve/Makefile.in.orig sieve/Makefile.in --- sieve/Makefile.in.orig Sat Dec 7 20:31:59 2002 +++ sieve/Makefile.in Sat Dec 7 20:32:47 2002 @@ -70,6 +70,8 @@ mv -f y.tab.h sieve.h addr-lex.c: addr-lex.l addr.h + $(LEX) $(srcdir)/addr-lex.l + mv -f lex.addr.c addr-lex.c addr.c addr.h: addr.y $(YACC) $(YFLAGS) -p addr $(srcdir)/addr.y -- Med venlig hilsen / Kind regards Hack Kampbjørn
using Murder for migration from UW IMAP
Would it be possible to use Murder to migrate from UW IMAP? I have Cyrus setup and running on a new machine, but the problem is that taking everything down and converting all the mailboxes would be too much downtime (2-3 days). What I was thinking of is setting up a frontend server with UW IMAP and Cyrus as the backend servers, with the initial mupdated database showing all the mailboxes were on the old IMAP server. UW IMAP isn't going to talk to mupdated, but if no mailboxes are being created there it seems like that won't matter. As each mailbox is moved to the new server, the master list of mailboxes is reflected to update the new location. From my inspection of the documentation and some of the code, it looks like this should work with a couple of caveats (during the transition, users have to be prevented from creating new mailboxes -- this can be hacked in the code, and connections that have been referred to the old server have to be broken when the mailbox is transferred). Does anyone see a reason why this won't work or any other gotchas to watch for? Thanks. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
Re: can't find acap.h while building imapd-2.1.11
I had problems with the sieve and perl part too when trying to build out of the source directory. Acap and sieve were fixed with these patches, but I couldn't get the perl part to build. Seems I need to patch MakeMaker for this 8-( $ diff -u acap/Makefile.in.orig acap/Makefile.in --- acap/Makefile.in.orig Sat May 25 21:57:41 2002 +++ acap/Makefile.inSat Dec 7 20:40:04 2002 @@ -51,7 +51,7 @@ RANLIB = @RANLIB@ DEFS = @DEFS@ -CPPFLAGS = @CPPFLAGS@ @SASLFLAGS@ -I. -I.. -I../lib +CPPFLAGS = @CPPFLAGS@ @SASLFLAGS@ -I. -I.. -I$(srcdir) -I../lib LIBS = @LIBS@ CFLAGS = @CFLAGS@ diff -u sieve/Makefile.in.orig sieve/Makefile.in --- sieve/Makefile.in.orig Sat Dec 7 20:31:59 2002 +++ sieve/Makefile.in Sat Dec 7 20:32:47 2002 @@ -70,6 +70,8 @@ mv -f y.tab.h sieve.h addr-lex.c: addr-lex.l addr.h + $(LEX) $(srcdir)/addr-lex.l + mv -f lex.addr.c addr-lex.c addr.c addr.h: addr.y $(YACC) $(YFLAGS) -p addr $(srcdir)/addr.y I patched acap/Makefile.in and also master/Makefile.in and imap/Makefile.in --- master/Makefile.in.orig 2002/12/09 23:03:36 +++ master/Makefile.in 2002/12/09 23:07:31 @@ -53,7 +53,7 @@ CYRUS_GROUP=@cyrus_group@ DEFS = @DEFS@ @LOCALDEFS@ -CPPFLAGS = -I. -I.. -I../lib -I$(srcdir) @CPPFLAGS@ @COM_ERR_CPPFLAGS@ +CPPFLAGS = -I. -I.. -I../lib -I$(srcdir) -I$(srcdir)/../lib @CPPFLAGS@ @COM_ERR_CPPFLAGS@ DEPLIBS = @DEPLIBS@ CFLAGS = @CFLAGS@ --- imap/Makefile.in.orig Mon Nov 4 12:39:36 2002 +++ imap/Makefile.inMon Dec 9 18:12:24 2002 @@ -62,7 +62,7 @@ CYRUS_GROUP=@cyrus_group@ DEFS = @DEFS@ @LOCALDEFS@ -CPPFLAGS = -I. -I.. -I../sieve -I$(srcdir) -I$(srcdir)/../lib -I$(srcdir)/../acap -I../acap @COM_ERR_CPPFLAGS@ @SIEVE_CPPFLAGS@ @CPPFLAGS@ @SASLFLAGS@ +CPPFLAGS = -I. -I.. -I../sieve -I$(srcdir) -I$(srcdir)/../lib -I$(srcdir)/../acap +-I../acap -I$(srcdir)/../sieve @COM_ERR_CPPFLAGS@ @SIEVE_CPPFLAGS@ @CPPFLAGS@ +@SASLFLAGS@ IMAP_LIBS = @IMAP_LIBS@ SIEVE_LIBS = @SIEVE_LIBS@ IMAP_COM_ERR_LIBS = @IMAP_COM_ERR_LIBS@ I also ran into a problem with perl, but for now, I'm building without it (--without-perl).
Re: using Murder for migration from UW IMAP
On Mon, 9 Dec 2002, John Alton Tamplin wrote: Would it be possible to use Murder to migrate from UW IMAP? I have Cyrus setup and running on a new machine, but the problem is that taking everything down and converting all the mailboxes would be too much downtime (2-3 days). What I was thinking of is setting up a frontend server with UW IMAP and Cyrus as the backend servers, with the initial mupdated database showing all the mailboxes were on the old IMAP server. UW IMAP isn't going to talk to mupdated, but if no mailboxes are being created there it seems like that won't matter. As each mailbox is moved to the new server, the master list of mailboxes is reflected to update the new location. From my inspection of the documentation and some of the code, it looks like this should work with a couple of caveats (during the transition, users have to be prevented from creating new mailboxes -- this can be hacked in the code, and connections that have been referred to the old server have to be broken when the mailbox is transferred). Does anyone see a reason why this won't work or any other gotchas to watch for? Thanks. So, the murder really isn't intended to work like this. Does UW-IMAPd even support proxy authentication? If it does, *offhand*, provided you're not using internal mechanisms to move the mailboxes (i.e. you are moving them by hand), I don't really see a reason this won't work, but I'm not going to recommend it. Do you really have so much data that it would take 2-3 days to move it? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: using Murder for migration from UW IMAP
Quoting Rob Siemborski [EMAIL PROTECTED]:
So, the murder really isn't intended to work like this.
Right, I understand. I also looked for more generic IMAP/LMTP proxies but most
of the links were dead and the ones that weren't seemed to be lacking something.
Does UW-IMAPd even support proxy authentication?
No, logins to it will have to be the user who is accessing their mailboxes.
Once the client logs into the proxy, isn't that same login information passed
onto the backend server?
If it does, *offhand*, provided you're not using internal mechanisms to
move the mailboxes (i.e. you are moving them by hand), I don't really see
a reason this won't work, but I'm not going to recommend it.
Here is pseudo-code of how I envisioned the process:
Populate mupdated with initial database showing all mailboxes on old server
for each user {
block mail delivery to the user (LMTP returns temporary failure)
block write access in UW IMAP (minor hack to locking code)
connect to Cyrus server as user with backdoor password (via saslauthd)
for each user mailbox {
create mailbox on Cyrus server
Do you really have so much data that it would take 2-3 days to move it?
The tests I have done so far (using both imap-utils mbxcvt and custom perl code)
it looks like it will take around 60 hours to convert everything (2300 users,
23000 folders, 70G total), and that is putting /var/imap on a tmpfs filesystem
for the conversion (about a 2x speed improvement there) and striping /cyrus
across 14 drives in an FC-AL array.
--
John A. Tamplin
Unix System Administrator
Re: using Murder for migration from UW IMAP
On Mon, 9 Dec 2002, John A. Tamplin wrote: No, logins to it will have to be the user who is accessing their mailboxes. Once the client logs into the proxy, isn't that same login information passed onto the backend server? No, the IMAP proxies use a superuser account to auth to the backends. It's not quite an IMAP admin, but its pretty close. This is because mechanisms such as KERBEROS_V4 and GSSAPI make passing credentials hard. Do you really have so much data that it would take 2-3 days to move it? The tests I have done so far (using both imap-utils mbxcvt and custom perl code) it looks like it will take around 60 hours to convert everything (2300 users, 23000 folders, 70G total), and that is putting /var/imap on a tmpfs filesystem for the conversion (about a 2x speed improvement there) and striping /cyrus across 14 drives in an FC-AL array. Perhaps you'd be better off using Perdition or another IMAP proxy to do the move, since the murder is really trying to solve a slightly different problem. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: can't find acap.h while building imapd-2.1.11
On Tue, 10 Dec 2002, Hack Kampbjorn wrote: diff -u sieve/Makefile.in.orig sieve/Makefile.in --- sieve/Makefile.in.orig Sat Dec 7 20:31:59 2002 +++ sieve/Makefile.in Sat Dec 7 20:32:47 2002 @@ -70,6 +70,8 @@ mv -f y.tab.h sieve.h addr-lex.c: addr-lex.l addr.h + $(LEX) $(srcdir)/addr-lex.l + mv -f lex.addr.c addr-lex.c addr.c addr.h: addr.y $(YACC) $(YFLAGS) -p addr $(srcdir)/addr.y What make and lex are you using that requires this? I don't understand the need for the mv command at all. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: using Murder for migration from UW IMAP
On Monday 09 December 2002 06:37 pm, John Alton Tamplin wrote: Would it be possible to use Murder to migrate from UW IMAP? I have Cyrus setup and running on a new machine, but the problem is that taking everything down and converting all the mailboxes would be too much downtime (2-3 days). What I was thinking of is setting up a frontend server with UW IMAP and Cyrus as the backend servers, with the initial mupdated database showing all the mailboxes were on the old IMAP server. UW IMAP isn't going to talk to mupdated, but if no mailboxes are being created there it seems like that won't matter. As each mailbox is moved to the new server, the master list of mailboxes is reflected to update the new location. From my inspection of the documentation and some of the code, it looks like this should work with a couple of caveats (during the transition, users have to be prevented from creating new mailboxes -- this can be hacked in the code, and connections that have been referred to the old server have to be broken when the mailbox is transferred). Does anyone see a reason why this won't work or any other gotchas to watch for? Thanks. You might also want to consider using the perdition IMAP/Pop3 proxy. It's well suited for something like this since it can use LDAP, MySQL, PostreSQL, and local GDBM databases to lookup the real server for users. http://www.vergenet.net/linux/perdition/ Cheers, Jeremy
Re: can't find acap.h while building imapd-2.1.11
Rob Siemborski wrote: On Tue, 10 Dec 2002, Hack Kampbjorn wrote: diff -u sieve/Makefile.in.orig sieve/Makefile.in --- sieve/Makefile.in.orig Sat Dec 7 20:31:59 2002 +++ sieve/Makefile.in Sat Dec 7 20:32:47 2002 @@ -70,6 +70,8 @@ mv -f y.tab.h sieve.h addr-lex.c: addr-lex.l addr.h + $(LEX) $(srcdir)/addr-lex.l + mv -f lex.addr.c addr-lex.c addr.c addr.h: addr.y $(YACC) $(YFLAGS) -p addr $(srcdir)/addr.y What make and lex are you using that requires this? I don't understand the need for the mv command at all. This is on a OpenBSD 3.2, so that would be bmake and flex: $ flex --version flex version 2.5.4 Without the explicit lex and mv I got this error as flex produced a lex.addr.c file and not lex.yy.c as make expected: $ make -f Makefile.orig flex ../../cyrus-imapd-2.1.11.orig/sieve/addr-lex.l mv lex.yy.c addr-lex.c mv: lex.yy.c: No such file or directory *** Error code 1 Stop in /usr/ports/mystuff/mail/cyrus-imapd/w-cyrus-imapd-2.1.11/build/sieve. What should I do instead? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper -- Med venlig hilsen / Kind regards Hack Kampbjørn
Re: can't find acap.h while building imapd-2.1.11
I've applied patches similar to these (and the acap one, though we're dropping the acap directory in 2.2 anyway, so) to CVS. Thanks, -Rob On Mon, 9 Dec 2002, Matt Selsky wrote: I had problems with the sieve and perl part too when trying to build out of the source directory. Acap and sieve were fixed with these patches, but I couldn't get the perl part to build. Seems I need to patch MakeMaker for this 8-( $ diff -u acap/Makefile.in.orig acap/Makefile.in --- acap/Makefile.in.orig Sat May 25 21:57:41 2002 +++ acap/Makefile.inSat Dec 7 20:40:04 2002 @@ -51,7 +51,7 @@ RANLIB = @RANLIB@ DEFS = @DEFS@ -CPPFLAGS = @CPPFLAGS@ @SASLFLAGS@ -I. -I.. -I../lib +CPPFLAGS = @CPPFLAGS@ @SASLFLAGS@ -I. -I.. -I$(srcdir) -I../lib LIBS = @LIBS@ CFLAGS = @CFLAGS@ diff -u sieve/Makefile.in.orig sieve/Makefile.in --- sieve/Makefile.in.orig Sat Dec 7 20:31:59 2002 +++ sieve/Makefile.in Sat Dec 7 20:32:47 2002 @@ -70,6 +70,8 @@ mv -f y.tab.h sieve.h addr-lex.c: addr-lex.l addr.h + $(LEX) $(srcdir)/addr-lex.l + mv -f lex.addr.c addr-lex.c addr.c addr.h: addr.y $(YACC) $(YFLAGS) -p addr $(srcdir)/addr.y I patched acap/Makefile.in and also master/Makefile.in and imap/Makefile.in --- master/Makefile.in.orig 2002/12/09 23:03:36 +++ master/Makefile.in 2002/12/09 23:07:31 @@ -53,7 +53,7 @@ CYRUS_GROUP=@cyrus_group@ DEFS = @DEFS@ @LOCALDEFS@ -CPPFLAGS = -I. -I.. -I../lib -I$(srcdir) @CPPFLAGS@ @COM_ERR_CPPFLAGS@ +CPPFLAGS = -I. -I.. -I../lib -I$(srcdir) -I$(srcdir)/../lib @CPPFLAGS@ @COM_ERR_CPPFLAGS@ DEPLIBS = @DEPLIBS@ CFLAGS = @CFLAGS@ --- imap/Makefile.in.orig Mon Nov 4 12:39:36 2002 +++ imap/Makefile.inMon Dec 9 18:12:24 2002 @@ -62,7 +62,7 @@ CYRUS_GROUP=@cyrus_group@ DEFS = @DEFS@ @LOCALDEFS@ -CPPFLAGS = -I. -I.. -I../sieve -I$(srcdir) -I$(srcdir)/../lib -I$(srcdir)/../acap -I../acap @COM_ERR_CPPFLAGS@ @SIEVE_CPPFLAGS@ @CPPFLAGS@ @SASLFLAGS@ +CPPFLAGS = -I. -I.. -I../sieve -I$(srcdir) -I$(srcdir)/../lib -I$(srcdir)/../acap -I../acap -I$(srcdir)/../sieve @COM_ERR_CPPFLAGS@ @SIEVE_CPPFLAGS@ @CPPFLAGS@ @SASLFLAGS@ IMAP_LIBS = @IMAP_LIBS@ SIEVE_LIBS = @SIEVE_LIBS@ IMAP_COM_ERR_LIBS = @IMAP_COM_ERR_LIBS@ I also ran into a problem with perl, but for now, I'm building without it (--without-perl). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: can't find acap.h while building imapd-2.1.11
On Tue, 10 Dec 2002, Hack Kampbjorn wrote: This is on a OpenBSD 3.2, so that would be bmake and flex: $ flex --version flex version 2.5.4 Okay, I'm guessing it's more bmake than flex, since the implicit rules supplied by gmake are creating this file like so: flex -t addr-lex.l addr-lex.c What should I do instead? Use gmake? ;) Seriously though, I highly doubt this is the only place in the code that there's problems with a non-GNU make. (Indeed, the same makefile has that problem with sieve-lex.c/sieve-lex.l). Or was this really the only problem? If you have a complete set of patches, I'm definately willing to look at them. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: can't find acap.h while building imapd-2.1.11
Rob Siemborski wrote: On Tue, 10 Dec 2002, Hack Kampbjorn wrote: This is on a OpenBSD 3.2, so that would be bmake and flex: $ flex --version flex version 2.5.4 Okay, I'm guessing it's more bmake than flex, since the implicit rules supplied by gmake are creating this file like so: flex -t addr-lex.l addr-lex.c What should I do instead? Use gmake? ;) Seriously though, I highly doubt this is the only place in the code that there's problems with a non-GNU make. (Indeed, the same makefile has that problem with sieve-lex.c/sieve-lex.l). Or was this really the only problem? Yes, that's was the only make problem and only when builddir != srcdir. If you have a complete set of patches, I'm definately willing to look at them. Ok, my private OpenBSD port have these patches: patch-acap_Makefile_in patch-imap_duplicate_c patch-imap_sendmail-map_c patch-imtest_imtest_c patch-lib_auth_krb_c patch-lib_auth_krb_pts_c patch-lib_auth_krb_pts_h patch-lib_cyrusdb_db3_c patch-ptclient_ptloader_c patch-sieve_Makefile_in The acap and sieve are the ones I already sent. patch-imtest_imtest_c explicitly includes openssl/md5.h as OpenBSD 3.2 comes with OpenSSL 0.9.7-beta3 30 Jul 2002. I suppose this should check if OPENSSL_VERSION_NUMBER = 0x00907000L --- imtest/imtest.c.origMon Nov 4 17:10:32 2002 +++ imtest/imtest.c Sat Dec 7 15:39:54 2002 @@ -78,6 +78,7 @@ #ifdef HAVE_SSL #include openssl/ssl.h +#include openssl/md5.h static SSL_CTX *tls_ctx = NULL; static SSL *tls_conn = NULL; The rest changes db.h to db3.h as installed by the db3 port. OpenBSD has the original db1 as db.h. The configure script is smart enough to find db3 support with -ldb and db3.h but all the cyrus-imapd soruces has hardcoded db.h -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper -- Med venlig hilsen / Kind regards Hack Kampbjørn
Re: How to use non-ascii charsets with sieve?
First, our Sieve implementation currently doesn't deal with RFC 2047 encoded headers---or rather, it just compares the undecoded headers against the UTF-8 string. This is obviously a bug which sadly isn't in bugzilla. Ken and I talked (a long time ago) about this. The main issue is that Cyrus's character comparison routines remove whitespace and always perform casemapping, and this is probably inappropriate for Sieve's use. Fixing this is probably not difficult, but I'd prefer not to have multiple different canonicalization tables. I _think_ I still have the code around which implements the Sieve charset tables and does the rfc2047 decoding. I don't recall why we had to have the separate tables however. different comparators would require different tables, I think. The table Cyrus usually uses isn't suitable for i;ascii-casemap since space isn't significant, but transcoding to UTF-8 and doing a dumb comparison is all that's required, a big improvement on what Cyrus is doing now, and not hard to implement. Tim
Re: Cyrus SASL 2.1.10 Released
Hack Kampbjorn wrote: Rob Siemborski wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd like to announce the release of Cyrus SASL 2.1.10 on ftp.andrew.cmu.edu. This version corrects a number of DIGEST-MD5 interoperability issues, as well as corrects some potential buffer overflows. It is recommended that all sites using a 2.x release upgrade to 2.1.10. Please send any feedback either to [EMAIL PROTECTED] (public list) or to [EMAIL PROTECTED] Download at: ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/cyrus-sasl-2.1.10.tar.gz or http://ftp.andrew.cmu.edu/pub/cyrus-mail/cyrus-sasl-2.1.10.tar.gz This includes two backup files which can be quite confusing: $ tar ztf ../../distfiles/cyrus-sasl-2.1.10.tar.gz cyrus-sasl-2.1.10/config/kerberos* cyrus-sasl-2.1.10/config/kerberos_v4.m4 cyrus-sasl-2.1.10/config/kerberos_v4.m4.orig cyrus-sasl-2.1.10/config/kerberos_v4.m4~ More problems: with cyrus-sasl version 2.1.9 plugins/otp.c only defined MD5_H for OpenSSL versions 0.9.7 but in version 2.1.10 the check is removed. OpenBSD 3.2 ships with OpenSSL 0.9.7-beta3 30 Jul 2000 (0x00907003L) and fails with this error: /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -I. -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/plugins -I.. -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/include -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/lib -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/sasldb -I/usr/local/include -I/usr/include/kerberosIV -I/usr/include/kerberosV -I/usr/include -Wall -W -Wall -O2 -I/usr/include/kerberosV -c /usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/plugins/otp.c rm -f .libs/otp.lo cc -DHAVE_CONFIG_H -I. -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/plugins -I.. -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/include -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/lib -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/sasldb -I/usr/local/include -I/usr/include/kerberosIV -I/usr/include/kerberosV -I/usr/include -Wall -W -Wall -O2 -I/usr/include/kerberosV -c /usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/plugins/otp.c -fPIC -DPIC -o .libs/otp.lo /usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/plugins/otp.c:59: invalid preprocessing directive name /usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/plugins/otp.c:61: invalid preprocessing directive name *** Error code 1 Stop in /usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/build-i386/plugins. Adding the version check back fixes this problem. --- plugins/otp.c.orig Tue Dec 10 01:33:54 2002 +++ plugins/otp.c Tue Dec 10 01:39:44 2002 @@ -56,7 +56,9 @@ #include openssl/evp.h #include sasl.h +#if OPENSSL_VERSION_NUMBER 0x00907000L #define MD5_H /* suppress internal MD5 */ +#endif #include saslplug.h #include plugin_common.h - -Rob - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 Comment: Made with pgp4pine 1.76 iQA/AwUBPfTJjGes8cJc4y/MEQJkTACgrxUwOCBvIJ5uC8piWb89gMdPfJwAoJ37 uFcGZ9shhlkmhQ3aPSLYcUD9 =0UJK -END PGP SIGNATURE- -- Med venlig hilsen / Kind regards Hack Kampbjørn
Re: How to use non-ascii charsets with sieve?
Hi Larry,
(B
(BWe are considering a modification like this to fill_cache(message_data_t *)
(Bin cyrus-imapd-2.1.11/sieve/test.c
(B
(B%%SNIP%%
(Bvoid fill_cache(message_data_t *m)
(B{
(Brewind(m-data);
(B
(B/* let's fill that header cache */
(Bfor (;;) {
(Bchar *name, *body;
(Bint cl, clinit;
(B
(Bif (parseheader(m-data, name, body) 0) {
(Bbreak;
(B}
(B
(B#ifdef DECODE_SUBJECT
(B/* decode mime encoded subjects */
(Bif( name * name ! strcmp( name, "subject" )
(B body * body strstr( body, "=?" ))
(B{
(Bchar * de = charset_decode1522( body, NULL, 0 ) ;
(Bif( decoded * decoded )
(B{
(Bfree( body ) ;
(Bbody = decoded ;
(B}
(B}
(B#endif /* DECODE_SUBJECT */
(B
(B%%SNIP%%
(B
(BThis hasn't been tested this yet since I stuck it in yesterday before
(Bgoing home and have just returned to the office. It should decode subjects
(Binto utf8. But it may have "interesting" unintended side-effects. So far
(Bwe are only interested in decoded subjects. But decoding the comment part
(Bof addresses also has a high probability of being desired. Depends on the
(Bfeed-back we get from users.
(B
(BWill charset_decode1522( ) strip the whitespace?
(BSomeone else found the function and I have only given it the most cursory
(Bglance over.
(B
(BOn Mon, 9 Dec 2002 15:59:38 -0500, Lawrence Greenfield [EMAIL PROTECTED] wrote...
(B You bring up good questions.
(B
(B First, our Sieve implementation currently doesn't deal with RFC 2047
(B encoded headers---or rather, it just compares the undecoded headers
(B against the UTF-8 string. This is obviously a bug which sadly isn't in
(B bugzilla.
(B
(B Ken and I talked (a long time ago) about this. The main issue is that
(B Cyrus's character comparison routines remove whitespace and always
(B perform casemapping, and this is probably inappropriate for Sieve's
(B use. Fixing this is probably not difficult, but I'd prefer not to have
(B multiple different canonicalization tables.
(B
(B The "fileinto" problem is more straightforward and should be fixed in
(B lmtpd.c:sieve_fileinto().
(B
(B I would add a function to mboxname.[ch] of mboxname_utf8tomutf7() and
(B then make sieve_fileinto() call it.
(B
(B Larry
(B
(BThank You! This is very NICE as I hadn't gotten far enough along to look
(Bat this yet. The obvious work around (ugly hack) for fileinto is to have
(Bthe client do the mutf-7 conversion before submitting the script. We're
(Bworking on the client so such a hack isn't out of the question; but probably
(Bwont work well if some other client were to access the server.
(B
(B
(BDate: Mon, 9 Dec 2002 19:53:37 +0900 (JST)
(BFrom: Mark Keasling [EMAIL PROTECTED]
(B [...]
(Bscript language="sieve" version="RFC-3028"
(B # pretend this is encoded in UTF-8
(B
(B require ["reject","fileinto"];
(B
(B if header :contains "Subject" "$B%;%_%J!
Re: How to use non-ascii charsets with sieve?
--On Monday, December 09, 2002 6:01 PM -0800 Tim Showalter [EMAIL PROTECTED] wrote: different comparators would require different tables, I think. The table Cyrus usually uses isn't suitable for i;ascii-casemap since space isn't significant, but transcoding to UTF-8 and doing a dumb comparison is all that's required, a big improvement on what Cyrus is doing now, and not hard to implement. Yes, unlike the IMAP SEARCH command the Sieve comparators have strict semantics. I believe it's possible to implement the Sieve comparators and Cyrus's current SEARCH comparator with a single table. The table would transcode into UTF-8 (fully decomposed) and the SEARCH comparator could do the modifications needed. Larry
Re: using Murder for migration from UW IMAP
Quoting Jeremy Rumpf [EMAIL PROTECTED]: You might also want to consider using the perdition IMAP/Pop3 proxy. It's well suited for something like this since it can use LDAP, MySQL, PostreSQL, and local GDBM databases to lookup the real server for users. http://www.vergenet.net/linux/perdition/ Thanks for the pointer. Do you have a suggestion for an LMTP proxy that might use the same back-end database? -- John A. Tamplin Unix System Administrator
Re: OPENSSL_VERSION_NUMBER (Was: Cyrus SASL 2.1.10 Released)
OK. I now have two conflicting reports regarding testing for OPENSSL_VERSION_NUMBER with OpenSSL 0.9.7 (both quoted below). Could somebody who has 0.9.7 installed please try to figure out what the deal is? I tend to believe that I was originally correct in including the check, and I'm confused as to why it doesn't work for Peter using the same release as Hack. Ken Hack Kampbjorn wrote: More problems: with cyrus-sasl version 2.1.9 plugins/otp.c only defined MD5_H for OpenSSL versions 0.9.7 but in version 2.1.10 the check is removed. OpenBSD 3.2 ships with OpenSSL 0.9.7-beta3 30 Jul 2000 (0x00907003L) and fails with this error: /bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -I. -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/plugins -I.. -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/include -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/lib -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/sasldb -I/usr/local/include -I/usr/include/kerberosIV -I/usr/include/kerberosV -I/usr/include -Wall -W -Wall -O2 -I/usr/include/kerberosV -c /usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/plugins/otp.c rm -f .libs/otp.lo cc -DHAVE_CONFIG_H -I. -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/plugins -I.. -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/include -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/lib -I/usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/sasldb -I/usr/local/include -I/usr/include/kerberosIV -I/usr/include/kerberosV -I/usr/include -Wall -W -Wall -O2 -I/usr/include/kerberosV -c /usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/plugins/otp.c -fPIC -DPIC -o .libs/otp.lo /usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/plugins/otp.c:59: invalid preprocessing directive name /usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/cyrus-sasl-2.1.10/plugins/otp.c:61: invalid preprocessing directive name *** Error code 1 Stop in /usr/ports/security/cyrus-sasl2/w-cyrus-sasl-2.1.10/build-i386/plugins. Adding the version check back fixes this problem. --- plugins/otp.c.orig Tue Dec 10 01:33:54 2002 +++ plugins/otp.c Tue Dec 10 01:39:44 2002 @@ -56,7 +56,9 @@ #include openssl/evp.h #include sasl.h +#if OPENSSL_VERSION_NUMBER 0x00907000L #define MD5_H /* suppress internal MD5 */ +#endif #include saslplug.h #include plugin_common.h Peter 'Luna' Runestig wrote: Hi all! What's the deal with this part in plugins/otp.c (2.1.8): #if OPENSSL_VERSION_NUMBER 0x00907000L #define MD5_H /* suppress internal MD5 */ #endif As it stands, the code doesn't compile with openssl-0.9.7-beta3 (if I remove the version check, it does). Do you expect MD5 support to be dropped in future versions of openssl, or what? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: Different type of message store
HI, On Monday, December 9, 2002, at 04:58 PM, Rob Siemborski wrote: On Sun, 8 Dec 2002, Rob Mueller wrote: Has there been any thought in spending some time cleaning up the code to try and stop these assumptions all over the place and create some better abstractions? Clearly cyrus has been a project that's evolved over time, and the code is where it is now because of the evolution over time, but some time spent fixing old assumptions and some old programming practices would certainly help with the speediness and correctness of future coding? Its something we're not adverse too, but don't have specific plans to spend time on. I know for one I've been wanting to clean up the mboxlist API, which really took a beating during the murder development. (Though, its probably the most separate part of the API at the current point). Just curious. I am looking into this for our IMAP service and I am interested in this (I started the thread). Maybe I can contribute parts of code (depends a bit on our internal way forward) and therefor I would like to know how you 'vyrus-developers/maintainers' see this. You have CVS access or prefer to have just patches, Harrie Software developer, Technical Department
