Re: Cyrus 2.3.13 RC3
On 13 Oct 2008, at 16:42, Rosenbaum, Larry M. wrote: > That fixed it. Thanks. Sure, please respond to the list so someone finding your original question can get the correct answer as well. Thanks! :wes Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
RE: Cyrus 2.3.13 RC3
> From: Wesley Craig [mailto:[EMAIL PROTECTED] > > Try --without-gssapi. > Sorry, it's actually --disable-gssapi. That fixed it. Thanks. > :wes > > On 13 Oct 2008, at 15:45, Larry Rosenbaum wrote: > > I can't get it to build. I get the following: > > > > gcc -c -I.. -I/usr/local/BerkeleyDB.4.2/include -I/usr/local/ssl/ > > include > > -I../com_err/et -I/usr/local/include -DHAVE_CONFIG_H -g -O2 \ > > auth_krb5.c > > auth_krb5.c:60:18: krb5.h: No such file or directory > > > > I'm not interested in using Kerberos. I tried --without-krb but > > got the > > same error. What do I need to change? I am on Solaris 9 SPARC. > > Here is > > the configure input and output: Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
RE: Cyrus 2.3.13 RC3
> From: Wesley Craig [mailto:[EMAIL PROTECTED] > > Try --without-gssapi. Thanks, but that didn't help. > :wes > > On 13 Oct 2008, at 15:45, Larry Rosenbaum wrote: > > I can't get it to build. I get the following: > > > > gcc -c -I.. -I/usr/local/BerkeleyDB.4.2/include -I/usr/local/ssl/ > > include > > -I../com_err/et -I/usr/local/include -DHAVE_CONFIG_H -g -O2 \ > > auth_krb5.c > > auth_krb5.c:60:18: krb5.h: No such file or directory > > > > I'm not interested in using Kerberos. I tried --without-krb but > > got the > > same error. What do I need to change? I am on Solaris 9 SPARC. > > Here is > > the configure input and output: Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus 2.3.13 RC3
Try --without-gssapi. :wes On 13 Oct 2008, at 15:45, Larry Rosenbaum wrote: > I can't get it to build. I get the following: > > gcc -c -I.. -I/usr/local/BerkeleyDB.4.2/include -I/usr/local/ssl/ > include > -I../com_err/et -I/usr/local/include -DHAVE_CONFIG_H -g -O2 \ > auth_krb5.c > auth_krb5.c:60:18: krb5.h: No such file or directory > > I'm not interested in using Kerberos. I tried --without-krb but > got the > same error. What do I need to change? I am on Solaris 9 SPARC. > Here is > the configure input and output: Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
RE: Cyrus 2.3.13 RC3
I can't get it to build. I get the following: gcc -c -I.. -I/usr/local/BerkeleyDB.4.2/include -I/usr/local/ssl/include -I../com_err/et -I/usr/local/include -DHAVE_CONFIG_H -g -O2 \ auth_krb5.c auth_krb5.c:60:18: krb5.h: No such file or directory auth_krb5.c: In function `mycanonifyid': auth_krb5.c:104: error: `krb5_context' undeclared (first use in this function) auth_krb5.c:104: error: (Each undeclared identifier is reported only once auth_krb5.c:104: error: for each function it appears in.) auth_krb5.c:104: error: syntax error before "context" auth_krb5.c:105: error: `krb5_principal' undeclared (first use in this function) auth_krb5.c:121: error: `context' undeclared (first use in this function) auth_krb5.c:124: error: `princ' undeclared (first use in this function) auth_krb5.c:139: error: `princ_dummy' undeclared (first use in this function) gmake[1]: *** [auth_krb5.o] Error 1 gmake[1]: Leaving directory `/usr/local/src/cyrus/cyrus-imapd-2.3.13rc3/lib' I'm not interested in using Kerberos. I tried --without-krb but got the same error. What do I need to change? I am on Solaris 9 SPARC. Here is the configure input and output: CC=gcc LDFLAGS="-L/usr/local/lib -R/usr/local/lib" \ ./configure \ --enable-idled \ --without-krb \ --with-cyrus-prefix=/usr/local/cyrus \ --with-dbdir=/usr/local/BerkeleyDB.4.2 \ --with-openssl=/usr/local/ssl \ --with-sasl=/usr/local checking build system type... sparc-sun-solaris2.9 checking host system type... sparc-sun-solaris2.9 checking for makedepend... makedepend checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for ranlib... ranlib checking whether make sets $(MAKE)... yes checking for a BSD-compatible install... ./install-sh -c checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /usr/xpg4/bin/grep checking for egrep... /usr/xpg4/bin/grep -E checking for AIX... no checking for library containing strerror... none required checking for gawk... no checking for mawk... no checking for nawk... nawk checking for an ANSI C-conforming const... yes checking for long file names... yes checking for inline... inline checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... no checking for unistd.h... yes checking for int... yes checking size of int... 4 checking for long... yes checking size of long... 4 checking for size_t... yes checking size of size_t... 4 checking for off_t... yes checking size of off_t... 4 checking for long long int... yes checking size of long long int... 8 checking for unsigned long long int... yes checking size of unsigned long long int... 8 checking whether byte ordering is bigendian... yes checking for __attribute__... yes checking if compiler supports -fPIC... yes checking for runpath switch... -R checking for unistd.h... (cached) yes checking sys/select.h usability... yes checking sys/select.h presence... yes checking for sys/select.h... yes checking sys/param.h usability... yes checking sys/param.h presence... yes checking for sys/param.h... yes checking stdarg.h usability... yes checking stdarg.h presence... yes checking for stdarg.h... yes checking for memmove... yes checking for strcasecmp... yes checking for ftruncate... yes checking for strerror... yes checking for strlcat... yes checking for strlcpy... yes checking for getgrouplist... no checking for dirent.h that defines DIR... yes checking for library containing opendir... none required checking for connect... no checking for gethostbyname in -lnsl... yes checking for connect in -lsocket... yes checking for res_search... no checking for dn_expand... yes checking for dns_lookup... no checking for getaddrinfo... yes checking for gai_strerror... yes checking for getnameinfo... yes checking whether you have ss_family in struct sockaddr_storage... yes checking whether you have sa_len in struct sockaddr... no checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking whether time.h and sys/time.h may both be included... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for struct tm.tm_zone... no checking whether tzname is declared... yes checking for tzname... yes checking for vprintf... yes checking for _doprnt... yes checking db.h usability... yes checking db.h presence... yes checking for db.h... yes checking for bison... no checking for byacc... no checking for flex... no chec
Re: Problems with frontend to backend authentication in murder 2.3.12
Matt Selsky wrote: > > On Oct 13, 2008, at 12:44 PM, Nic Bernstein wrote: > >> Wesley Craig wrote: >>> >>> On 03 Oct 2008, at 04:31, Simon Matter wrote: Any update on this issue? I'm wondering whether the patch will go into 2.3.13? >>> >>> Nic and I are still talking. This patch will likely be applied >>> after 2.3.13 is released. We've already made "last call" for >>> 2.3.13. I did find a bug in the version Nic tried, so if you're >>> messing with it, you should get it again. >>> >>> :wes >> I wanted to follow up to the list on this issue so that others may >> learn from my experience. The issue here was one of poor >> documentation and confusing examples rather than a software bug. >> >> The configuration in question involves numerous hosts on a >> geographically diverse WAN with similar systems in multiple >> locations. Frontends in these locations are named >> imap.xx.example.com and backends are called mailbox.xx.example.com, >> where xx is a two letter state or country code. For purposes of >> configuring cyrus imapd to use the correct mechanisms and passwords >> with these numerous systems the hostname_mechs and hostname_password >> configuration elements were used. >> >> The documentation (man page) for imapd.conf states: >> hostname_password: >> The password to use for authentication to the backend >> server host- >> name (where hostname is the short hostname of the server) >> - Cyrus >> Murder >> Short hostname is a somewhat ambiguous term. There are many examples >> floating around on the web, in mailing lists, etc. in which people >> define the hostname_password and hostname_mechs settings for >> multipart hostnames, such as imap.wi, by using an underscore (_) >> character, like so: imap_wi, since everything to the right of a >> period (.) in these settings would otherwise be discarded by the parser. >> >> My error was that I trusted these examples, and followed them in my >> configurations. Thus I had mailbox_wi_password and mailbox_wi_mechs >> settings, which were simply ignored by the software, as it ignored >> everything after the the first dot when looking for passwords, and >> not finding an entry for, say mailbox_password, it failed the >> authentication. >> >> So, since my hostnames are not unique in their "short hostname" (I >> will have eight systems named "mailbox" and eight named "imap" by >> this definition) I am not allowed to define unique passwords or >> mechanisms. I have fallen back to using common passwords for all >> hosts and the "proxy_password" setting. >> >> I must confess that I see this as a somewhat capricious limitation of >> the software, frustrated by the vague documentation and lack of >> debugging information. In this case the error logged was "no worthy >> mechanisms" which led to a wild goose chase for a mechanism problem >> when in fact the problem was that no password was being defined. >> >> I hope that the software is changed to allow for FQDNs to be defined >> for these host specific configuration variables. The limitation of >> only allowing "short hostnames" seems baseless. I also hope that the >> wiki is enhanced with more specific examples of murder configurations >> which show how these various settings interact. It is frustrating to >> waste so much time on configuration issues like this simply because >> of the dearth of good clear examples, and the proliferation of bad >> examples on the web. >> >> For example, a search for murder configurations on Google will turn >> up many examples with "mupdate_admins" when this is not actually a >> configuration setting used by cyrus imapd. When the only examples >> around are erroneous, errors will proliferate. >> >> I will be glad to offer up some concrete working examples with >> explanations once my own implementation is complete, and would be >> glad to contribute them to the wiki. Is there any consensus as to >> where such documentation should go on the wiki? >> >> Much thanks are due to Wesley Craig for his patience and assistance >> in tracking down the answer to this problem. >> >> Thanks again, Wes. > > Nic, glad to hear you have things working. > > Can you open bugs in bugzilla for the places where the documentation > is confusing, so we can track these properly? I have just done so. Thanks for the tip. -nic -- Nic Bernstein [EMAIL PROTECTED] Onlight llc. www.onlight.com 2266 North Prospect Avenue #610 v. 414.272.4477 Milwaukee, Wisconsin 53202-6306 f. 414.290.0335 Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: IMAP account used for multiple users
Jason Voorhees wrote, at 10/13/2008 01:58 PM: > A simple question: > Is there any kind of problem if a unique IMAP account is used by more > than one client at the same time? It can be done... > I'm thinking to give access to all my users (up to 90 users) trough MS > Outlook to a unique IMAP account. ...but not with Outlook. I should be fair, and state that any special features of any client can cause problems, along with the issues that simply come from everyone playing in the same sandbox. For example, all it takes is one user to set aggressive (or use poorly trained) junk filtering to wreak a bit of havoc for everyone. Nonetheless, Cyrus does allow concurrent read/write access, which is handy for users that access webmail while leaving desktop clients running. The extra burden with Outlook comes from its monolothic approach that allows email to trigger a variety of events. When I evaluated sharing an account with Outlook 2007, it didn't seem wise due to the ease with which another user can affect your todo list, calendar, and god knows what else. Outlook is really a personal organizer, and should be kept personal, IMHO. > I don't plan to use suscribed folders instead for simplicity reasons. A broadcast alias or mailing list is often better. Or go with a full-blown issue tracker, if that's what you're really trying to do. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Problems with frontend to backend authentication in murder 2.3.12
On Oct 13, 2008, at 12:44 PM, Nic Bernstein wrote: > Wesley Craig wrote: >> >> On 03 Oct 2008, at 04:31, Simon Matter wrote: >>> Any update on this issue? I'm wondering whether the patch will go >>> into >>> 2.3.13? >> >> Nic and I are still talking. This patch will likely be applied >> after 2.3.13 is released. We've already made "last call" for >> 2.3.13. I did find a bug in the version Nic tried, so if you're >> messing with it, you should get it again. >> >> :wes > I wanted to follow up to the list on this issue so that others may > learn from my experience. The issue here was one of poor > documentation and confusing examples rather than a software bug. > > The configuration in question involves numerous hosts on a > geographically diverse WAN with similar systems in multiple > locations. Frontends in these locations are named > imap.xx.example.com and backends are called mailbox.xx.example.com, > where xx is a two letter state or country code. For purposes of > configuring cyrus imapd to use the correct mechanisms and passwords > with these numerous systems the hostname_mechs and hostname_password > configuration elements were used. > > The documentation (man page) for imapd.conf states: > hostname_password: > The password to use for authentication to the backend > server host- > name (where hostname is the short hostname of the > server) - Cyrus > Murder > Short hostname is a somewhat ambiguous term. There are many > examples floating around on the web, in mailing lists, etc. in which > people define the hostname_password and hostname_mechs settings for > multipart hostnames, such as imap.wi, by using an underscore (_) > character, like so: imap_wi, since everything to the right of a > period (.) in these settings would otherwise be discarded by the > parser. > > My error was that I trusted these examples, and followed them in my > configurations. Thus I had mailbox_wi_password and mailbox_wi_mechs > settings, which were simply ignored by the software, as it ignored > everything after the the first dot when looking for passwords, and > not finding an entry for, say mailbox_password, it failed the > authentication. > > So, since my hostnames are not unique in their "short hostname" (I > will have eight systems named "mailbox" and eight named "imap" by > this definition) I am not allowed to define unique passwords or > mechanisms. I have fallen back to using common passwords for all > hosts and the "proxy_password" setting. > > I must confess that I see this as a somewhat capricious limitation > of the software, frustrated by the vague documentation and lack of > debugging information. In this case the error logged was "no worthy > mechanisms" which led to a wild goose chase for a mechanism problem > when in fact the problem was that no password was being defined. > > I hope that the software is changed to allow for FQDNs to be defined > for these host specific configuration variables. The limitation of > only allowing "short hostnames" seems baseless. I also hope that > the wiki is enhanced with more specific examples of murder > configurations which show how these various settings interact. It > is frustrating to waste so much time on configuration issues like > this simply because of the dearth of good clear examples, and the > proliferation of bad examples on the web. > > For example, a search for murder configurations on Google will turn > up many examples with "mupdate_admins" when this is not actually a > configuration setting used by cyrus imapd. When the only examples > around are erroneous, errors will proliferate. > > I will be glad to offer up some concrete working examples with > explanations once my own implementation is complete, and would be > glad to contribute them to the wiki. Is there any consensus as to > where such documentation should go on the wiki? > > Much thanks are due to Wesley Craig for his patience and assistance > in tracking down the answer to this problem. > > Thanks again, Wes. Nic, glad to hear you have things working. Can you open bugs in bugzilla for the places where the documentation is confusing, so we can track these properly? -- Matt Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: IMAP account used for multiple users
--On Monday, October 13, 2008 12:58 -0500 Jason Voorhees <[EMAIL PROTECTED]> wrote: > Hi all: > > A simple question: > Is there any kind of problem if a unique IMAP account is used by more > than one client at the same time? > I'm thinking to give access to all my users (up to 90 users) trough MS > Outlook to a unique IMAP account. > I hope you mean that they would each log in with their own account, and share the same folder. That should work. If not, various problems might arise. Off the top of my head: -- Anybody could delete and expunge, or, nobody can. -- They can't keep track of what messages each person has seen. -- Somebody might POP the mailbox and remove everything. Joseph Brennan Columbia University Information Technology Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
IMAP account used for multiple users
Hi all: A simple question: Is there any kind of problem if a unique IMAP account is used by more than one client at the same time? I'm thinking to give access to all my users (up to 90 users) trough MS Outlook to a unique IMAP account. I don't plan to use suscribed folders instead for simplicity reasons. Thanks, bytes! Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Problems with frontend to backend authentication in murder 2.3.12
Wesley Craig wrote: On 03 Oct 2008, at 04:31, Simon Matter wrote: Any update on this issue? I'm wondering whether the patch will go into 2.3.13? Nic and I are still talking. This patch will likely be applied after 2.3.13 is released. We've already made "last call" for 2.3.13. I did find a bug in the version Nic tried, so if you're messing with it, you should get it again. :wes I wanted to follow up to the list on this issue so that others may learn from my experience. The issue here was one of poor documentation and confusing examples rather than a software bug. The configuration in question involves numerous hosts on a geographically diverse WAN with similar systems in multiple locations. Frontends in these locations are named imap.xx.example.com and backends are called mailbox.xx.example.com, where xx is a two letter state or country code. For purposes of configuring cyrus imapd to use the correct mechanisms and passwords with these numerous systems the hostname_mechs and hostname_password configuration elements were used. The documentation (man page) for imapd.conf states: hostname_password: The password to use for authentication to the backend server host- name (where hostname is the short hostname of the server) - Cyrus Murder Short hostname is a somewhat ambiguous term. There are many examples floating around on the web, in mailing lists, etc. in which people define the hostname_password and hostname_mechs settings for multipart hostnames, such as imap.wi, by using an underscore (_) character, like so: imap_wi, since everything to the right of a period (.) in these settings would otherwise be discarded by the parser. My error was that I trusted these examples, and followed them in my configurations. Thus I had mailbox_wi_password and mailbox_wi_mechs settings, which were simply ignored by the software, as it ignored everything after the the first dot when looking for passwords, and not finding an entry for, say mailbox_password, it failed the authentication. So, since my hostnames are not unique in their "short hostname" (I will have eight systems named "mailbox" and eight named "imap" by this definition) I am not allowed to define unique passwords or mechanisms. I have fallen back to using common passwords for all hosts and the "proxy_password" setting. I must confess that I see this as a somewhat capricious limitation of the software, frustrated by the vague documentation and lack of debugging information. In this case the error logged was "no worthy mechanisms" which led to a wild goose chase for a mechanism problem when in fact the problem was that no password was being defined. I hope that the software is changed to allow for FQDNs to be defined for these host specific configuration variables. The limitation of only allowing "short hostnames" seems baseless. I also hope that the wiki is enhanced with more specific examples of murder configurations which show how these various settings interact. It is frustrating to waste so much time on configuration issues like this simply because of the dearth of good clear examples, and the proliferation of bad examples on the web. For example, a search for murder configurations on Google will turn up many examples with "mupdate_admins" when this is not actually a configuration setting used by cyrus imapd. When the only examples around are erroneous, errors will proliferate. I will be glad to offer up some concrete working examples with explanations once my own implementation is complete, and would be glad to contribute them to the wiki. Is there any consensus as to where such documentation should go on the wiki? Much thanks are due to Wesley Craig for his patience and assistance in tracking down the answer to this problem. Thanks again, Wes. Cheers, -nic -- Nic Bernstein [EMAIL PROTECTED] Onlight llc. www.onlight.com 2266 North Prospect Avenue #610 v. 414.272.4477 Milwaukee, Wisconsin 53202-6306 f. 414.290.0335 Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
user groups
Hello, don't know if this is a stupid question or if it's something I can achieve with Virtual Domains on Cyrus. I'd like to know if there is a simple solution to my standard installation of Cyrus. Using ACLs I can have IMAP users see a "user" folder containing shared mailboxes. Now, I have to create a new group of users that pertains to a specific group. I'd like to be able to share their mailboxes to other users, having them aggregated into a different folder than "user", so that other users may easily see normal users under "user" and these special users under another name. Is it possible? Thanx for any help, Gabriele Bulfon. Gabriele Bulfon - Sonicle S.r.l. Tel +39 028246016 Int. 30 - Fax +39 028243880 Via Felice Cavallotti 16 - 20089, Rozzano - Milano - ITALY http://www.sonicle.com Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
