Re: OPENSSL_VERSION_NUMBER (Was: Cyrus SASL 2.1.10 Released)
Ken Murchison wrote: 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, Back to my original question then: why? Why treat OpenSSL version 0.9.7 and above different than the previous versions? Is there any change in the MD5 code between those versions (I don't think so, not anything that affects this issue anyway)? Anyway, here's what happens to me, if 'MD5_H' isn't defined: $ ./configure --with-openssl=/usr/local [tweak the Makefiles to make Kerberos somewhat compile (RH 7.2)] [snip a lot of other output] /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/kerberos/include -I/usr/kerberos/include/kerberosIV -I../include -I../lib -I../sasldb -I/usr/local/include -I/usr/local/include -Wall -W -Wall -g -O2 -c otp.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/kerberos/include -I/usr/kerberos/include/kerberosIV -I../include -I../lib -I../sasldb -I/usr/local/include -I/usr/local/include -Wall -W -Wall -g -O2 -c otp.c -fPIC -DPIC -o otp.lo In file included from ../include/saslplug.h:11, from otp.c:60: ../include/md5.h:30: conflicting types for `MD5_CTX' /usr/local/include/openssl/md5.h:103: previous declaration of `MD5_CTX' make[2]: *** [otp.lo] Error 1 Yes, the name 'MD5_CTX' is used in both OpenSSL and SASL native MD5, so that clash was sure to come. and I'm confused as to why it doesn't work for Peter using the same release as Hack. So am I! But I have another remark further down here: 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 What kind of an error is that? Is the macro 'MD5_H' used elswhere in OpenBSD? Unfortunately, I don't have a OBSD 3.2 around to test on... /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? Cheers, - Peter -- Peter 'Luna' Runestig (fd. Altberg), Sweden [EMAIL PROTECTED] PGP Key ID: 0xD07BBE13 Fingerprint: 7B5C 1F48 2997 C061 DE4B 42EA CB99 A35C D07B BE13 AOL Instant Messenger Screen name: PRunestig
³¬Î¢MBAºËÐĿγÌÖ¤Êé°à£¨µÚ¶þÆÚ£©
¹á³¹ÊµÓÃʵЧƷÖÊ ¼á³ÖѧÒÔÖÂÓÃÔÔò¡ª¡ª ³¬Î¢MBAºËÐĿγÌÖ¤Êé°à£¨µÚ¶þÆÚ£© ¿Î³Ì°²ÅÅ£º 1¡¢Î´¶¯¶øÏÈı¡ª¡ªÖªÊ¶¾¼Ãʱ´úµÄ¹ÜÀí˼ά 2¡¢Ã»ÓÐ×îºÃ £¬Ö»ÓÐÊÊÓ᪡ªÏÖ´úÈËÁ¦×ÊÔ´¹ÜÀí 3¡¢´´ÐÂΪ»ê¡ª¡ªÓªÏú¹ÜÀíÓ봴оӪ ¡ïÖ÷°ìµ¥Î»£ºÑÇÌ«ÊÀ¼ÍÖ°Òµ¾ÀíÈËÅàѵÖÐÐÄ ¡ïÅàѵʱ¼ä£º12ÔÂ20ÈÕ¡ª¡ª22ÈÕ£¨¹²ÈýÌ죩 ¡ïÅàѵµØµã£º±±¾©¡¤±±¾©´óѧ ¡ï¿Î³ÌÊÕ·Ñ£º1980Ôª/ÈË£¨º¬Åàѵ¡¢×ÊÁÏ¡¢Ö¤Ê顢ר¼Ò·Ñ¡¢Îç²Í·Ñ£© ¡ïסËÞ°²ÅÅ£ºÐÖú°²ÅÅÔÚ±±¾©´óѧ¸½½üסËÞ£¬·ÑÓÃ×ÔÀí¡£ ¡ïʦ×ÊÁ¦Á¿£ºÌ¨Í岩ʿ£»±±´ó½²Ê¦£»¹úÄÚʵս¹ÜÀíר¼Ò¡£ ¡ï²Î»á¶ÔÏ󣺶ʳ¤¡¢×ܾÀí£»ÏúÊÛ¡¢ÈËÁ¦×ÊÔ´µÈÖи߲ã¹ÜÀíÕߣ¬Ö°Òµ¾ÀíÈË£» ¡ï½áÒµÖ¤Ê飺½áÒµ°ä·¢½áÒµÖ¤Êé¡£ ¡ï×Éѯµç»°£º010¡ª 82057871ת84ÎâÀÏʦ 82057871ת87 ÌïÀÏʦ £¨Çë²»ÒªÖ±½Ó»Ø¸´±¾Óʼþ£© È˲»¿ÉÄÜÔÚÒ»ÌìÄÚ³ÉΪ¹ÜÀí´óʦ£¬ µ«¿ÉÒÔÓôóʦµÄÑÛ¹âÈ¥¿´´ýÎÊÌ⣻ È˲»¿ÉÄÜÔÚÒ»ÌìÄÚ³ÉΪMBA£¬ µ«¿ÉÒÔÓÃMBAµÄÊÓ½ÇÈ¥½â¾öÎÊÌâ¡£ --- Èç¹ûÕâ·âÓʼþ´òÈÅÄúÁË£¬·³ÇëËæÊÖɾµô£¬²¢Çë¼ûÁ¡£ ÈôÄú²»Ï£ÍûÔÙ´ÎÊÕµ½ÎÒÃǵÄÓʼþ£¬·³Çë·ÃÎÊÒÔÏÂÍøÖ·£º http://mailt.59i.net/DB_Agents/user_cancel.asp?id=596language=gb2312
Re: Moving the cyrus mail store (var/lib/imap, var/spool/imap)
Joe Hrbek schrieb: I was wondering if there is an easy way to move the cyrus mail store to a new server. I tried moving it simply by tarring the /var/lib/imap directory and /var/spool/imap but that didn't seem to work. Of course, I had the mta shutoff as well as cyrus-imapd prior to this operation. Seems absolutely correct to me. I installed cyrus-imapd on the new server with the same RPMs I used on the current system and then extracted the tar files on the new server in the same location they were on the old one. I started cyrus-imapd and it check Maybe stupid question but worth to ask: did you check permissions and ownership of the directories after extracting? pointed the databases (I'm using simon matters RPMS, 2.1.10 I think). All appears to work, but after about 5 or 6 deliveries by the MTA, the cyrus Deliver program begins to hang. In addition, if I switch to LMTP instead of using cyrus deliver (I use postfix as an mta btw), those processes will begin to hang just as quickly as the deliver program did. Did you install the RPMs on the same RedHat release? If not, I _strongly_ suggest rebuilding the source RPM and then installing the newly built binaries. HTH Simon Obviously something isn't right. I tend to believe that it is because of the way I moved the spool and the *.db files. Could someone tell me, or point me to a document that explains how to move a cyrus system to a new machine? I looked through the docs, but I can't seem to find any such information. Additionally, when will the reconstruct -m command become available again? I as able to find one pseudo how-to, not very in-depth, actually just a newsgroup article that said, if you have problems with a database, run reconstruct -m and it should fix everything. Any help would be appreciated, -Joe
Re: How to use non-ascii charsets with sieve?
Hi, On Mon, 09 Dec 2002 22:17:06 -0500, Lawrence Greenfield [EMAIL PROTECTED] wrote... --On Tuesday, December 10, 2002 11:52 AM +0900 Mark Keasling [EMAIL PROTECTED] wrote: Hi Larry, [ ... decode in fill_cache() ... ] This hasn't been tested this yet since I stuck it in yesterday before going home and have just returned to the office. It should decode subjects into utf8. But it may have interesting unintended side-effects. So far we are only interested in decoded subjects. But decoding the comment part of addresses also has a high probability of being desired. Depends on the feed-back we get from users. Will charset_decode1522( ) strip the whitespace? Yes, the output of charset_decode1522() is intended to be fed into the Cyrus IMAP SEARCH algorithm, which ignores whitespace. It also does case folding, preventing i;octet searches from working. charset_decode1522() would work if it was using a different transcoding table than what is generated in the lib/ directory. I'm in the process of trying to figure out how this stuff works... Is it possible to separate the charset to utf-8 conversion from the text to search data transformation? Regards, Mark Keasling [EMAIL PROTECTED]
Re: Question: How to specify path to saslauthd mux socket inimapd.conf?
On Mon, 9 Dec 2002, Kevin M. Myer wrote: 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 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 :) What you're describing sounds almost like a solution to a problem I'm grappling with, but I suspect not quite - any suggestions on the Right Way to proceed here would be welcomed: I'm upgrading an inherited 1.5.19 installation to 2.1.11, but have to cope with some local authentication madness. For historical reasons we authenticate to different LDAP servers depending upon the usercode (staff and students), and the 1.5 code has been horribly hacked to support this. Taking the LDAP madness as read, it sounds like the way to solve this in Cyrus is to go to impad-2_2 in CVS and use named virtual domains, with users logging in as user@staff or user@student. Alas, that's not a realistic short-term option for me (as a Cyrus newbie I'd rather stay away from CVS, and the upgrade has to be invisible to users wherever possible). So what I've been considering is applying a similar patch to saslauthd/lak.c to choose an LDAP config based on the usercode. Obviously I'd prefer not to mutilate the code if I could avoid it - if I instead ran two saslauthd instances with their own configs, is there a way to make imapd 2.1 dynamically choose a socket based on some per-user property? (This property needn't be the usercode - for example, we keep staff and students in separate partitions.) Like I said, any advice would be gratefully received! 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? Following up on Rob's list, my tests show that Outlook 2000, Pine 4.44 and Mozillia 1.0.1 complain about self-signed certs but let you use them. Eudora 5.2 is more interesting: they've fixed the broken STARTTLS support that plagued 5.0/5.1 so that it really does start TLSv1 on port 143 (their IMAPS (port 993) support is for TLSv1 with an SSLv2 hello). However, it will fail the connection if you're using a self-signed cert, and Qualcomm support doc 2323HQ tells you to go into Certificate Manager and add the cert to your trusted list. Which is all nice and sensible, except that running it in Light mode you have to open the Last SSL Info dialog to get to Cert Manager, and you can't open that dialog until you've had a successful SSL connection. Hmm... -- Simon Brady mailto:[EMAIL PROTECTED] ITS Technical Services University of Otago, Dunedin, New Zealand
Re: OPENSSL_VERSION_NUMBER (Was: Cyrus SASL 2.1.10 Released)
Peter 'Luna' Runestig wrote: Unfortunately, I don't have a OBSD 3.2 around to test on... I have done some tests on OBSD 3.1, and it behaves the same as my RH 7.2 system. Tested both with OBSD 3.1 native OpenSSL 0.9.6b [engine], and with 0.9.7-beta3 (built on the system using OpenSSL's code distribution). As is, SASL 2.1.10 compiles fine (well, past plugins/otp.c anyway, then it breaks on Kerberos). If you remove the #define MD5_H it goes: /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../lib -I../sasldb -I/usr/local/include -I/home/luna/openssl-097b3//include -Wall -W -Wall -g -O2 -c otp.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../lib -I../sasldb -I/usr/local/include -I/home/luna/openssl-097b3//include -Wall -W -Wall -g -O2 -c otp.c -fPIC -DPIC -o otp.lo In file included from ../include/saslplug.h:11, from otp.c:60: ../include/md5.h:30: conflicting types for `MD5_CTX' /home/luna/openssl-097b3/include/openssl/md5.h:103: previous declaration of `MD5_CTX' Cheers, - Peter -- Peter 'Luna' Runestig (fd. Altberg), Sweden [EMAIL PROTECTED] PGP Key ID: 0xD07BBE13 Fingerprint: 7B5C 1F48 2997 C061 DE4B 42EA CB99 A35C D07B BE13 AOL Instant Messenger Screen name: PRunestig
Re: OPENSSL_VERSION_NUMBER (Was: Cyrus SASL 2.1.10 Released)
Oops! I pulled the wrong SASL address out of my address book. Please do not send any more replies to ietf-sasl. Ken Peter 'Luna' Runestig wrote: Ken Murchison wrote: 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, Back to my original question then: why? Why treat OpenSSL version 0.9.7 and above different than the previous versions? Is there any change in the MD5 code between those versions (I don't think so, not anything that affects this issue anyway)? Anyway, here's what happens to me, if 'MD5_H' isn't defined: $ ./configure --with-openssl=/usr/local [tweak the Makefiles to make Kerberos somewhat compile (RH 7.2)] [snip a lot of other output] /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/kerberos/include -I/usr/kerberos/include/kerberosIV -I../include -I../lib -I../sasldb -I/usr/local/include -I/usr/local/include -Wall -W -Wall -g -O2 -c otp.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/kerberos/include -I/usr/kerberos/include/kerberosIV -I../include -I../lib -I../sasldb -I/usr/local/include -I/usr/local/include -Wall -W -Wall -g -O2 -c otp.c -fPIC -DPIC -o otp.lo In file included from ../include/saslplug.h:11, from otp.c:60: ../include/md5.h:30: conflicting types for `MD5_CTX' /usr/local/include/openssl/md5.h:103: previous declaration of `MD5_CTX' make[2]: *** [otp.lo] Error 1 Yes, the name 'MD5_CTX' is used in both OpenSSL and SASL native MD5, so that clash was sure to come. and I'm confused as to why it doesn't work for Peter using the same release as Hack. So am I! But I have another remark further down here: 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 What kind of an error is that? Is the macro 'MD5_H' used elswhere in OpenBSD? Unfortunately, I don't have a OBSD 3.2 around to test on... /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? Cheers, - Peter -- Peter 'Luna' Runestig (fd. Altberg), Sweden [EMAIL PROTECTED] PGP Key ID: 0xD07BBE13 Fingerprint: 7B5C 1F48 2997 C061 DE4B 42EA CB99 A35C D07B BE13 AOL Instant Messenger Screen name: PRunestig -- Kenneth
Re: How to use non-ascii charsets with sieve?
I dug up the patch I have for creating a separate Sieve charset table. I have no idea if it will still apply cleanly due to its age, but it should point you at the places to look in the code. If you can find a way to make one unified table as Larry suggests, that would be great. Mark Keasling wrote: Hi, On Mon, 09 Dec 2002 22:17:06 -0500, Lawrence Greenfield [EMAIL PROTECTED] wrote... --On Tuesday, December 10, 2002 11:52 AM +0900 Mark Keasling [EMAIL PROTECTED] wrote: Hi Larry, [ ... decode in fill_cache() ... ] This hasn't been tested this yet since I stuck it in yesterday before going home and have just returned to the office. It should decode subjects into utf8. But it may have interesting unintended side-effects. So far we are only interested in decoded subjects. But decoding the comment part of addresses also has a high probability of being desired. Depends on the feed-back we get from users. Will charset_decode1522( ) strip the whitespace? Yes, the output of charset_decode1522() is intended to be fed into the Cyrus IMAP SEARCH algorithm, which ignores whitespace. It also does case folding, preventing i;octet searches from working. charset_decode1522() would work if it was using a different transcoding table than what is generated in the lib/ directory. I'm in the process of trying to figure out how this stuff works... Is it possible to separate the charset to utf-8 conversion from the text to search data transformation? Regards, Mark Keasling [EMAIL PROTECTED] -- 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 sieve-mime.patch.gz Description: GNU Zip compressed data
Re: OPENSSL_VERSION_NUMBER (Was: Cyrus SASL 2.1.10 Released)
On Tuesday 10 December 2002 15:16, Ken Murchison wrote: Oops! I pulled the wrong SASL address out of my address book. Please do not send any more replies to ietf-sasl. Ken Peter 'Luna' Runestig wrote: Ken Murchison wrote: 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, I think i've tracked this now. The two first OpenSSL 0.9.7 betas had removed the inclusion of all the other headers in openssl/evp.h this was reverted for beta 3. But the OpenBSD folk didn't like it so they removed the inclusion again. http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/evp/evp.h So we have that for OpenSSL versions 0.9.7 the openssl.evp.h also includes openssl/md5.h as it does for betas =3 (but not on OpenBSD). As otp.c wanted to use the openssl MD5 file and not the sasl's internal my previous patch was wrong. Just explicitly including openssl/md5.h seems a better solution as that's what we want. Possibly including this file twice shouldn't break anything. --- otp.c.orig Mon Oct 14 21:39:43 2002 +++ otp.c Tue Dec 10 16:31:36 2002 @@ -54,6 +54,7 @@ #include assert.h #include openssl/evp.h +#include openssl/md5.h #include sasl.h #define MD5_H /* suppress internal MD5 */
Re: OPENSSL_VERSION_NUMBER (Was: Cyrus SASL 2.1.10 Released)
Hack Kampbjørn wrote: On Tuesday 10 December 2002 15:16, Ken Murchison wrote: Oops! I pulled the wrong SASL address out of my address book. Please do not send any more replies to ietf-sasl. Ken Peter 'Luna' Runestig wrote: Ken Murchison wrote: 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, I think i've tracked this now. The two first OpenSSL 0.9.7 betas had removed the inclusion of all the other headers in openssl/evp.h this was reverted for beta 3. But the OpenBSD folk didn't like it so they removed the inclusion again. http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/evp/evp.h So we have that for OpenSSL versions 0.9.7 the openssl.evp.h also includes openssl/md5.h as it does for betas =3 (but not on OpenBSD). As otp.c IIRC, the md5.h header was included in either beta1 or pre-beta code, since I added it for a reason when I first tested against 0.9.7. wanted to use the openssl MD5 file and not the sasl's internal my previous patch was wrong. Just explicitly including openssl/md5.h seems a better solution as that's what we want. Possibly including this file twice shouldn't break anything. --- otp.c.orig Mon Oct 14 21:39:43 2002 +++ otp.c Tue Dec 10 16:31:36 2002 @@ -54,6 +54,7 @@ #include assert.h #include openssl/evp.h +#include openssl/md5.h #include sasl.h #define MD5_H /* suppress internal MD5 */ This is crazy! Since EVP is an interface to ALL digests and ciphers, shouldn't it include the headers for everything that it encapsulates? And what's the deal with OpenBSD deciding to make their header non-standard? Stuff like this makes me want to say that 0.9.7 and BSD aren't supported. Of course, this isn't my call, and its unrealistic anyway. Ken -- 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: OPENSSL_VERSION_NUMBER (Was: Cyrus SASL 2.1.10 Released)
Hack Kampbjørn wrote: On Tuesday 10 December 2002 15:16, Ken Murchison wrote: Oops! I pulled the wrong SASL address out of my address book. Please do not send any more replies to ietf-sasl. Ken Peter 'Luna' Runestig wrote: Ken Murchison wrote: 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, I think i've tracked this now. The two first OpenSSL 0.9.7 betas had removed the inclusion of all the other headers in openssl/evp.h this was reverted for beta 3. But the OpenBSD folk didn't like it so they removed the inclusion again. http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/evp/evp.h So we have that for OpenSSL versions 0.9.7 the openssl.evp.h also includes openssl/md5.h as it does for betas =3 (but not on OpenBSD). As otp.c wanted to use the openssl MD5 file and not the sasl's internal my previous patch was wrong. Just explicitly including openssl/md5.h seems a better solution as that's what we want. Possibly including this file twice shouldn't break anything. --- otp.c.orig Mon Oct 14 21:39:43 2002 +++ otp.c Tue Dec 10 16:31:36 2002 @@ -54,6 +54,7 @@ #include assert.h #include openssl/evp.h +#include openssl/md5.h #include sasl.h #define MD5_H /* suppress internal MD5 */ So, if Peter can confirm that this works for him (both including openssl/md5.h and _always_ defining MD5_H), then I'll go ahead commit this to CVS. -- 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: using Murder for migration from UW IMAP
On Monday 09 December 2002 23:10 pm, John A. Tamplin wrote: 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? Not off hand, you can use Postfix's transport maps to kind of fake being an LMTP proxy. That would require you to put another MTA hop in the mix, or replace your boarder MTAs with postfix. I'm not sure how your layout is, but postfix + LDAP can do some pretty nifty things when it comes to mail routing (I'm sure other MTAs can as well, but I'm mostly fluent with postfix). From postfix's perspective, one address could be delivered via LMTP to a Cyrus mail backend, while another address can be SMTP delievered to another MTA running on a UW IMAP backend. Routing can be switched on the fly by updating the LDAP entry. I kind of describe what I'm talking about in this post: http://asg.web.cmu.edu/archive/message.php?mailbox=archive.info-cyrussearchterm=perditionmsg=17997 I have plans to wrap this up into a more formal howto, but haven't found the time yet. If you have any other questions/ideas, feel free to ask. Cheers, Jeremy
Sieve filtering -- set filter as Cyrus administrator
Hi, I wonder, is there is way to login into Tim sieved or sieve shell as cyurs (administrator), and set the filter for the normal users? The Tim sieved doesn't seem to have a command to specify the mailbox name, after logged in. Does Sieve have some thing like ACL, to allow other user to set the filter for the mailbox? Thanks a lot for your help. Su Li Research In Motion (519)888-7465 ext 3041
Re: Sieve filtering -- set filter as Cyrus administrator
On Tue, 10 Dec 2002, Su Li wrote: I wonder, is there is way to login into Tim sieved or sieve shell as cyurs (administrator), and set the filter for the normal users? Yes. sieveshell --authname=cyrus --user=the user you want -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
RE: Sieve filtering -- set filter as Cyrus administrator
On Tue, 10 Dec 2002, Su Li wrote: Thanks Rob for you quick reply. It works on sieveshell. Do you by chance know, if I telnet to Timsieved (port 2000), what command should I user to do --user=testuser1 --authname=cyrus? Right now, when I log in Tim sieved, I do: c: AUTHENTICATE LOGIN s: VXNlcm5hbWU6-- user c: username (in base 64) s: UGFzc3dvcmQ6-- password c: password (in base 64) s: OK I don't know how do I login as authname and set the filter for normal user. You need to use a SASL mech that supports authorization, like PLAIN, which I suspect will be difficult for you using telnet. sivtest should be able to do it for you though. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
RE: Sieve filtering -- set filter as Cyrus administrator
Thanks Rob for you quick reply. It works on sieveshell. Do you by chance know, if I telnet to Timsieved (port 2000), what command should I user to do --user=testuser1 --authname=cyrus? Right now, when I log in Tim sieved, I do: c: AUTHENTICATE LOGIN s: VXNlcm5hbWU6-- user c: username (in base 64) s: UGFzc3dvcmQ6-- password c: password (in base 64) s: OK I don't know how do I login as authname and set the filter for normal user. Thanks, Su -Original Message- From: Rob Siemborski [mailto:[EMAIL PROTECTED]] Sent: December 10, 2002 12:19 PM To: Su Li Cc: [EMAIL PROTECTED] Subject: Re: Sieve filtering -- set filter as Cyrus administrator On Tue, 10 Dec 2002, Su Li wrote: I wonder, is there is way to login into Tim sieved or sieve shell as cyurs (administrator), and set the filter for the normal users? Yes. sieveshell --authname=cyrus --user=the user you want -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: OPENSSL_VERSION_NUMBER (Was: Cyrus SASL 2.1.10 Released)
Ken Murchison wrote: --- otp.c.orig Mon Oct 14 21:39:43 2002 +++ otp.c Tue Dec 10 16:31:36 2002 @@ -54,6 +54,7 @@ #include assert.h #include openssl/evp.h +#include openssl/md5.h #include sasl.h #define MD5_H /* suppress internal MD5 */ So, if Peter can confirm that this works for him (both including openssl/md5.h and _always_ defining MD5_H), then I'll go ahead commit this to CVS. Works fine over here! Cheers, - Peter -- Peter 'Luna' Runestig (fd. Altberg), Sweden [EMAIL PROTECTED] PGP Key ID: 0xD07BBE13 Fingerprint: 7B5C 1F48 2997 C061 DE4B 42EA CB99 A35C D07B BE13 AOL Instant Messenger Screen name: PRunestig
Re: How to use non-ascii charsets with sieve?
Date: Tue, 10 Dec 2002 19:07:55 +0900 (JST) From: Mark Keasling [EMAIL PROTECTED] [...] I'm in the process of trying to figure out how this stuff works... Is it possible to separate the charset to utf-8 conversion from the text to search data transformation? It would be technically possible. It's probably not the easiest thing to do in the Cyrus code base. Currently mkchartable.c does casemapping, character decomposition, and whitespace elimination. It also applies some mappings (charset/unifix.txt) that help with a language independant match but may not be appropriate for collation or all UTF-8 comparators. To make the chartable stuff work for Sieve our current SEARCH, we probably should build tables that just output decomposed (or fully composed) UTF-8 characters. We can then write a UTF-8 comparator library that, during comparison, does the canonicalization. The easier path to make Sieve work would be to just build two completely seperate tables. I'd prefer to see the more general solution. While none of this is rocket science, it is heavily detailed oriented and requires concentration. Larry
files in stage. directory ...
What are they, and how do you clean them out? I have stuff dating back to march 19th in there: Mar 19 2002 27181-1016554210 just delete, or is there somethign I should be fixing?
New Berkeley DB Configuration Methods
I just committed some changes to the Berkeley DB configuration subsystem to the Cyrus 2.1 branch of CVS. If some of the people who generally have Berkeley DB troubles with Cyrus could test it out and let me know, that'd be great. It should be much closer to how SASL works now, which while not perfect is probably better. (it has --with-bdb-libdir and --with-bdb-incdir options). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * [EMAIL PROTECTED] * 412.268.7456 -BEGIN GEEK CODE BLOCK Version: 3.12 GCS/IT/CM/PA d- s+: a-- C$ ULS$ P+++$ L+++() E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e h r- y? --END GEEK CODE BLOCK-
Re: using Murder for migration from UW IMAP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Content-Type: text/plain; charset=us-ascii In message [EMAIL PROTECTED], John A. Tamplin writ es: Quoting Rob Siemborski [EMAIL PROTECTED]: 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. Have you considered just doing a direct mailbox conversion? You can convert directly to Cyrus mailboxes and then reconstruct everything. That might be faster than dealing with the mbxcvt code. - -- Ted Cabeen http://www.pobox.com/~secabeen[EMAIL PROTECTED] Check Website or Keyserver for PGP/GPG Key BA0349D2 [EMAIL PROTECTED] I have taken all knowledge to be my province. -F. Bacon [EMAIL PROTECTED] Human kind cannot bear very much reality.-T.S.Eliot[EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) Comment: Exmh version 2.5 07/13/2001 iD8DBQE99lFSoayJfLoDSdIRAp5iAKDJGxcgRfjU6k1QI3zWkIzKrOcVRQCeIKBP IqjyY9I+VrxVbx3pkHu8DiU= =dvwG -END PGP SIGNATURE-
Re: using Murder for migration from UW IMAP
Ted Cabeen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Content-Type: text/plain; charset=us-ascii In message [EMAIL PROTECTED], John A. Tamplin writ es: Quoting Rob Siemborski [EMAIL PROTECTED]: 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. Have you considered just doing a direct mailbox conversion? You can convert directly to Cyrus mailboxes and then reconstruct everything. That might be faster than dealing with the mbxcvt code. I need to get the flags and seen state transferred as well -- that wouldn't do it, right? It is important that the transition be as seemless as possible. Having to rename a few mailboxes that UW IMAP allows but Cyrus doesn't is enough hassle to the users. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
Backing up db directory
Am I correct in assuming that the db directory doesn't need to be backed up - in fact should not be backed up - and I should instead be backing up the db.backup1 and db.backup2 dirs and using reconstruct to recreate db itself? Jay Levitt
sieve and unixhierarchysep
I've been using websieve for a small mail server and have been quite happy with it. However I've now run into an issue with what appears to be sieve and unixhierarchysep not wanting to play nice together. For users with . 's in there username everything works fine. For users with . 's in there username imap works fine, but auth against sieve fails. I've emailed the author of websieve thinking that this may be an issue with just that software, but I'm now suspect that sieve itself doesn't want to play with usernames that have . 's in them. Does anyone have sure fire way that I can test this directly against sieve? Has anyone had any luck with websieve and . 's in usernames? Thanks. -Joseph
how to rebuiild mailboxes.db ?
hello, I got my mailboxes.db mangled because of a file system problem. I cannot even delete or modify quota of some accounts anymore, it tells me mailbox format is invalid. How can I rebuild the whole mailboxes.db file? is it possible to fix mailboxes.db ? thanks Rick
Sieve works but vacation / reply messages do not.
Greetings! Setup: FreeBSD 4.7-STABLE - Postfix 1.1.11,1 /Cyrus 2.1.9 I think I'm really close on this one but don't know where to go next...I have working rules as far as move to this folder and discard silently and such go.. But vacation messaging isn't working as it should. Here's what happens... I set up a rule that says if my email [EMAIL PROTECTED] sends a message to my other address, [EMAIL PROTECTED] then reply with a vacation message.. I send a message to the [EMAIL PROTECTED] address and jks2 gets it, but jks never gets the reply. Here's what's in my syslogs: Dec 10 19:38:57 courier postfix/qmgr[10185]: 0229C55853: from=[EMAIL PROTECTED], size=12000, nrcpt=1 (queue active) Dec 10 19:38:57 courier postfix/pipe[12416]: 0229C55853: to=[EMAIL PROTECTED], relay=cyrus, delay=0, status=sent (mx1.clickcom.com) Mx1 is the real hostname. Clickcom addresses are all in the virtual users table. I would guess my problem is that it's replying to the translated email address instead of back to the original sending address. Or maybe it's cause the pipe isn't working, but I don't see any error messages regarding that.. Thoughts, ideas of where I should look next?? John Straiton [EMAIL PROTECTED] Clickcom, Inc 704-365-9970x101
Unexpected lmtpproxy response
Every now and then, we see the following error in our logs: Dec 6 22:29:20 www postfix/lmtp[15516]: 7319A58B2: to=xyz, relay=/var/imap/socket/lmtpprox[/var/imap/socket/lmtpprox], delay=218, status=bounced (host /var/imap/socket/lmtpprox[/var/imap/socket/lmtpprox] said: 250 2.1.5 ok (in reply to DATA command)) We're currently using a hacked version of the lmtpproxyd.c to do proxied delivery to our separate IMAP servers. The code is basically the same, though we've replaced the mupdate lookup stuff with our own hostname lookups. There are a few specifics that seem to trigger it: 1. We're using a unix socket. If we change to an inet one with an internal IP address, the problem doesn't seem to occur 2. The load of the destination lmtp server is quite high We're running linux, so I'm not sure if it's a linux bug, some race condition in the proxy or kernel, or anything else for that matter. Odd. Just thought I'd check if anyone else has seen it or knows a work around. Rob
Broken Pipe ?
I made and installed db-4.1.24, cyrus-sasl-2.1.9 and cyrus-imapd-2.1.10. All the things seem all right. Ater I had configured /etc/imapd.conf, /etc/inetd.conf, /var/imap... I started /usr/cyrus/bin/master, and it did run. Then I connected to 143 port of the server, but this time it failed. Then I using: cyradm --server localhost It didn't work and appeared the message Broken Pipe. I don't know why, who could tell me? BR, LinDec 11, 2002
Re: Unexpected lmtpproxy response
On Wed, 11 Dec 2002 17:06:51 +1100, Rob Mueller [EMAIL PROTECTED] said: Every now and then, we see the following error in our logs: Dec 6 22:29:20 www postfix/lmtp[15516]: 7319A58B2: to=xyz, relay=/var/imap/socket/lmtpprox[/var/imap/socket/lmtpprox], delay=218, status=bounced (host /var/imap/socket/lmtpprox[/var/imap/socket/lmtpprox] said: 250 2.1.5 ok (in reply to DATA command)) ... There are a few specifics that seem to trigger it: 1. We're using a unix socket. If we change to an inet one with an internal IP address, the problem doesn't seem to occur Actually, we haven't confirmed #1 as yet. I'm not sure whether or not it occurs with a TCP socket.
