Re: dothack and cyrus 2.0.16
> > We are locking for "dothack" patch in order to be able to create logins > > with dots... > > > The alternate separator patch is incorporated into 2.1, which provides the > same functionality. Yes, yes, but 2.1 requires the new SASL and all those problems. Since the 'final answer' is "stick with 2.0 until all the other applications are updated" then you need to keep supporting 2.0. -- Joe Rhett Chief Geek [EMAIL PROTECTED] ISite Services, Inc.
Re: dothack and cyrus 2.0.16
Any chance one of you could do this so that the branch is validated and up to date, please? This is your baby :-} On Mon, Jan 28, 2002 at 04:05:54PM -0500, Ken Murchison wrote: > If you *REALLY* need this functionality for 2.0.16, I'd suggest doing > this via CVS. Grab the 'hier-sep' branch and the merge the > 'cyrus-release-2-0-16' tag. > > Ken > > > > Enric Ramos wrote: > > > > Hi. > > > > Firstofall thanks for your help... > > I've found the HIERSEP-r2.patch for cyrus-imapd-2.0.15.. > > > > Unfortunately, after apply this patch it includes references into > > imapd.c,master.c etc... to namespace.h file... > > I havn't got this file anywhere, and obviosly, afetr applying this patch > > cyrus doesn't compile... > > > > Do you know where could I find this file (namespace.h) ?? > > > > I have search in 2.0.16,2.1.1,2.0.15... but this file doesn't exists... > > > > Thsnks ! > > > > Enric > > > > > -Mensaje original- > > > De: Jeremy Howard [mailto:[EMAIL PROTECTED]] > > > Enviado el: sábado, 26 de enero de 2002 8:22 > > > Para: Joe Rhett > > > CC: Enric Ramos; [EMAIL PROTECTED] > > > Asunto: Re: dothack and cyrus 2.0.16 > > > > > > > > > > > > We are locking for "dothack" patch in order to be able to create > > > logins > > > > > > with dots... > > > > > > > > > > > The alternate separator patch is incorporated into 2.1, > > > which provides > > > the > > > > > same functionality. > > > > > > > > Yes, yes, but 2.1 requires the new SASL and all those > > > problems. Since the > > > > 'final answer' is "stick with 2.0 until all the other > > > applications are > > > > updated" then you need to keep supporting 2.0. > > > > > > > Well then search for "althier" on google. There's a 2.0.15 > > > patch floating > > > around. > > > > > > > > -- > 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 -- Joe Rhett Chief Geek [EMAIL PROTECTED] ISite Services, Inc.
Re: dothack and cyrus 2.0.16
> There is no further development on any branches other than HEAD at this > time (um, well, Rob is working on some sieve byte-code stuff but this is > limited to a small set of files, even though he's working on a branch). > > Unfortunately, I don't have the time, inclination or desire to port the > hier-sep. The intent of putting this functionality into v2.1 was to try > to get people who want/need this feature to upgrade (just like the TLS > caching code, SQUAT indexing, etc). If there is a need/want for this, > someone who hasn't already upgraded will have to do the port. Maybe, but in forcing the new SASL you've raised the entry bar too high for any production configuration to join. Your baby might be born, but she's on the moon and we have no spaceships to get there yet. -- Joe Rhett Chief Geek [EMAIL PROTECTED] ISite Services, Inc.
Re: dothack and cyrus 2.0.16
> I'll take a shot at it (it being an interim tool). Is this basically > what people are looking for? > > a saslpasswd that does it's operations on both /etc/sasldb (old sasl) > and /etc/sasldb2 (new sasl) Yeppers. > a sasldblistusers that will list from either Not so important for us, and may be very confusing. I would say #1 has priority, because we can teach the admins how to query both. > a saslconv to convert from one to the other <- this would be a no go if > the data encryption changed (not just stored different) Yeppers. -- Joe Rhett Chief Geek [EMAIL PROTECTED] ISite Services, Inc.
Re: dothack and cyrus 2.0.16
> There might be a little bit of pain involved for large sites to migrate > to IMAP 2.1/SASL 2.x, but there aren't any showstoppers that I'm aware > of. > > If CMU can do it (and yes, they are using Sendmail 8.12.x with SMTP > AUTH), then any site should be able to do it. I have asked several times on the list, and nobody has told us of a way to handle the dual environment using the sasldb as the database. -- Joe Rhett Chief Geek [EMAIL PROTECTED] ISite Services, Inc.
Re: How to let users change their password ?
Someone did a patch for saslpasswd that would allow it to be run non-suid, with the original password and then the replacement password supplied on standard input (for a web CGI). I assumed it has been integrated into the new release, but perhaps not. We're still using that patch in production. On Thu, Feb 07, 2002 at 11:46:25AM +0100, Daniel Persson wrote: > Hi all, > > Im finally up and running with my new mailsolution. > > However, right now all users got a default password, and i want to let > them change their passsword. > > How do i accomplish this since none of them has shellacess and cant run > saslpasswd ? > > Any good tricks out there ? > > /Daniel > > -- > Daniel Persson > > Westbo Linux User Group ---> http://wlug.westbo.se > A swedish site about Gnome---> http://wlug.westbo.se/gnome > My personal pages ---> http://wlug.westbo.se/~myrridin > > Dagens kommentar : > > "Computer games don't affect kids; I mean if Pac-Man affected us as kids, > we'd all be running around in darkened rooms, munching magic pills and > listening to repetitive electronic music." > > Kristian Wilson, Nintendo, Inc, 1989. > -- Joe Rhett Chief Geek [EMAIL PROTECTED] ISite Services, Inc.
Re: Getting SASL from CVS --- automake complains about errors
> $ make distclean > $ rm aclocal.m4 config.* configure saslauthd/aclocal.m4 saslauthd/config.* > saslauthd/configure > $ sh SMakefile > > This _should_ run clean except for the WARNINGs. Except that it deletes config.sub ! -- Joe Rhett Chief Geek [EMAIL PROTECTED] ISite Services, Inc.
cvs imapd configure errors out on the SASL libs
This problem continues to exist in CVS. The problem is that you aren't including the include path specified by --with-sasl when you compile and run the test program. SASL is installed in /opt/sasl. I'm using the configuration options listed below. I get the output listed below. If I go into /usr/lib/include and type "ln -s /opt/sasl/include/sasl" then the configure runs perfectly fine. The relevant line is at 5348 in the configure generated on my system. ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" There's no use of $CPPFLAGS to pick up the --with-sasl includes or libs. Again, you don't notice this because you pollute the includes and libs with /usr/local automatically, even when it isn't relevant and can be harmful. Please fix the autoconf to use the --with-sasl options when building conftest. On Tue, Aug 20, 2002 at 09:12:16PM -0700, Joe Rhett wrote: > Configure problem with cyrus-imapd CVS version -- it's not seeing --with-sasl > at all. > > ./configure --prefix=/opt/imapd --with-cyrus-prefix=/opt/imapd > --with-sasl=/opt/sasl --with-openssl=/opt/openssl > --with-dbdir=/opt/berkeleydb > ...etc... > checking for sasl/sasl.h... yes > checking for sasl/saslutil.h... yes > checking for prop_get in -lsasl2... yes > configure: error: Incorrect SASL headers found. This package requires SASL 2.1.7 or >newer. > > However, the only sasl.h on the system is in /opt/sasl/include/sasl/ ... > Commenting out the "rm conftest*" in 'configure' and then checking the > output of the test program shows... > > cyclops 151% cat conftest.out > configure:5278: sasl/sasl.h: No such file or directory > configure:5281: #error SASL_VERSION_MAJOR not defined > configure:5284: #error SASL_VERSION_MINOR not defined > configure:5287: #error SASL_VERSION_STEP not defined > configure:5291: #error SASL version is less than 2.1.7 > > > I can't quite figure out why this isn't working, but the sasl.h and libsasl2 > tests are -- maybe you have a clue? > > On Wed, Aug 14, 2002 at 10:38:35AM -0700, Joe Rhett wrote: > > Nope. We had to downgrade so that I could work with your CVS stuff. Most > > annoying. > > > > On Mon, Aug 12, 2002 at 06:52:40PM -0400, Ken Murchison wrote: > > > Did you upgrade to a new version of autoconf? Only v2.13 will work > > > (currently). > > > > > > > > > > > > Joe Rhett wrote: > > > > On Fri, Aug 09, 2002 at 09:46:42PM -0400, Ken Murchison wrote: > > > > > > > >>Joe Rhett wrote: > > > >> > > > >>>Well, that's part 2 --- sasl won't compile for me any more. > > > >> > > > >>Whoa! Did you try: > > > >> > > > >>make distclean > > > >>rm configure aclocal.m4 > > > >>sh SMakefile > > > > > > > > > > > > aclocal.m4 doesn't exist for me, and configure never got far enough to make > > > > a real Makefile so make distclean doesn't work -- but yeah, that's exactly > > > > what I've done. > > > > > > > > > > > >>>cyclops% sh SMakefile > > > >>>aclocal -I cmulocal -I config > > > >>>aclocal: configure.in: 80: macro `AM_DISABLE_STATIC' not found in library > > > >>>aclocal: configure.in: 82: macro `AM_PROG_LIBTOOL' not found in library > > > >>>autoheader > > > >>>autoconf > > > >>>autoconf: Undefined macros: > > > >>>configure.in:192: AC_DEFINE(DLSYM_NEEDS_UNDERSCORE), > > > >>>configure.in:224: AC_DEFINE(HAVE_PAM) > > > >>>configure.in:236: AC_DEFINE(HAVE_SASLAUTHD) > > > >>>configure.in:237: AC_DEFINE_UNQUOTED(PATH_SASLAUTHD_RUNDIR, > > > >>>"$with_saslauthd") > > > >>>configure.in:251: AC_DEFINE(HAVE_PWCHECK) > > > >>>configure.in:252: AC_DEFINE_UNQUOTED(PWCHECKDIR, "$with_pwcheck") > > > >>>configure.in:267: AC_DEFINE(USE_DOORS) > > > >>>configure.in:274: AC_DEFINE(HAVE_ALWAYSTRUE) > > > >>>configure.in:287: AC_DEFINE(DO_SASL_CHECKAPOP) > > > >>>configure.in:302: AC_DEFINE(STATIC_CRAMMD5) > > > >>>configure.in:330: AC_DEFINE(STATIC_DIGESTMD5) > > > >>>configure.in:385: AC_DEFINE(STATIC_OTP) > > > >>>configure.in:412:AC_DEFINE(HAVE_OPIE) > > > >>>configure.in:441: AC_DEFINE(STATIC_SRP) > &
Time has come to stop with /usr/local path pollution!
We really must stop with the path pollution that you guys include into the configuration process. I just lost 2 hours trying to figure out why it couldn't find a db3_nosync function... and finally figured out that you were looking at a path I never specified ( /usr/local/include ) and reading the include files from there, instead of the path I did specify: --with-dbdir=/opt/berkeleydb If I want you to read /usr/local, I'll tell you that. Please stop assuming that everything is dumped there. At the very least, try the specified path and only try /usr/local if nothing was specified. You've had more than a dozen complaints about stuff picking up the wrong libraries, when the properly library paths were explicitly listed. On Thu, Sep 26, 2002 at 03:30:54PM -0700, Joe Rhett wrote: > This problem continues to exist in CVS. The problem is that you aren't > including the include path specified by --with-sasl when you compile and > run the test program. > > SASL is installed in /opt/sasl. I'm using the configuration options listed > below. I get the output listed below. > > If I go into /usr/lib/include and type "ln -s /opt/sasl/include/sasl" then > the configure runs perfectly fine. The relevant line is at 5348 in the > configure generated on my system. > > ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" > > There's no use of $CPPFLAGS to pick up the --with-sasl includes or libs. > > Again, you don't notice this because you pollute the includes and libs with > /usr/local automatically, even when it isn't relevant and can be harmful. > Please fix the autoconf to use the --with-sasl options when building > conftest. > > On Tue, Aug 20, 2002 at 09:12:16PM -0700, Joe Rhett wrote: > > Configure problem with cyrus-imapd CVS version -- it's not seeing --with-sasl > > at all. > > > > ./configure --prefix=/opt/imapd --with-cyrus-prefix=/opt/imapd > > --with-sasl=/opt/sasl --with-openssl=/opt/openssl > > --with-dbdir=/opt/berkeleydb > > ...etc... > > checking for sasl/sasl.h... yes > > checking for sasl/saslutil.h... yes > > checking for prop_get in -lsasl2... yes > > configure: error: Incorrect SASL headers found. This package requires SASL 2.1.7 >or newer. > > > > However, the only sasl.h on the system is in /opt/sasl/include/sasl/ ... > > Commenting out the "rm conftest*" in 'configure' and then checking the > > output of the test program shows... > > > > cyclops 151% cat conftest.out > > configure:5278: sasl/sasl.h: No such file or directory > > configure:5281: #error SASL_VERSION_MAJOR not defined > > configure:5284: #error SASL_VERSION_MINOR not defined > > configure:5287: #error SASL_VERSION_STEP not defined > > configure:5291: #error SASL version is less than 2.1.7 > > > > > > I can't quite figure out why this isn't working, but the sasl.h and libsasl2 > > tests are -- maybe you have a clue? > > > > On Wed, Aug 14, 2002 at 10:38:35AM -0700, Joe Rhett wrote: > > > Nope. We had to downgrade so that I could work with your CVS stuff. Most > > > annoying. > > > > > > On Mon, Aug 12, 2002 at 06:52:40PM -0400, Ken Murchison wrote: > > > > Did you upgrade to a new version of autoconf? Only v2.13 will work > > > > (currently). > > > > > > > > > > > > > > > > Joe Rhett wrote: > > > > > On Fri, Aug 09, 2002 at 09:46:42PM -0400, Ken Murchison wrote: > > > > > > > > > >>Joe Rhett wrote: > > > > >> > > > > >>>Well, that's part 2 --- sasl won't compile for me any more. > > > > >> > > > > >>Whoa! Did you try: > > > > >> > > > > >>make distclean > > > > >>rm configure aclocal.m4 > > > > >>sh SMakefile > > > > > > > > > > > > > > > aclocal.m4 doesn't exist for me, and configure never got far enough to make > > > > > a real Makefile so make distclean doesn't work -- but yeah, that's exactly > > > > > what I've done. > > > > > > > > > > > > > > >>>cyclops% sh SMakefile > > > > >>>aclocal -I cmulocal -I config > > > > >>>aclocal: configure.in: 80: macro `AM_DISABLE_STATIC' not found in library > > > > >>>aclocal: configure.in: 82: macro `AM_PROG_LIBTOOL' not found in library > > > > >>>auto
Re: Time has come to stop with /usr/local path pollution!
> > However it does seem that when explicit paths are called for certain > > componants they should be placed in line before the assumed system paths. > I agree 100% that the paths should be honored. However, since it works > for most people, and testing is pretty annoying (as ken stated), I'm not > terribly eager to spend my time doing it, when I could be working on > performance or feature improvements elsewhere in the code. > > If there was a patch provided that I could look at, approve, and apply, > I'd be willing to do so. Ah -- that is all I was waiting to hear. Patch will be coming up. > to read a bug report hidden inside of a rant that seems to assume that the > developers of Cyrus are part of a consipracy against all system > administrators everywhere. Wow. Somehow you got something (er, a lot of things!) from my message I never intended. All I was complaining about was that the application of the --with-path= stuff was very non-intuitive, and your average "./configure ; make ; make install" person has no chance of figuring this out. -- Joe Rhett Chief Geek [EMAIL PROTECTED] ISite Services, Inc.
Re: Time has come to stop with /usr/local path pollution!
> The next time somebody is frustrated by the software and wants to rant about > how much of their time the developers wasted, take a step back and remember how > much time and money they actually _saved_ you. Having been the guilty party which kicked off this thread, I want to step back and make myself clear. 1. Thank You! 2. I help as I can, although it often ends up being documentation or testing rather than code. 3. Sometimes that help is intended to save other users from running circles around a problem I ran circles around. Ultimately, this should reduce the amount of hand-holding you have to do, which makes your life easier. I was doing #2, found an issue and tried to do #3. This was the ultimate goal of my message, not to criticize anyone personally. I pretty much screwed up the tone of my message completely, and I really hope each of you will accept my deepest apologies. -- Joe Rhett Chief Geek [EMAIL PROTECTED] ISite Services, Inc.
Re: Time has come to stop with /usr/local path pollution!
> First off, why did you feel the need to send this directly to me? Cyrus > is not _my_ software, I'm just a contributor. Secondly, I can > understand your frustration, but your shitty attitude ain't gonna help. Sorry, I misunderstood clearly, as I thought you were heading up the imapd 2.2 branch. > A lot of bitching, and no proposed fixes. It works for me, and I'm sure > it works for CMU, otherwise it would've been fixed already. Since I I would happily submit a patch .. but I want to make sure it would be accepted or at least considered. I've lost too much time over the years putting together a clean patch to fix something only to find that the maintainers had no interest in _ever_ accepting said patch. So I toss out a query about it before I do it. And before you say "Then why the complaint?" -- because I did toss out such a query. Twice. Once on this list, and once on the SASL list. With no takers on the issue. > Have people forgotten how much they _paid_ for this software? What is > the ROI and/or price performance of this software for ISPs, freakin' > infinity? Why is it assumed that each user is _entitled_ to some level > of technical support? Not asking for technical support. Suggesting that this may solve a lot of the compilation support issues you guys receive on the list. -- Joe Rhett Chief Geek [EMAIL PROTECTED] ISite Services, Inc.
TimSieved dies silently, exit status 75 .. in config.c?
I'm using CVS'd cyrus_2_2. For some reason that I can't figure out, timsieved dies with: telnet localhost sieve Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. NO Fatal error: Internal error: assertion failed: config.c: 220: imapopts[opt].t == OPT_SWITCH Connection closed by foreign host. Oct 2 15:45:57 gamera.isite.net master[24520]: [ID 392559 local6.debug] about to exec /opt/imapd/bin/timsieved Oct 2 15:45:57 gamera.isite.net sieve[24520]: [ID 518349 local6.debug] executed Oct 2 15:45:57 gamera.isite.net sieve[24520]: [ID 921384 local6.debug] accepted connection Oct 2 15:45:57 gamera.isite.net master[24353]: [ID 310780 local6.debug] process 24520 exited, status 75 The last time I set up Sieve it worked perfectly out of the box, so I never learned anything :-( This is probably a bonehead configuration problem, but I don't know where to look. Is there any additional logging I can get here to figure out what's wrong? -- Joe Rhett Chief Geek [EMAIL PROTECTED] ISite Services, Inc.
Re: TimSieved dies silently, exit status 75 .. in config.c?
> > I'm using CVS'd cyrus_2_2. For some reason that I can't figure out, > > timsieved dies with: > > Is this a new problem since you've done a CVS update? If so, try doing a > make clean and trying again. I haven't tried Sieve since I started working with Cyrus v2 at all. Last time I had it working was v1. Nothing I knew them may apply. What does exit status 75 mean? It's dying in config.c -- is there a configuration option I'm overlooking? sievedir is set in imapd.conf. -- Joe Rhett Chief Geek [EMAIL PROTECTED] ISite Services, Inc.
Re: TimSieved dies silently, exit status 75 .. in config.c?
Ah -- I believe that I always do a make clean, but it won't hurt me to try the build process again. On Thu, Oct 03, 2002 at 03:26:42PM -0400, Rob Siemborski wrote: > On Thu, 3 Oct 2002, Joe Rhett wrote: > > > > Is this a new problem since you've done a CVS update? If so, try doing a > > > make clean and trying again. > > > > I haven't tried Sieve since I started working with Cyrus v2 at all. Last > > time I had it working was v1. Nothing I knew them may apply. > > You misunderstand... In your 2.2 tree, did you ever do this sequence (or > something similar): > > cvs checkout > make > cvs update > make > > There's a possibility that if you didn't have an intervening make clean > after the cvs update, that stuff didn't build properly. > > -Rob > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 > Research Systems Programmer * /usr/contributed Gatekeeper > -- Joe Rhett Chief Geek [EMAIL PROTECTED] ISite Services, Inc.
Re: TimSieved dies silently, exit status 75 .. in config.c?
I did a completely clean suck from CVS and rebuilt, and you were right -- problem gone. Danke schon! On Thu, Oct 03, 2002 at 02:38:50PM -0700, Joe Rhett wrote: > Ah -- I believe that I always do a make clean, but it won't hurt me to try > the build process again. > > On Thu, Oct 03, 2002 at 03:26:42PM -0400, Rob Siemborski wrote: > > On Thu, 3 Oct 2002, Joe Rhett wrote: > > > > > > Is this a new problem since you've done a CVS update? If so, try doing a > > > > make clean and trying again. > > > > > > I haven't tried Sieve since I started working with Cyrus v2 at all. Last > > > time I had it working was v1. Nothing I knew them may apply. > > > > You misunderstand... In your 2.2 tree, did you ever do this sequence (or > > something similar): > > > > cvs checkout > > make > > cvs update > > make > > > > There's a possibility that if you didn't have an intervening make clean > > after the cvs update, that stuff didn't build properly. > > > > -Rob > > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 > > Research Systems Programmer * /usr/contributed Gatekeeper > > > > -- > Joe Rhett Chief Geek > [EMAIL PROTECTED] ISite Services, Inc. -- Joe Rhett Chief Geek [EMAIL PROTECTED] ISite Services, Inc.
Re: cvs imapd configure errors out on the SASL libs
I can't find the original e-mail but I thought someone said they had solved this -- but either it isn't checked into CVS, or it isn't merged into the cyrus_2_2 tree, because a fresh new pull from CVS was still compiling the conftest program without the --with-sasl paths, and I had to create symbolic links in /usr/local/include for configure to run. On Thu, Sep 26, 2002 at 03:30:54PM -0700, Joe Rhett wrote: > This problem continues to exist in CVS. The problem is that you aren't > including the include path specified by --with-sasl when you compile and > run the test program. > > SASL is installed in /opt/sasl. I'm using the configuration options listed > below. I get the output listed below. > > If I go into /usr/lib/include and type "ln -s /opt/sasl/include/sasl" then > the configure runs perfectly fine. The relevant line is at 5348 in the > configure generated on my system. > > ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" > > There's no use of $CPPFLAGS to pick up the --with-sasl includes or libs. > > Again, you don't notice this because you pollute the includes and libs with > /usr/local automatically, even when it isn't relevant and can be harmful. > Please fix the autoconf to use the --with-sasl options when building > conftest. > > On Tue, Aug 20, 2002 at 09:12:16PM -0700, Joe Rhett wrote: > > Configure problem with cyrus-imapd CVS version -- it's not seeing --with-sasl > > at all. > > > > ./configure --prefix=/opt/imapd --with-cyrus-prefix=/opt/imapd > > --with-sasl=/opt/sasl --with-openssl=/opt/openssl > > --with-dbdir=/opt/berkeleydb > > ...etc... > > checking for sasl/sasl.h... yes > > checking for sasl/saslutil.h... yes > > checking for prop_get in -lsasl2... yes > > configure: error: Incorrect SASL headers found. This package requires SASL 2.1.7 >or newer. > > > > However, the only sasl.h on the system is in /opt/sasl/include/sasl/ ... > > Commenting out the "rm conftest*" in 'configure' and then checking the > > output of the test program shows... > > > > cyclops 151% cat conftest.out > > configure:5278: sasl/sasl.h: No such file or directory > > configure:5281: #error SASL_VERSION_MAJOR not defined > > configure:5284: #error SASL_VERSION_MINOR not defined > > configure:5287: #error SASL_VERSION_STEP not defined > > configure:5291: #error SASL version is less than 2.1.7 > > > > > > I can't quite figure out why this isn't working, but the sasl.h and libsasl2 > > tests are -- maybe you have a clue? > > > > On Wed, Aug 14, 2002 at 10:38:35AM -0700, Joe Rhett wrote: > > > Nope. We had to downgrade so that I could work with your CVS stuff. Most > > > annoying. > > > > > > On Mon, Aug 12, 2002 at 06:52:40PM -0400, Ken Murchison wrote: > > > > Did you upgrade to a new version of autoconf? Only v2.13 will work > > > > (currently). > > > > > > > > > > > > > > > > Joe Rhett wrote: > > > > > On Fri, Aug 09, 2002 at 09:46:42PM -0400, Ken Murchison wrote: > > > > > > > > > >>Joe Rhett wrote: > > > > >> > > > > >>>Well, that's part 2 --- sasl won't compile for me any more. > > > > >> > > > > >>Whoa! Did you try: > > > > >> > > > > >>make distclean > > > > >>rm configure aclocal.m4 > > > > >>sh SMakefile > > > > > > > > > > > > > > > aclocal.m4 doesn't exist for me, and configure never got far enough to make > > > > > a real Makefile so make distclean doesn't work -- but yeah, that's exactly > > > > > what I've done. > > > > > > > > > > > > > > >>>cyclops% sh SMakefile > > > > >>>aclocal -I cmulocal -I config > > > > >>>aclocal: configure.in: 80: macro `AM_DISABLE_STATIC' not found in library > > > > >>>aclocal: configure.in: 82: macro `AM_PROG_LIBTOOL' not found in library > > > > >>>autoheader > > > > >>>autoconf > > > > >>>autoconf: Undefined macros: > > > > >>>configure.in:192: AC_DEFINE(DLSYM_NEEDS_UNDERSCORE), > > > > >>>configure.in:224: AC_DEFINE(HAVE_PAM) > > > > >>>configure.in:236: AC_DEFINE(HAVE_SASLAUTHD) > > > > >>>configure.i
Re: cvs imapd configure errors out on the SASL libs
Forget I said that. Operator error. The fix is in. On Thu, Oct 03, 2002 at 09:04:39PM -0700, Joe Rhett wrote: > I can't find the original e-mail but I thought someone said they had solved > this -- but either it isn't checked into CVS, or it isn't merged into the > cyrus_2_2 tree, because a fresh new pull from CVS was still compiling the > conftest program without the --with-sasl paths, and I had to create > symbolic links in /usr/local/include for configure to run. > > On Thu, Sep 26, 2002 at 03:30:54PM -0700, Joe Rhett wrote: > > This problem continues to exist in CVS. The problem is that you aren't > > including the include path specified by --with-sasl when you compile and > > run the test program. > > > > SASL is installed in /opt/sasl. I'm using the configuration options listed > > below. I get the output listed below. > > > > If I go into /usr/lib/include and type "ln -s /opt/sasl/include/sasl" then > > the configure runs perfectly fine. The relevant line is at 5348 in the > > configure generated on my system. > > > > ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" > > > > There's no use of $CPPFLAGS to pick up the --with-sasl includes or libs. > > > > Again, you don't notice this because you pollute the includes and libs with > > /usr/local automatically, even when it isn't relevant and can be harmful. > > Please fix the autoconf to use the --with-sasl options when building > > conftest. > > > > On Tue, Aug 20, 2002 at 09:12:16PM -0700, Joe Rhett wrote: > > > Configure problem with cyrus-imapd CVS version -- it's not seeing --with-sasl > > > at all. > > > > > > ./configure --prefix=/opt/imapd --with-cyrus-prefix=/opt/imapd > > > --with-sasl=/opt/sasl --with-openssl=/opt/openssl > > > --with-dbdir=/opt/berkeleydb > > > ...etc... > > > checking for sasl/sasl.h... yes > > > checking for sasl/saslutil.h... yes > > > checking for prop_get in -lsasl2... yes > > > configure: error: Incorrect SASL headers found. This package requires SASL >2.1.7 or newer. > > > > > > However, the only sasl.h on the system is in /opt/sasl/include/sasl/ ... > > > Commenting out the "rm conftest*" in 'configure' and then checking the > > > output of the test program shows... > > > > > > cyclops 151% cat conftest.out > > > configure:5278: sasl/sasl.h: No such file or directory > > > configure:5281: #error SASL_VERSION_MAJOR not defined > > > configure:5284: #error SASL_VERSION_MINOR not defined > > > configure:5287: #error SASL_VERSION_STEP not defined > > > configure:5291: #error SASL version is less than 2.1.7 > > > > > > > > > I can't quite figure out why this isn't working, but the sasl.h and libsasl2 > > > tests are -- maybe you have a clue? > > > > > > On Wed, Aug 14, 2002 at 10:38:35AM -0700, Joe Rhett wrote: > > > > Nope. We had to downgrade so that I could work with your CVS stuff. Most > > > > annoying. > > > > > > > > On Mon, Aug 12, 2002 at 06:52:40PM -0400, Ken Murchison wrote: > > > > > Did you upgrade to a new version of autoconf? Only v2.13 will work > > > > > (currently). > > > > > > > > > > > > > > > > > > > > Joe Rhett wrote: > > > > > > On Fri, Aug 09, 2002 at 09:46:42PM -0400, Ken Murchison wrote: > > > > > > > > > > > >>Joe Rhett wrote: > > > > > >> > > > > > >>>Well, that's part 2 --- sasl won't compile for me any more. > > > > > >> > > > > > >>Whoa! Did you try: > > > > > >> > > > > > >>make distclean > > > > > >>rm configure aclocal.m4 > > > > > >>sh SMakefile > > > > > > > > > > > > > > > > > > aclocal.m4 doesn't exist for me, and configure never got far enough to make > > > > > > a real Makefile so make distclean doesn't work -- but yeah, that's exactly > > > > > > what I've done. > > > > > > > > > > > > > > > > > >>>cyclops% sh SMakefile > > > > > >>>aclocal -I cmulocal -I config > > > > > >>>aclocal: configure.in: 80: macro `AM_DISABLE_STATIC' not found in li
Re: Configure for imapd 2.1.9 doesn't necessarily pick up the version of BerkeleyDB specified with --with-dbdir= switch
This is well known, although not well documented. I believe it is fixed in cvs as well. On Tue, Oct 15, 2002 at 11:06:57AM -0400, Gordon Marler wrote: > On Tue, 2002-10-15 at 10:42, Rob Siemborski wrote: > > On 15 Oct 2002, Gordon Marler wrote: > > > > > Since I'm not set up for GSSAPI yet, I used --disable-gssapi, and it > > > works fine. Many thanks! > > > > > > It isn't intuitive that the two would be related, is it? > > > > It is, since your configure.log was complaining about GSSAPI libraries > > that were missing. It's a bit more disturbing that it thought you had > > them, but I'll look into that I guess. > > > > -Rob > > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 > > Research Systems Programmer * /usr/contributed Gatekeeper > > > > > > > What's even more disturbing (note the subject change above for the > benefit of the list) is the fact that if you specify > --with-dbdir= > to configure, it won't necessarily pick that up. Allow me to elaborate: > > I have every version of Sleepycat Berkeley DB installed since v2.7.7. > However, I use one of them more than the others, so my PATH is set to go > through that version's /bin directory (version 4.x.x) > > I notice that if I specify the --with-dbdir= switch to > configure, configure runs programs in *my PATH* (DB version 4.x.x) to > determine the version of DB available rather than exclusively using the > directory I specified in the --with-dbdir= switch. Of course, this > causes the compile to fail miserably later, since configure couldn't > really determine which version to target, so it mixes them up a bit. > > Just thought the maintainer would like to know this was happening. Most > products that allow you to specify a certain version of a library during > a configure purposely ignore all other installations of that library, > and manually set the PATH during each configure test to make sure that > only the specified version of a tool is used. Oh well... > > -- > T. Gordon Marler > [EMAIL PROTECTED] -- Joe Rhett Chief Geek [EMAIL PROTECTED] ISite Services, Inc.
Re: Stability of 2.2.2?
> My question is, how stable/reliable is 2.2.2? Could I safely use it in > a production environment? I need/want to do virtual domains. Ie, > people logging in with [EMAIL PROTECTED] or [EMAIL PROTECTED] Rock solid. Less problems than we had with 2.1 "stable". -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc.
Re: [POLL] Cyrus 2.2 virtdomains behavior (Was: global admin without defaultdomain?)
> I just committed some code to CVS which changes the virtdomains option > from a SWITCH to an ENUM having 3 options: > > off/no/0/false/f (disabled) > userid(fully qualified userids only) > on/yes/1/true/t (current behavior) > > What this means (hopefully) is that existing installations of 2.2 code > (whether virtdomains is enabled or not) should be unaffected. Those > that don't want the reverse IP address lookup can use the "userid" option. Great answer! Perfect for us. -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc.
Re: Stability of 2.2.2?
On Fri, Jan 02, 2004 at 10:10:01AM -0800, Jules Agee wrote: > Joe Rhett wrote: > >>My question is, how stable/reliable is 2.2.2? Could I safely use it in > >>a production environment? I need/want to do virtual domains. Ie, > >>people logging in with [EMAIL PROTECTED] or [EMAIL PROTECTED] > > > > > >Rock solid. Less problems than we had with 2.1 "stable". > > Would you mind briefly describing the problems you had with 2.1 stable, > and which version you were using (2.1.14/15/16...)? I am planning an > upgrade and I expect to use 2.1.16, unless someone has a pretty > compelling reason to go with 2.2.2. I don't need any of the new 2.2 > features. Stability is by far the most important factor. We had some corrupted Seen indexes and various sorts of non-critical but time-consuming problems to work out. The patches that solved these problems went into both the 2.1 and 2.2 trees, but releases in the 2.2 came out faster ;-) -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc.
Re: SSL/TLS question
> I expect that'd do it; you'll still need to install the CA certificate > in browsers, though. I have a similar setup, but with a CA cert > generated in-house. No you don't. The server hands out both certificates during the connection process. It just works ;-) > I then install the ca cert into clients who need access. To be specific, > I generate a client SSL certificate for them that also contains an > embedded version of our CA cert. That way they import the CA cert when > they install the client cert; I then just get them to authorize the CA > cert for identifying remote hosts. In your case it sounds like you aren't using a certificate signed by any known authority. He is - he's just using one signed by someone who was signed by a known authority. Nothing needs to be installed in the browser. -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc.
Re: SSL/TLS question
On Mon, Jan 12, 2004 at 07:25:33PM -0800, Wil Cooley wrote: > [Sorry this is a repost from a month ago; I didn't get an answer then, > but maybe my timing is better now.] > > For my web server, I use a certificate from Comodo which is very > inexpensive by comparison with Thawte/Verisign certs, but it requires > installation of an intermediary key for most browsers to be happy with > it. It's not difficult with Apache and mod_ssl; I'm wondering if it > will work with Cyrus, perhaps using the 'tls_ca_file'? The docs are a > little sparse (and Comodo doesn't provide explicit instructions like it > does for mod_ssl) and my understanding of SSL/TLS is a bit limited. Use the exact same files for the web server as for the Cyrus mail server. They're both using the same library. And no, the CA file is to verify client certs. In this case you put the certificate and the intermediary certificate in the same file (*.cert) You don't need a tls_ca_file unless you are verifying client certs. (unlikely) -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc.
Re: virtualdomains and SASL realms?
> 1) What realm is sent to the SASL layer when a user logs in with an > unqualified username? Is the realm automatically set to the virtual > domain that they're in? defaults to hostname() > 2) When a user logs in with an unqualified username in the > defaultdomain, are they sent with a blank SASL realm, or with the > defaultdomain as their realm? probably the same. -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc.
Re: Helpful Hint on Virtual Domains, and Mail Aliases
On Mon, Feb 02, 2004 at 05:49:36PM -0500, Peter P. Benac wrote: > To Whom: > > I found it very difficult to set up virtual domains and getting my > existing mail aliases working with sendmail. It might have been helpful if > the documentation mentioned that I needed to get rid of my virtusertable, > local-host-names and to reference all the aliases in the my aliases file by > their respective domains. Um.. well, none of those statements are true. Clearly that configuration worked for you, but we use Cyrus with local-host-names, local aliases and a very extensive virtusertable. > Having to guess all of this made the install very frustrating, not to > mention the stupid questions I did post to the mail list could have been > avoided. It sounds like all of these questions were really Sendmail configuration questions. (I'm guessing) The problem wasn't Cyrus IMAPd at all, but that you had issues configuring the MTA to route mail properly. That really isn't something that Cyrus documentation should attempt to solve. That said, as Ken indicated, updates to documentation are always accepted. I know for certain, because most of my updates were (in spirit if not word by word). -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc. --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Kill this thread, it shouldn't have been one ( was: Re: CYRUS = ....)
On Tue, Feb 03, 2004 at 09:53:01AM -0500, Peter P. Benac wrote: > I had asked several stupid questions on the list because I couldn't find > a stupid answer and I didn't get a single response. For what it's worth, I'm sorry ... but I get really tired of trying to tell people that they have an MTA configuration issue. They rarely listen to me. And I've generally found that someone who can't tell an MTA from an MSA from a delivery system isn't going to be able to figure it out. And statements about debugging often being an MTA problem (and how to determine that) ARE documented. They just get ignored far too often. And so we on the list get tired of answering the same questions repeatedly and just start to ignore them. > from guessing. Luckily I don't need to answer to a higher power so I had > plenty of time to get this working. Perhaps David did not have the luxury > of time. How much time would it have taken for someone to answer my stupid Freeware is not for those without the luxory of time. If he wanted a solution immediately with complete documentation, then he should buy one. -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc. --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Clear text password and MySQL
On Wed, Feb 04, 2004 at 11:41:06AM -0800, Eric S. Pulley wrote: > In this scenario you are still passing the SALT in clear text to the db > but IMO this is much better than having your users logging in with > plaintext passwords over an open network. Especially if your DB is on > the same host as cyrus-imap since you can contain it to a socket and not > use a network at all for the DB lookups. So what is the gain here, really? I may be wrong, but I suspect that you've confused yourself on what you are protecting. If you aren't using TLS, then the password is going over the network in cleartext anyway. If imapd is on a different host than the db, then the encrypted password is going with the salt... so effectively cleartext. -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc. --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: MySQL authentication options
> I had been doing some research about authenticating user against a MySQL > database, and from what I can see the only option is via PAM through > saslauthd. Is this correct, or there are other way to do it ? Nope -- you can compile SASL with direct mysql support and skip PAM entirely. We use it that way. -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc. --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: virtual domains questions
> Is there any ability to adjust a quota per virtual domain ? Yes, read the documentation. > and second question is problem. > After upgrading cyrus-imapd-2.1.16 to cyrus-imapd-2.2.3 > I can't connect to sieve, where is my problem ? And again, read the FAQ. -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc. --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Group usage on mailboxes...
So what is to prevent someone from writing a group ptloader for the SQL database backend? And where would we start? On Tue, Mar 23, 2004 at 01:45:11PM -0500, Rob Siemborski wrote: > On Tue, 23 Mar 2004, Jason Williams wrote: > > > Since im using sasldb2 as the backend, the auth_unix won't work then correct? > > > > I'm not real familiar with AFS PTS. Could someone give me a quick rundown > > on that? I guess the other alternative is to setup LDAP then with ptloader. > > > > I appreciate it. > > AFS PTS groups probably won't be useful to you if you don't already run > AFS (http://www.openafs.org). > > -Rob > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 > Research Systems Programmer * /usr/contributed Gatekeeper > > --- > Home Page: http://asg.web.cmu.edu/cyrus > Wiki/FAQ: http://cyruswiki.andrew.cmu.edu > List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc. --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: virtual domains questions
On Thu, Apr 01, 2004 at 05:38:19AM +0400, Andrew B. Panphiloff wrote: > ÷ óÒÄ, 31.03.2004, × 14:03, Joe Rhett ÐÉÛÅÔ: > > > Is there any ability to adjust a quota per virtual domain ? > > > > Yes, read the documentation. > > What about this : > > localhost> lm > [EMAIL PROTECTED] (\HasNoChildren) > localhost> sq @borisych.mastak.com 100 > quota:100 > localhost> sq [EMAIL PROTECTED] 500 > quota:500 > > now I send message , which size is between 100 and 500 K > I get: > > localhost> lq [EMAIL PROTECTED] > STORAGE 377/500 (75.4%) > localhost> lq @borisych.mastak.com > STORAGE 0/100 (0%) > localhost> > > Why if I set quota for user it not consider in domain quota ? Because you didn't read the documentation. A user quota root will override a quota root at the domain. Just like any other more specific quota root, as documented. -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc. --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Alias problems
Lenny, you've told Sendmail that example.net's final delivery is an error message. This means you can't deliver to local addresses, because sendmail doesn't know how. Mailertable has to tell sendmail how to deliver to the local address. On Thu, Apr 08, 2004 at 11:42:47AM -0400, Lenny wrote: > I am using the Cyrus-Sendmail integration as done by Andrzej Filip. I'm having > problems with some aliases. > > The problem is with aliases that are in virtusertable which point to an alias in > the aliases file (because the aliases forward to multiple destinations). All > works fine except that I can't have a copy go into the users real mailbox. Here > is an example of what I mean: > > In mailertable: > > example.net mrs_cyrus_mailertable:error:5.1.1:550 User > unknown > > Then [EMAIL PROTECTED] is added to cyrus, so it is a valid account. > > In virtusertable: > > [EMAIL PROTECTED] lennyfw > > In aliases: > > lennyfw: > [EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED] > > Obviously "example.net" is just for illustration purposes. Now, if I send an > email to "[EMAIL PROTECTED]", it parses virtusertable correct. It parses > aliases correctly and sends out to "[EMAIL PROTECTED]" and > "[EMAIL PROTECTED]", but errors on copying the message to the local mailbox > (errors with "User unknown"). > > So, the question is, how can I copy a message into the users actual mailbox via > the aliases file? Thanks. > > -- > > "Wisdom is to a man an infinite Treasure" - Anonymous" > > > > --- > Cyrus Home Page: http://asg.web.cmu.edu/cyrus > Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu > List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc. --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: [cyr]deliver, executed as , should have 's permissions
If you are connecting to localhost, use a socket instead of TCP. On Fri, Apr 09, 2004 at 12:37:12PM -0700, [EMAIL PROTECTED] wrote: > "... I dislike people who do not read docs" : ) Fair enough. > > I have now read _all_ /usr/share/doc/cyrus21-imapd/* and am struggling > to configure cyrus delivery using TCP sockets. cyrus.conf and > imapd.conf contain: > --- > lmtp cmd="lmtpd" listen="localhost:lmtp" prefork=0 maxchild=20 > --- > lmtpsocket: localhost:lmtp > --- > services contians: > --- > lmtp24/tcp > --- > Telnet works: > --- > [EMAIL PROTECTED]:~$ telnet localhost lmtp > Trying 127.0.0.1... > Connected to localhost (127.0.0.1). > Escape character is '^]'. > 220 wum LMTP Cyrus v2.1.16-IPv6-Debian-2.1.16-6 ready > --- > but cyrdeliver does not: > --- > [EMAIL PROTECTED]:~$ /usr/sbin/cyrdeliver admin < tmp/message > couldn't connect to lmtpd: Success > 421 4.3.0 deliver: couldn't connect to lmtpd > --- > Logs contain: > --- > Apr 9 12:07:41 wum cyrus/master[11512]: about to exec > /usr/lib/cyrus/bin/lmtpd > Apr 9 12:07:42 wum cyrus/lmtp[11512]: executed > Apr 9 12:07:42 wum cyrus/lmtpd[11512]: accepted connection > Apr 9 12:07:42 wum cyrus/lmtpd[11512]: connection from localhost > [127.0.0.1] > Apr 9 12:07:42 wum cyrus/deliver[11511]: lmtpengine do_auth: could not > sasl_setprop the security properties > --- > imapd has no SASL problems ... What have I missed? > > My goal is for a user's permission to deliver to a folder to agree with > that folder's ACL - so I can run cyrdeliver as an unprivileged user > (like from .procmailrc), w/o allowing the user to deliver to every > folder. > > Jack > > On Apr 6, 2004, at 8:07 AM, Henrique de Moraes Holschuh wrote: > > >On Tue, 06 Apr 2004, [EMAIL PROTECTED] wrote: > >>[cyr]deliver is executed as my user, instead of "root.mail" - as it > >... > >> > >>How do others get around this? > > > >Read the manpages, and configure cyrus deliver to use TCP sockets > >(cyrus > >lmtpd must be told to listen on the TCP socket as well), or change the > >permissions for the local unix socket. If you're using a Debian > >package of > >the 2.1 series, go read /usr/share/doc/cyrus21-imapd/* NOW. > > > >Make sure you do understand the security implications of what you're > >doing, > >you may end up opening email submission to anyone (which might be, or > >might > >not be a problem in your setup). > > > >-- > > "One disk to rule them all, One disk to find them. One disk to bring > > them all and in the darkness grind them. In the Land of Redmond > > where the shadows lie." -- The Silicon Valley Tarot > > Henrique Holschuh > >--- > >Home Page: http://asg.web.cmu.edu/cyrus > >Wiki/FAQ: http://cyruswiki.andrew.cmu.edu > >List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html > > > > > > --- > Cyrus Home Page: http://asg.web.cmu.edu/cyrus > Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu > List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc. --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Insert artificial delay into IMAP server responses (to workaround OL2002)
On Tue, Apr 13, 2004 at 12:45:55PM -0600, Michael Loftis wrote: > Reproducing this is difficult, but it DOES happen. And when it does SASL > thinks that it never saw AUTH PLAIN in the output from lmtpd, when looking > at the protocol traces/dumps from over the wire it clearly WAS sent and > arrived intact. I wrote a message to the list about it but received no > response. Sorry for the dumb question, but are you certain that plain was enabled in sasl? It's not enabled by default, you have to explicitly configure it during compile time. That might be why the mismatch. -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc. --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Please help, Perl Module problem.
Neil, open the files in question and modify the four real lines of the script so that you have -I/install/location/lib to where the perl modules are. This has been an ongoing bug that is indecently easy to fix, but Rob won't accept any patches on it. He evidently thinks that installing modules into the sitewide perl installation is the right idea. I believe that it's plain wrong, and want to use the libraries from the cyrus installation. It's a two-line patch, but nobody will accept it. On Thu, Apr 15, 2004 at 02:54:27PM +0100, Neil Marjoram X 663711 wrote: > Thanks for that, I have now recompiled SASL and imap in the default > location, it seems the PREFIX is set in the Perl makefile for imap, and > thus it loads in the Cyrus tree instead of the Perl tree. My recompile > used default locations and now all is installed where I think it should > be. How ever it still does not work. > > Executing the cyradm command now produces this error: > > Can't load > '/usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/auto/Cyrus/IMAP/IMAP.so' for > module Cyrus::IMAP: ld.so.1: perl: fatal: relocation error: file > /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/auto/Cyrus/IMAP/IMAP.so: symbol > db_strerror: referenced symbol not found at > /usr/local/lib/perl5/5.8.0/sun4-solaris/DynaLoader.pm line 229. > at > /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/Cyrus/IMAP/Admin.pm > line 44 > Compilation failed in require at > /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/Cyrus/IMAP/Admin.pm > line 44. > BEGIN failed--compilation aborted at > /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/Cyrus/IMAP/Admin.pm > line 44. > Compilation failed in require at > /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/Cyrus/IMAP/Shell.pm > line 60. > BEGIN failed--compilation aborted at > /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/Cyrus/IMAP/Shell.pm > line 60. > Compilation failed in require. > BEGIN failed--compilation aborted. > > I am still getting this error in the auth.log when I attempt to test the > imap server : > > Apr 15 14:45:35 lowestoft.adastral.ucl.ac.uk imtest[29027]: [ID 702911 > auth.warning] Could not find a dlname line in .la file: libsasldb.la > Apr 15 14:45:35 lowestoft.adastral.ucl.ac.uk imap[29026]: [ID 702911 > auth.notice] Bad IPREMOTEPORT value > Apr 15 14:45:35 lowestoft.adastral.ucl.ac.uk imap[29026]: [ID 702911 > auth.notice] Bad IPLOCALPORT value > Apr 15 14:45:35 lowestoft.adastral.ucl.ac.uk imtest[29027]: [ID 702911 > auth.notice] Bad IPLOCALPORT value > Apr 15 14:47:23 lowestoft.adastral.ucl.ac.uk lmtpunix[29031]: [ID 702911 > auth.warning] Could not find a dlname line in .la file: libsasldb.la > > Anybody any clues ? > > Thanks > > Neil. > > On Thu, 2004-04-15 at 14:21, Heinz Ulrich Stille wrote: > > On Thursday 15 April 2004 12:37, Neil Marjoram X 663711 wrote: > > > I have found the Cyrus Perl module located in the directory I installed > > > cyrus in : /opt/cyrus/lib/perl5/site_perl/5.8.0/sun4-solaris/. How do I > > > get it installed in the Perl tree? > > > > Did you install cyrus imap from a precompiled package? It should be installed > > into the perl tree if you compile it yourself. Alternatively set the perl > > include path (no idea how) or use an utility like "graft" (see freshmeat) to > > symbolically link it there, that's what I do. (I did compile everything > > myself, though, including perl.) > > > > No idea about the .la problem. > > > > MfG, Ulrich > > --- > Cyrus Home Page: http://asg.web.cmu.edu/cyrus > Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu > List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc. --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Please help, Perl Module problem.
cyradm and really any script you run that fails because of the error you listed. And yes, the lines that execute perl. On Fri, Apr 16, 2004 at 09:29:03AM +0100, Neil Marjoram X 663711 wrote: > Joe, > > Thanks for this, can you tell me which files I need to change. I assume > that you mean cyradm and to change the lines that execute the perl > command. > > Thanks, > > Neil. > On Thu, 2004-04-15 at 15:55, Joe Rhett wrote: > > Neil, open the files in question and modify the four real lines of the > > script so that you have -I/install/location/lib to where the perl modules are. > > > > This has been an ongoing bug that is indecently easy to fix, but Rob won't > > accept any patches on it. He evidently thinks that installing modules into > > the sitewide perl installation is the right idea. I believe that it's > > plain wrong, and want to use the libraries from the cyrus installation. > > It's a two-line patch, but nobody will accept it. > > > > On Thu, Apr 15, 2004 at 02:54:27PM +0100, Neil Marjoram X 663711 wrote: > > > Thanks for that, I have now recompiled SASL and imap in the default > > > location, it seems the PREFIX is set in the Perl makefile for imap, and > > > thus it loads in the Cyrus tree instead of the Perl tree. My recompile > > > used default locations and now all is installed where I think it should > > > be. How ever it still does not work. > > > > > > Executing the cyradm command now produces this error: > > > > > > Can't load > > > '/usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/auto/Cyrus/IMAP/IMAP.so' for > > > module Cyrus::IMAP: ld.so.1: perl: fatal: relocation error: file > > > /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/auto/Cyrus/IMAP/IMAP.so: > > > symbol db_strerror: referenced symbol not found at > > > /usr/local/lib/perl5/5.8.0/sun4-solaris/DynaLoader.pm line 229. > > > at > > > /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/Cyrus/IMAP/Admin.pm > > > line 44 > > > Compilation failed in require at > > > /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/Cyrus/IMAP/Admin.pm > > > line 44. > > > BEGIN failed--compilation aborted at > > > /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/Cyrus/IMAP/Admin.pm > > > line 44. > > > Compilation failed in require at > > > /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/Cyrus/IMAP/Shell.pm > > > line 60. > > > BEGIN failed--compilation aborted at > > > /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris/Cyrus/IMAP/Shell.pm > > > line 60. > > > Compilation failed in require. > > > BEGIN failed--compilation aborted. > > > > > > I am still getting this error in the auth.log when I attempt to test the > > > imap server : > > > > > > Apr 15 14:45:35 lowestoft.adastral.ucl.ac.uk imtest[29027]: [ID 702911 > > > auth.warning] Could not find a dlname line in .la file: libsasldb.la > > > Apr 15 14:45:35 lowestoft.adastral.ucl.ac.uk imap[29026]: [ID 702911 > > > auth.notice] Bad IPREMOTEPORT value > > > Apr 15 14:45:35 lowestoft.adastral.ucl.ac.uk imap[29026]: [ID 702911 > > > auth.notice] Bad IPLOCALPORT value > > > Apr 15 14:45:35 lowestoft.adastral.ucl.ac.uk imtest[29027]: [ID 702911 > > > auth.notice] Bad IPLOCALPORT value > > > Apr 15 14:47:23 lowestoft.adastral.ucl.ac.uk lmtpunix[29031]: [ID 702911 > > > auth.warning] Could not find a dlname line in .la file: libsasldb.la > > > > > > Anybody any clues ? > > > > > > Thanks > > > > > > Neil. > > > > > > On Thu, 2004-04-15 at 14:21, Heinz Ulrich Stille wrote: > > > > On Thursday 15 April 2004 12:37, Neil Marjoram X 663711 wrote: > > > > > I have found the Cyrus Perl module located in the directory I installed > > > > > cyrus in : /opt/cyrus/lib/perl5/site_perl/5.8.0/sun4-solaris/. How do I > > > > > get it installed in the Perl tree? > > > > > > > > Did you install cyrus imap from a precompiled package? It should be installed > > > > into the perl tree if you compile it yourself. Alternatively set the perl > > > > include path (no idea how) or use an utility like "graft" (see freshmeat) to > > > > symbolically link it there, that's what I do. (I did compile everything > > > > myself, though, including perl.) > > > > > > > > No idea about the .la problem. > > > > > > > > MfG, Ulrich > > > > > > --- > > > Cyrus Home Page: http://asg.web.cmu.edu/cyrus > > > Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu > > > List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc. --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Please help, Perl Module problem.
There's nothing like coming back to your own words a while later to make you realize what a wining b-otch you sounded like when you said: (more below) > On Thu, 15 Apr 2004, Joe Rhett wrote: > > This has been an ongoing bug that is indecently easy to fix, but Rob won't > > accept any patches on it. He evidently thinks that installing modules into > > the sitewide perl installation is the right idea. I believe that it's > > plain wrong, and want to use the libraries from the cyrus installation. > > It's a two-line patch, but nobody will accept it. On Tue, Apr 20, 2004 at 09:35:19AM -0400, Rob Siemborski wrote: > I just looked through the list archives -- the only patch I see that looks > remotely like this was one that modifies the perl source with autoconf > which as you say in the post is relatively poor. > > Was I missing the cleaner patch that does this all within makemaker? No, mostly because I'm not that good with makemaker. When I wrote the original I was hoping to inspire someone to Do The Right Thing. But after looking at the layout, I'm not sure what you gain -- you'll have to add the Makemaker stuff to the autoconf files, so it's the same amount of changes. But if you will accept a patch that modifies the makemaker stuff, I'll hack one out over the next week or so, just so that we can stop getting the same FAQ from everyone ;-) -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc. --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Please help, Perl Module problem.
> On Tue, 20 Apr 2004, Joe Rhett wrote: > > But if you will accept a patch that modifies the makemaker stuff, I'll hack > > one out over the next week or so, just so that we can stop getting the same > > FAQ from everyone ;-) On Tue, Apr 20, 2004 at 03:37:02PM -0400, Rob Siemborski wrote: > Yes. > > My main concern is running autoconf substitutions on perl scripts sounds > like a good place for all sorts of doom to happen. It's just a proxy thing, because you're pushing the macro into makemaker and then pushing it right onward to the destination file. But I can understand your logic ;-) -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc. --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Please help, Perl Module problem.
I don't think you want or need to include the version or architecture in
your path. And I think you want a space after the I. So try:
x) exec perl -MCyrus::IMAP::Shell -I /usr/lib/perl5/site_perl -e shell -- ${1+"$@"} ;;
And frankly, that path is already probably in your include path (try perl -V)
You probably need to point to your cyrus installation instead. On my
system, it's like this:
x) exec perl -MCyrus::IMAP::Shell -I /opt/imapd/perl -e shell -- ${1+"$@"} ;;
On Fri, May 28, 2004 at 11:00:27AM -0400, Kent L. Nasveschuk wrote:
> This is what I added but I get the same db_version error :(
> I have yet to get this to run, very frustrating. It obviously works
> people use it. I'm so close on this...
>
>
> case "x$BASH_VERSION" in
> x) exec perl -MCyrus::IMAP::Shell
> -I/usr/lib/perl5/site_perl/5.8.0/i486-linux -e shell -- ${1+"$@"} ;;
> *) exec perl -MCyrus::IMAP::Shell
> -I/usr/lib/perl5/site_perl/5.8.0/i486-linux -e shell -- "$@" ;;
> esac
> echo "$0: how did I get here?" >&2
> exit 1
>
>
>
> On Fri, 2004-05-28 at 10:31, Andrew J Caird wrote:
> > On Fri, 28 May 2004, Kent Nasveschuk wrote:
> >
> > > Hello,
> > > You had a perl path problem back in April in cyradm (Cyrus IMAP) that it
> > > seems many people had. I was just wondering if you solved it and exactly
> > > what you did to solve it. I have Cyrus 2.2.4 installed and working on a
> > > test machine with exception of cyradm. Any help would be appreciated,
> > > I'm really beating my head against the wall on this one.
> >
> > Kent,
> > If your problem is truely only a path problem, you might want to try
> > what I do, which is adding:
> > -I/usr/local/cyrus/lib/perl5/site_perl/5.8.3/sun4-solaris to the two
> > "exec perl" lines at the top of cyradm (see below). Of course, if you
> > aren't using solaris or Perl v5.8.3, the last two components of the path
> > will be different for you.
> > Hope this helps.
> > --
> > Andrew Caird
> >
> > -
> > Now the top of cyradm looks like:
> >
> > case "x$BASH_VERSION" in
> > x) exec perl -MCyrus::IMAP::Shell
> > -I/usr/local/cyrus/lib/perl5/site_perl/5.8.3/sun4-solaris -e shell -- ${1+"$@"} ;;
> > *) exec perl -MCyrus::IMAP::Shell
> > -I/usr/local/cyrus/lib/perl5/site_perl/5.8.3/sun4-solaris -e shell -- "$@" ;;
> > esac
> > echo "$0: how did I get here?" >&2
> > exit 1
> --
> Kent L. Nasveschuk <[EMAIL PROTECTED]>
>
> ---
> Cyrus Home Page: http://asg.web.cmu.edu/cyrus
> Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
> List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
--
Joe Rhett Chief Geek
[EMAIL PROTECTED] Isite Services, Inc.
---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: common question - dot in email prefix
unixsephierarchy = yes then just create the mailboxes with the period. On Tue, Oct 26, 2004 at 11:11:17PM -0500, Fred Blaise wrote: > Hello all > > I am sure this question has been asked zillions of time.. I have gone > over the wiki (very quickly I must say) and googled a bit... but please > show indulgence towards the newbie at Cyrus :) > > Is there any way at all to create mailboxes such as user.fname.lname ? > ending up as [EMAIL PROTECTED] ? I kinda read that with the Unix > path separator, it would work, so I tried / and \ before the dot, but > nothing. I must have misunderstood. > > Thank you for your patience :) > > fred > > > > --- > Cyrus Home Page: http://asg.web.cmu.edu/cyrus > Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu > List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html -- Joe Rhett Senior Geek Meer.net --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Global sieve script
On Wed, Oct 27, 2004 at 06:55:01PM +0200, Sascha Wuestemann wrote: > On Mon, Oct 25, 2004 at 12:32:26PM -0500 or thereabouts, Adi Linden wrote: > > Is it possible to have a global sieve script, like /etc/procmailrc, which > > is run before any users sieve scripts? If so, where does it live? > > sorry that I can't answer this question I only wanted to mention that I > am very interested in this, too. Search the archives. Rob has documented this a few times. There's no easy way for users to edit it, but you can do this manually yourself. -- Joe Rhett Senior Geek Meer.net --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: smtp auth + saslauthd + ldap
On Thu, Oct 28, 2004 at 01:11:55PM +0530, Chetan Dutta wrote: > has anybody configured sendmail for smtp auth with saslauthd/pwcheck and > ldap. Which one are you trying? You can't possibly be doing all three... -- Joe Rhett Senior Geek Meer.net --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: cyrus-2.2-cvs: virtualdomains and sendmail virtusertable (cyrusv2 as local mailer)
Don't put the domains in $w, use mailertable and _VIRTUSER_NO_RECURSE_ or whatever the option name is. On Mon, Dec 16, 2002 at 09:32:20AM +0100, Christian Schulte wrote: > Hi, > > after changing the local mailer in my sendmail.mc from cyrus to cyrusv2 > I cannot get sendmail to correctly deliver the domain-part of > local-adresses to cyrusv2-lmtpd! Before, I had the cyrusv2-mailer set in > /etc/mail/mailertable but that way , I was not able to route my email as > I need to and as I do in /etc/mail/virtusertable. Ecspacially > catchall-accounts for domains which have more than one email-account in > cyrus are not possible with the mailertable approach. > > I have all my local domains in /etc/mail/local-host-names and do (want > to do) all email routing in /etc/mail/virtusertable like before. > > If I specify a final recipient (cyrus-account) in virtusertable as: > > @virtualdomain.it [EMAIL PROTECTED] > > where an account like [EMAIL PROTECTED] exists, sendmail > recognizes virtualdomain.it in /etc/mail/local-host-names as a local > domain and will strip the original virtualdomain.it from the recipient > replacing it with the localhost hostname. All domains defined in > /etc/mail/local-host-names will be recognized in virtusertable but the > local delivery will only go to the user@localhostname! > > Where can I change sendmail to not do that ? How do I tell sendmail to > never change the local-domain to the local hostname on succesfully > recognized /etc/mail/local-host-names domains ? > > --Christian-- -- Joe Rhett Chief Geek [EMAIL PROTECTED] ISite Services, Inc.
Re: cyrus-2.2-cvs: virtualdomains and sendmail virtusertable (cyrusv2 as local mailer)
> I hope that documenting how best to configure sendmail for use with > Cyrus 2.2 in virtdomain mode will be part of the documentation cleanup > that preceeds the 2.2 release. If I were sure what "the best" > approach was, I'd happily submit patches to the Cyrus documentation > files describing it. But I keep thinking that someone somewhere > surely knows of a better way than making changes to proto.m4 :-) It's already in the docs for 2.2. -- Joe Rhett Chief Geek [EMAIL PROTECTED] ISite Services, Inc.
Re: cyrus-2.2-cvs: virtualdomains and sendmail virtusertable (cyrusv2 as local mailer)
Christian, I really can't provide basic support for you on this problem. But rest assured that we are doing everything you are trying to do without any modifications to proto.m4. I really think you are over-working the problem. Virtusertable can easily map a name to a local alias (as you suggest), which can then specify names inside the domain on the right hand side. The recursion problem can be solved using define(`_VIRTUSER_STOP_ONE_LEVEL_RECURSION_')dnl in your .mc file. There's no brain surgery here, and your fixes to proto.m4 are just going to cause you more trouble down the road. On Thu, Dec 19, 2002 at 01:46:01PM +0100, Christian Schulte wrote: > >You can't do multiple targets in the virtusertable; to accomplish > >that, you need to create a local alias that expands into the two > >targets, and then have the virtusertable entry map to the alias. For > >example: > > > >>>Virtusertable: > >[EMAIL PROTECTED]alias_x > >[EMAIL PROTECTED]local_a > >[EMAIL PROTECTED]local_b > > > >>>Aliases: > >alias_x:[EMAIL PROTECTED],[EMAIL PROTECTED] > > And that is my problem! The entries alias_x, local_a, local_b are > getting expanded to alias_x@local-host-name etc.. So after processing > virtusertable there will never ever be a user which sendmail recognizes > as being local because of the @local-host-name part and so after > processing virtusertable, aliases will not be expanded any more! I > patched proto.m4 to add the @domain part to every local user so that > cyrusv2 mailer is able to deliver mail! What I now will have to do is to > not add a domain to local users for which an alias entry exists. (These > local-users are not really users but aliases!) I think that will not be > that hard to do, but I had not have enough time to do it right now! By > the way: Do you have a solution for catchall accounts like "@domain > account@domain" ? That is something I really do not want to miss because > all the tons of spam mails now go to the postmaster (me) for all domains > and not to the catchall-accounts! > > But maybe I misunderstood your solution: > > You did not patch anything at all ? You simply deliver mail to > local-users to an entry in the aliases.db and do not have entries for > domains with accounts in virtusertable at all ? > > So you have it like: > > virtusertable: > > @domainlocal_deliver_to_account_at_domain > > aliases: > > local_deliver_to_account_at_domain:account@domain > > Would such a setup work at all ? Would account@domain not beeing > redirected to sendmail itself again and would endup in an infinite loop ? > > > --Christian-- > > > > > > -- Joe Rhett Chief Geek [EMAIL PROTECTED] ISite Services, Inc.
Re: Quota.
> > a quota warning message from the Trash mailbox.Since the IMAP alert does > > not specify the mailbox that the quota warning applies to, the user assumes > > that it is the inbox and continues to try and delete messages until they go .. .. > Ok, so maybe it makes sense to change the message to "over quota in > quotaroot x." This is definately a reasonable change. .. .. > I'll file a bug on amending the quota warnings to include the mailbox name > (of course, this only helps if they ever select the mailbox). Um, can we not use "quotaroot" in the message. Guaranteed to get helpdesk calls on a word that no standard user knows. How about just "over quota in " where xxx is the quota root? Since this matches the mailbox name they are over quota in, it will make sense to the user and still be specific for debugging. -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc.
Re: quota warning problem - Is it a bug of cyrus imap?
On Wed, Jul 02, 2003 at 12:29:41PM -0500, Paul M Fleming wrote: > Rounding error would present a problem for us and our users. My 2 cents > .. quotas > 4GB are fairly rare. I know with a large student user base > with 50-75Mb quotas rounding to the nearest K wouldn't be desirable. Okay, color me confused. Say your mailbox quota is 50mb. Isn't that exactly 51200k? Or do you really need to give some users 5,121,133 byte quotas? Do you really manage your quotas down to less than 1 kilobyte, when you are giving the users 50 megabyte boundaries on the low side? Or am I missing your point entirely? -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc.
Re: Quota.
> > How about just "over quota in " where xxx is the quota root? Since > > this matches the mailbox name they are over quota in, it will make sense to > > the user and still be specific for debugging. > > This isn't perfect either since it is really the entire mailbox hierarchy under the > quota root that is over quota.For example, if you set a quota root on the inbox > and then the user fills up a subfolder of inbox, they may be over quota with no > messages in their inbox at all. If the error message reported is "over quota in > user.joesmith" or "over quota in INBOX", they are still going to call the help > desk.Maybe it should be something like, "over quota in INBOX or a subfolder" Most people will get the idea that subfolders could be the culprit. That's going to generate less helpdesk problems than a word someone doesn't know. ...Having had to fix many error messages of my own that confused me, even though I wrote them to be specific about the problem. I ended up giving up and using ID#s so that people just reported the ID# and didn't write us confused about the text. -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc.
Re: quota warning problem - Is it a bug of cyrus imap?
> >Or do you really need to give some users 5,121,133 byte quotas? Do you > >really manage your quotas down to less than 1 kilobyte, when you are giving > >the users 50 megabyte boundaries on the low side? > >Or am I missing your point entirely? > > > The problem is if you keep only the count of kBytes in a mailbox, what > do you do when you receive a message of 512 bytes? Do you not count it > at all, or do you count it as 1kB? If you keep actual bytes, you still > have the problem of it fitting in a 32-bit number, and if you round it > either way the quota will eventually be so wrong it is useless. I doubt (I may be wrong) that the idea was to round everything -- just the actual quota. So calculate each message normally and then round the total to k to compare against the quota. Since the error of margin could be 1/2 k, with 1 million users you could possibly end up using 500mb more space than you intended if they were all overquota and at the top of the margin of error. I doubt this counts as a significant problem. -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc.
Re: Cyrus 2.2.1-BETA Released
This is still on the 2_2 CVS branch, right? So if we are current with CVS there's nothing new? Or do we need to pull a different branch? On Thu, Jul 17, 2003 at 11:20:20AM -0400, Rob Siemborski wrote: > I'm pleased to announce the release of Cyrus 2.2.1 on ftp.andrew.cmu.edu. > This is a BETA quality release, as it contains significant new > functionality, and a large number of fixes over 2.2.0-ALPHA. > > Feature additions include full r/w ANNOTATEMORE support, and use of > annotations for administrative operations such as generating SQUAT > databases and controlling the expiration of messages. Additionally, the > sieve bytecode now is stored in network byte order and is therefore > portable across architectures. Many features have likewise been added to > Cyrus NNTPd. > > There have been substantial bugfixes in the virtual domain support code, > along with many of the fixes that have been applied to the 2.1 branch > since 2.2.0 was released. > > Please send comments to [EMAIL PROTECTED] (public list), or > [EMAIL PROTECTED] Development issues can be addressed on the > [EMAIL PROTECTED] list. > > You can download this tarball at: > ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.2.1-BETA.tar.gz > or > http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.2.1-BETA.tar.gz > > -Rob > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 > Research Systems Programmer * /usr/contributed Gatekeeper > -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc.
Re: Virtual domains shared folders
You send it to a name of [EMAIL PROTECTED] So if your imapd.conf sets postuser to bb (the old style) then use [EMAIL PROTECTED] If it is blank, use [EMAIL PROTECTED] Note that you may need to convince your mta to keep the plus sign. On Tue, Sep 16, 2003 at 04:57:58PM -0700, Joakim Ryden wrote: > Hey fellas - > > so I've seen some confusion about shared folders and thought I'd check > out what the fuss was all about. ;) > > I've used shared folders very happily and successfully in the past, but > on slightly older installations of Cyrus (this particular installation > is 2.2.1), and obviously never in a virtual domains environment. > > Ok, so what I did was: > > localhost.freebsd.se> cm [EMAIL PROTECTED] > localhost.freebsd.se> sam [EMAIL PROTECTED] anyone lrspi > localhost.freebsd.se> sam [EMAIL PROTECTED] anonymous p > localhost.freebsd.se> lam [EMAIL PROTECTED] > anonymous p > anyone lrspi > > Now, using any IMAP client the folder shows up just fine and everyone > can do what they need to do to it. I cannot for the life of me figure > out how to send mail to this new "folder". The LMTP conversation between > Postfix and Cyrus goes something like (sorry for the crappy wrapping): > > Sep 17 01:53:31 hq postfix/lmtp[19514]: lmtp socket: wanted attribute: > original_recipient > Sep 17 01:53:31 hq postfix/lmtp[19514]: input attribute name: > original_recipient > Sep 17 01:53:31 hq postfix/lmtp[19514]: input attribute value: > [EMAIL PROTECTED] > Sep 17 01:53:31 hq postfix/lmtp[19514]: lmtp socket: wanted attribute: > recipient > Sep 17 01:53:31 hq postfix/lmtp[19514]: input attribute name: recipient > Sep 17 01:53:31 hq postfix/lmtp[19514]: < > /var/imap/socket/lmtp[/var/imap/socket/lmtp]: 250 2.0.0 ok > Sep 17 01:53:31 hq postfix/lmtp[19514]: deliver_message: reusing (count > 1) session with: /var/imap/socket/lmtp > Sep 17 01:53:31 hq postfix/lmtp[19514]: > > /var/imap/socket/lmtp[/var/imap/socket/lmtp]: MAIL > FROM:<[EMAIL PROTECTED]> SIZE=908 > Sep 17 01:53:31 hq postfix/lmtp[19514]: > > /var/imap/socket/lmtp[/var/imap/socket/lmtp]: RCPT > TO:<[EMAIL PROTECTED]> > Sep 17 01:53:31 hq postfix/lmtp[19514]: > > /var/imap/socket/lmtp[/var/imap/socket/lmtp]: DATA > Sep 17 01:53:31 hq postfix/lmtp[19514]: < > /var/imap/socket/lmtp[/var/imap/socket/lmtp]: 250 2.1.0 ok > Sep 17 01:53:31 hq postfix/lmtp[19514]: < > /var/imap/socket/lmtp[/var/imap/socket/lmtp]: 550-Mailbox unknown. > Either there is no mailbox associated with this > Sep 17 01:53:31 hq postfix/lmtp[19514]: < > /var/imap/socket/lmtp[/var/imap/socket/lmtp]: 550-name or you do not > have authorization to see it. > Sep 17 01:53:31 hq postfix/lmtp[19514]: < > /var/imap/socket/lmtp[/var/imap/socket/lmtp]: 550 5.1.1 User unknown > > Did I miss something silly? > > --Jo > -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc.
Summary/Confirmation - RedHat sasl libraries don't work with 2.2.x
I'd like to note for the record (and anyone else searching) that the sasl that ships with Redhat WILL NOT work with 2.2.1. It returns OK with an empty realm. For unknown reasons, Cyrus then returns an "Login failed: can't request info until later in exchange" I'm not sure why Cyrus 2.2.1 is unhappy with the OK response, but it is. As per the only thread I could find on this subject, upgrading to sasl 2.1.15 solved the problem. I left the Redhat plugins and saslauthd in place, just replaced the shared library and it works. So Rob's suggestion was correct. (Sorry, can't find the original thread handy) Can someone with a RedHat contract persuade them to provide updates from 2.1.10-3 to 2.1.15 ? As stated above, I'm just reaffirming this for other searchers. When I'm searching for solutions to problems, I always appreciate finding confirmation that a problem was replicable. -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc.
2.2.1-beta, Redhat 8; lmtpd continuously stuck on select( 0, ...)
Okay, I've had no drama at all getting recent versions of 2.2 to work like
a champ on Solaris, but Redhat appears to be a beast of a different color.
So the imap server is up and running and seems to be working. Squirrelmail
is happy anyway ;-) But delivering mail to the system is hanging. Running
deliver by hand hangs, and stracing deliver shows that it opens the LMTP
socket and then waits for a response.
strace of the running lmtpd process shows only:
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
$ lsof /var/imap/socket/lmtp
COMMAND PID USER FD TYPE DEVICE SIZENODE NAME
master 24362 cyrus 19u unix 0xc3c0a580 3308812 /var/imap/socket/lmtp
lmtpd 24376 cyrus4u unix 0xc3c0a580 3308812 /var/imap/socket/lmtp
The only thing related to this I can find -- and I'm not sure it's related
at all, is:
http://www.irbs.net/internet/info-cyrus/0209/0163.html
I'm happy to debug this, but I need to know what to look for. Tell me what
you need to know.
1. Is there anything about linux iptables that might intercept sockets?
2. What syntax can I put in cyrus.conf run lmtp in debug mode? Or strace?
It does not appear to enjoy "strace lmtpd 2>&1 /tmp/lmtpd.debug" as the
daemon to invoke. Should I make this a script and redirect, or ..?
Also, Ken! I could have swore you put a "-v" in deliver a while back so that we could
watch the LMTP conversation .. or am I misremembering?
--
Joe Rhett Chief Geek
[EMAIL PROTECTED] Isite Services, Inc.
Re: 2.2.1-beta, Redhat 8; lmtpd continuously stuck on select( 0, ...)
On Tue, Sep 30, 2003 at 04:20:04PM -0400, Etienne Goyer wrote: > On Tue, Sep 30, 2003 at 12:15:45PM -0700, Joe Rhett wrote: > > Okay, I've had no drama at all getting recent versions of 2.2 to work like > > a champ on Solaris, but Redhat appears to be a beast of a different color. > > It's red. ;) > > > I'm happy to debug this, but I need to know what to look for. Tell me what > > you need to know. > > Which MTA do you use ? Postfix under RedHat is chroot'ed by default; > you need to configure Postfix to connect to /etc/???, such as : > > mailbox_transport = lmtp:unix:/etc/lmtpproxy > > and create the socket under the chroot jail as /var/spool/postfix/etc/lmttproxy. I've not yet configured an MTA. We're focused on a system injecting messages into IMAP. I'm just using deliver by hand at this point in time. (and also very aware of the postfix chroot situation) Focus on the lmtpd -- what is the select failing on? Is that a lock failing, or the socket itself? -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc.
Re: Summary/Confirmation - RedHat sasl libraries don't work with 2.2.x
Sorry, you are right -- I failed to qualify that. On Wed, Oct 01, 2003 at 08:50:00AM +0200, Simon Matter wrote: > Joe Rhett schrieb: > > > > I'd like to note for the record (and anyone else searching) that the sasl > > that ships with Redhat WILL NOT work with 2.2.1. It returns OK with an > > empty realm. For unknown reasons, Cyrus then returns an > > "Login failed: can't request info until later in exchange" > > > > I'm not sure why Cyrus 2.2.1 is unhappy with the OK response, but it is. > > IIRC this is only the case when authenticating using saslauthd, not when > using sasldb. > > Simon > > > > > As per the only thread I could find on this subject, upgrading to sasl 2.1.15 > > solved the problem. I left the Redhat plugins and saslauthd in place, just > > replaced the shared library and it works. So Rob's suggestion was correct. > > (Sorry, can't find the original thread handy) > > > > Can someone with a RedHat contract persuade them to provide updates from > > 2.1.10-3 to 2.1.15 ? > > > > As stated above, I'm just reaffirming this for other searchers. When I'm > > searching for solutions to problems, I always appreciate finding confirmation > > that a problem was replicable. > > > > -- > > Joe Rhett Chief Geek > > [EMAIL PROTECTED] Isite Services, Inc. -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc.
Re: Using email address as login name
On Fri, Oct 17, 2003 at 09:35:16AM -0500, James A. Pattie wrote: > Paul Kreiner wrote: > | If you want your username to contain an '@' sign, you need to patch SASL to > | make this work, otherwise you'll get '(-13) NO User does not exist' errors or > | something (forget the message off the top of my head). This is because SASL > | internally uses the '@' character to delimit the SASL realm from the > | username, which messes up your authentication scheme. > > Where would I get this patch for SASL? This was the problem I was encountering > and reported last month and no-one mentioned having to patch SASL! Umm.. You don't. I don't know why Kreiner is making budy work for himself, but there's no reason to patch SASL to support double @ signs. Simply make the domain part of the e-mail address be the realm in your authentication method of choice. This is painfully easily ;-) in LDAP and MySQL configurations. I believe you can handle this in sasldb as well with sasl2/program.conf options. -- Joe Rhett Chief Geek [EMAIL PROTECTED] Isite Services, Inc.
Re: Success 2.0.7, SSL, and SASL!
Michael, "Secure Password Authentication" is a not-so-secure Microsoft-Domain-specific form of authentication. It basically means "send this mail server your current authentication token ..." In short, it don't work with Unix servers at all, especially Cyrus. You can disable this, and enable using SSL and everything will be encrypted just fine. On Mon, Dec 04, 2000 at 11:28:42AM -0800, Michael Fair wrote: > > From: "Michael Fair" <[EMAIL PROTECTED]> > > > 4) Microsoft Outlook Express' "Secure Password > > > Authentication" doesn't seem to work with cyrus. > > > It complains about CRAM-MD5 failing and thinks > > > the server doesn't support any authentication > > > that my Windows 98 machine has on it. > > > Anyone got any ideas on this one? > > > > > Oulook Express only supports the LOGIN mechanism, so you need to compile > > SASL with '--enable-login'. > > > > I did this after watching the unencrypted network > traffic and seeing the word LOGIN from the Microsoft > Client before I posted to the group. > I probably should have mentioned that before. > Enabling LOGIN with SASL seems to have made no > difference to the Outlook Express 5.5 client. > Here are my imtest results which show that SASL > is working just fine. > imtest -u test -a test -m LOGIN localhost works. > imtest -u test -a test -m PLAIN localhost does not work. > imtest -u test -a test -t "" -m PLAIN localhost works. > imtest -u test -a test -m CRAM-MD5 localhost works. > imtest -u test -a test -m DIGEST-MD5 localhost works. > > Any other ideas? > > -- Michael -- -- Joe Rhett Chief Technology Officer [EMAIL PROTECTED] ISite Services, Inc. PGP keys and contact information: http://www.noc.isite.net/Staff/
Re: Permission denied when user creates a subfolder
They're probably trying to create it at the same level as their inbox. Tell them to create the subfolder _inside_ their inbox. Remember that "inbox" == "user.username", so the subfolder must be created at "user.username.subfolder", not at the same level - which would be "user". Common mistake. I wish the IMAP clients would default to creating subfolder inside the INBOX, it would save a lot of spurious questions about this. On Wed, Jan 31, 2001 at 02:39:43AM +0100, [EMAIL PROTECTED] wrote: > I've installed cyrus 2.0.9 on a suse linux 7.0 > (I have also tried it on a RedHat 7.0) > All works fine, except when a user (not admin) try to > create a subfolder. > I've tried with manual CREATE command, with python imaplib > and with netscape communicator. > This is not an auth problem (is the same with sasldb or pam auth). > acl on user mailbox are: > lrswipcda > (defaults) > What's Wrong > > Gianluigi Tiesi -- Joe Rhett Chief Technology Officer [EMAIL PROTECTED] ISite Services, Inc. PGP keys and contact information: http://www.noc.isite.net/Staff/
Re: How to add virtual domain support
> I have a suggestion on this subject. What about the possibility of > binding a realm to a local address for cyrus (IP based vhost)? Yes, > authentication and named vhosts via username and realm is ideal, but > given that that information is usually not explicitly send by the > client, if the imap server could assign the realm based on some implicit > information such as the IP address, then there is an answer that should > work while we all wait for more widespread support of SASL realms. If > there was a patch to do this, would it be accepted into CVS? It does mean that you must get an SSL certificate per IP address, if using SSL. This would make other approaches seem better. -- Joe Rhett Chief Technology Officer [EMAIL PROTECTED] ISite Services, Inc. PGP keys and contact information: http://www.noc.isite.net/Staff/
Re: How to add virtual domain support
It's not possible at that level, which is what I was saying. The best way is to have the client log into a single hostname with a single IP (and single matching certificate) but provide domain information during the login. The second, non-scaleable approach is a different configuration per IP address which is now supported, but doesn't scale due the cost of IPs, the cost of certificates, etc etc. On Fri, May 04, 2001 at 02:03:30PM -0400, Todd Nemanich wrote: > Joe Rhett wrote: > > > > > I have a suggestion on this subject. What about the possibility of > > > binding a realm to a local address for cyrus (IP based vhost)? Yes, > > > authentication and named vhosts via username and realm is ideal, but > > > given that that information is usually not explicitly send by the > > > client, if the imap server could assign the realm based on some implicit > > > information such as the IP address, then there is an answer that should > > > work while we all wait for more widespread support of SASL realms. If > > > there was a patch to do this, would it be accepted into CVS? > > > > It does mean that you must get an SSL certificate per IP address, if using > > SSL. This would make other approaches seem better. > > > > Well, this is a little quirky. The client would have to pass their > authentication information or something to indicate their realm prior to > TLS negotiation. As I understand it, there is no real way to do this in > a named virtual host architecture. > The problem here is that the certificate contains the common name of > the mail host. To give an example of this, take a box who's default ip > realm domain1 and a secondary realm vhost is domain2. When a client > connects and does STARTTLS, the server does not know which realm they > are trying to use yet (since no authentication information has been > passed yet). So it passes the default certificate containing the common > name host.domain1. When the client recieves this certificate, it should > reject the certificate, or at least inform the user that the certificate > is for host.domain1, not host.domain2. If you have an alternative answer > to using IP vhosts for doing SSL, I would love to hear any thoughts on > how. > -- > Todd Nemanich [EMAIL PROTECTED] > > "Protecting the opulent and staging moral standard, > They expect redemption of character and self growth" > Bad Religion - Inner Logic -- Joe Rhett Chief Technology Officer [EMAIL PROTECTED] ISite Services, Inc. PGP keys and contact information: http://www.noc.isite.net/Staff/
Re: How to add virtual domain support
> > The best way is to have the client log into a single hostname with a single > > IP (and single matching certificate) but provide domain information during > > the login. > > This is indeed a better idea, which already has been discussed. My > opinion is that the server should have the option to implicitly set it's > realm information, since you don't always have the information you need > from the client to set the realm. If you don't like it, don't use it. :) > The main point of this is to actually get some virtual hosting within a > single mailstore. The use_ip_as_realm patch will provide most of the > changes needed to do either named or ip vhosts, primarily how > information (mailboxes, acls, message flags, etc) is seperated across > realms so you can have bob@realm1 and bob@realm2 who are different > users. Changing the realm won't resolve name conflicts within the message store. -- Joe Rhett Chief Technology Officer [EMAIL PROTECTED] ISite Services, Inc. PGP keys and contact information: http://www.noc.isite.net/Staff/
Re: How to add virtual domain support
> > > I have a suggestion on this subject. What about the possibility of > > > binding a realm to a local address for cyrus (IP based vhost)? Yes, > > > authentication and named vhosts via username and realm is ideal, but > > > given that that information is usually not explicitly send by the > > > client, if the imap server could assign the realm based on some implicit > > > information such as the IP address, then there is an answer that should > > > work while we all wait for more widespread support of SASL realms. If > > > there was a patch to do this, would it be accepted into CVS? > > > > It does mean that you must get an SSL certificate per IP address, if using > > SSL. This would make other approaches seem better. > > Joe, SASL is not SSL. *plonk* If you have a different DNS name & IP address for each virtual domain, you'll need a different SSL certificate for each one or the browser will complain upon establishing a connection -- long before SASL issues are relevant. Note that I did specify "if using SSL". So I'll deny your *plonk*, and raise you one kiddo. Pay attention! -- Joe Rhett Chief Technology Officer [EMAIL PROTECTED] ISite Services, Inc. PGP keys and contact information: http://www.noc.isite.net/Staff/
