squatter
More information : squatter is not able to index mailboxes on virtual domain !! they interpret the "." of the domain name as a separator and substitute it !! example : su cyrus squatter -r -v user/[EMAIL PROTECTED] error opening [EMAIL PROTECTED]: Mailbox does not exist May be a bug in 2.2 code ?? vittorio - This mail sent through IMP: http://horde.org/imp/
squatter
I use cyrus-imapd-2.2 from cvs on my system, all goes fine, but when I tried to use squatter on a user I receive the following error : SQUAT: Unknown error 1 (Closing index) I used this command : su cyrus /usr/cyrus/bin/squater -r user/ Any idea ? Thanks vittorio - This mail sent through IMP: http://horde.org/imp/
Re: Sieve help
pnelson wrote: On Fri, 2003-06-06 at 10:29, Ken Murchison wrote: Patrick Nelson wrote: Running Cyrus-imap 2.1.13 on RH9 and alls well. Moved the whole company off of exchange a week ago and so far not even a hickup. So, now I want to explore sieve, but I'm not sure where to begin. Is there any good docs you all would recommend. Or maybe highlight to me your course of knowledge on this? For writing scripts or configuring Cyrus to handle them? For authoring, this might be the best place to start. http://www.cyrusoft.com/sieve/ For setup, the Cyrus docs _should_ be enough to get you started. Have sieve working but the cyrusoft sites sieve docs are kind of lacking. Anyone else know of a good ole' howto on the syntax of sieve? There isn't much. The best docs are the RFCs and IDs themselves. They are all listed on the doc/specs.html page in the distro. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: Sieve help
On Fri, 2003-06-06 at 10:29, Ken Murchison wrote: > Patrick Nelson wrote: > > Running Cyrus-imap 2.1.13 on RH9 and alls well. Moved the whole company > > off of exchange a week ago and so far not even a hickup. > > > > So, now I want to explore sieve, but I'm not sure where to begin. Is > > there any good docs you all would recommend. Or maybe highlight to me > > your course of knowledge on this? > > For writing scripts or configuring Cyrus to handle them? > > > For authoring, this might be the best place to start. > > http://www.cyrusoft.com/sieve/ > > > For setup, the Cyrus docs _should_ be enough to get you started. Have sieve working but the cyrusoft sites sieve docs are kind of lacking. Anyone else know of a good ole' howto on the syntax of sieve?
Re: Linking imapd with db-4.1.25
QUESTION: Does the Berkeley 4.1.25 database not like the version of POSIX threads in Linux Mandrake 9.1, but is happy with the NGPT in Redhat 9.0? I ask because when I built Cyrus-IMAP 2.1.12 against the db4.1 libs on Mandrake 9.1, I ran into the problem described below: / On a Mandrkake 9.1 installation on a Athlon system, I configured Berkely db-4.1.25NC like so, all on one line: env LDFLAGS="-lpthread" ../dist/configure --enable-posixmutexes --enable-cxx --enable-test --enable-rpc --enable-tcl -with-tcl=/usr/lib --prefix=/usr I noticed this in the output of configure, though: ./build_unix/config.log:configure:17731: result: POSIX/pthreads/private And subsequently, my build of cyrus-IMAP 2.1.13 linked against this db-4.1.25, yielded these messages in /var/log/syslog when I started: Jun 10 17:25:49 ns1 ctl_cyrusdb[10682]: recovering cyrus databases Jun 10 17:25:49 ns1 ctl_cyrusdb[10682]: DBERROR db4: Berkeley DB library configured to support only DB_PRIVATE environments Jun 10 17:25:49 ns1 ctl_cyrusdb[10682]: DBERROR: dbenv->open '/var/lib/imap/db' failed: Invalid argument Looking through the changelog for Berkeley DB 4.1.24, I found: 2. Support configuration of POSIX pthread mutexes on systems where the pthread mutexes do not support inter-process locks. [#4942] And then in the Berkeley DB Reference Guide, there is: DB_PRIVATE Specify that the environment will only be accessed by a single process (although that process may be multithreaded). This flag has two effects on the Berkeley DB environment. First, all underlying data structures are allocated from per-process memory instead of from shared memory that is potentially accessible to more than a single process. Second, mutexes are only configured to work between threads. This flag should not be specified if more than a single process is accessing the environment because it is likely to cause database corruption and unpredictable behavior. For example, if both a server application and the Berkeley DB utility db_stat are expected to access the environment, the DB_PRIVATE flag should not be specified. -- Scott Langley [EMAIL PROTECTED] Systems Administrator Rural Network Services
Re: Cant get sieve working [SOLVED]
On Fri, 2003-06-13 at 16:03, Ken Murchison wrote: > pnelson wrote: > > On Fri, 2003-06-13 at 15:38, Wil Cooley wrote: > > > >>On Fri, 2003-06-13 at 14:55, pnelson wrote: > >> > >> > >>>require "fileinto"; > >>>if header :contains "Subject" "test" { > >>> fileinto "INBOX.test; > >> > >> ^ You probably want a '"' here. > >> > > > > > > Oops email typo... the script has it in there. > > > > I am using unixhierarchysep so that names can handle the dot, maybe that > > might be a problem? On my mailbox I don't have dots but others do. > > If you're using unixhiersep, then you probably want INBOX/test > I had thought about unixhierarchysep, but didn't know how to get around it. Thanks Ken... That did the trick and now it's working like a charm.
Re: Cant get sieve working
pnelson wrote: On Fri, 2003-06-13 at 15:38, Wil Cooley wrote: On Fri, 2003-06-13 at 14:55, pnelson wrote: require "fileinto"; if header :contains "Subject" "test" { fileinto "INBOX.test; ^ You probably want a '"' here. Oops email typo... the script has it in there. I am using unixhierarchysep so that names can handle the dot, maybe that might be a problem? On my mailbox I don't have dots but others do. If you're using unixhiersep, then you probably want INBOX/test -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: Cant get sieve working
On Fri, 2003-06-13 at 15:38, Wil Cooley wrote: > On Fri, 2003-06-13 at 14:55, pnelson wrote: > > > require "fileinto"; > > if header :contains "Subject" "test" { > > fileinto "INBOX.test; >^ You probably want a '"' here. > Oops email typo... the script has it in there. I am using unixhierarchysep so that names can handle the dot, maybe that might be a problem? On my mailbox I don't have dots but others do.
Re: Cant get sieve working
On Fri, 2003-06-13 at 14:55, pnelson wrote: > require "fileinto"; > if header :contains "Subject" "test" { > fileinto "INBOX.test; ^ You probably want a '"' here. Wil -- Wil Cooley [EMAIL PROTECTED] Naked Ape Consultinghttp://nakedape.cc * * * * Linux, UNIX, Networking and Security Solutions * * * * * Tired of spam and viruses in your e-mail? Get the * * Naked Ape Mail Defender! http://nakedape.cc/r/maildefender * signature.asc Description: This is a digitally signed message part
Re: Cant get sieve working
On Fri, 2003-06-13 at 15:11, Carl P. Corliss wrote: > What version of Cyrus are you using? > > On Friday 13 June 2003 03:55 pm, pnelson wrote: > > Have Cyrus-imap working great and can... > > > > sieveshell -u pnelson -a pnelson localhost > > > > then: > > >put test.siqeve > > >activate test.sieve > > >list > > > > test.sieve <- active script > > > > The test.sieve is simply: > > > > require "fileinto"; > > if header :contains "Subject" "test" { > > fileinto "INBOX.test; > > } > > > > INBOX.test does exist. But when I send a manual message using telnet > > with the correct subject line it doesn't appear to use the script. > > > > The mail arrives in my inbox not my INBOX.test folder. Any ideas on how > > to get this working or configured correctly? cyrus-imap v2.1.13
problems using mailutil to move messages from Groupwise to Cyrus
Original Message We've been happily running a cyrus mail server for several years. Lately we've been attempting to migrate our Groupwise users from the dark side over to our IMAP server. This seemed straightforward enough. We're using imaputil to move the Groupwise mailboxes over, but have run into some issues (probably caused by the Groupwise IMAP server). Cyrus 2.1.10 IMAP server When we move the mailboxes with mailutil transfer -debug {adngate.adn.uwrf.edu} {biff.servers.uwrf.edu}INBOX.GW. most of the mail messages move over fine, but some generate a whole slug of errrors, and are not moved. As an example: + go ahead IMAP protocol error: STORE 1 Command, State, or Parameter STORE 1 Command, State, or Parameter () "13-Jun-2003 08:48:41 -0500" {1851} + go ahead IMAP protocol error: STORE 1 Command, State, or Parameter STORE 1 Command, State, or Parameter (\Seen) "13-Jun-2003 08:54:18 -0500" {2521} + go ahead (\Seen) "13-Jun-2003 08:54:19 -0500" {2555} + go ahead (\Seen) "13-Jun-2003 09:14:42 -0500" {2852} + go ahead (\Seen) "13-Jun-2003 09:14:45 -0500" {2886} + go ahead IMAP protocol error: STORE 1 Command, State, or Parameter STORE 1 Command, State, or Parameter () "13-Jun-2003 09:21:25 -0500" {5489} + go ahead I'm not quite sure what I'm suppsed to divine from this - I don't see anyting that jumps out at me here. What are the numbers in the curly braces??? -- Steve Hanson UW River Falls ITS 715-425-4357
Cant get sieve working
Have Cyrus-imap working great and can... sieveshell -u pnelson -a pnelson localhost then: >put test.siqeve >activate test.sieve >list test.sieve <- active script The test.sieve is simply: require "fileinto"; if header :contains "Subject" "test" { fileinto "INBOX.test; } INBOX.test does exist. But when I send a manual message using telnet with the correct subject line it doesn't appear to use the script. The mail arrives in my inbox not my INBOX.test folder. Any ideas on how to get this working or configured correctly?
Re: Cyrus Backup Strategy
pnelson wrote: Yes dumping to removable medium. Why not write directly to tape rather than going through an extra step and requiring extra disk space? So a cyrus backup needs to contain: /var/spool/imap /var/lib/imap/mailboxes.db to be useful as a backup, right? With these to things I can recover... I'm making sure I understand this completely. You need to backup all of /var/spool/imap and /var/lib/imap. Some parts are less critical, but they are small anyway so you shouldn't try and leave out parts of it. How do you dump mailboxes to/from text? From cron as user cyrus, ctl_mboxlist -d >/var/lib/imap/mailboxes.txt What is the restore process? That gets a bit more fun. Our policy is to do restores for users at the folder level (assuming a user error restore -- a dead disk restore is easy, just restore everything). We create a RESTORE folder under the user's mailbox, set a quota on it, then restore all the message files and cyrus.* files from the folder to be recovered into that directory. Then run reconstruct on user/joe/RESTORE, and let them do what they want with the messages there. The RESTORE folder is automatically deleted 2 weeks later. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
Re: Cyrus Backup Strategy
On Fri, 13 Jun 2003, pnelson wrote: > On Fri, 2003-06-13 at 12:11, Igor Brezac wrote: > > On Fri, 13 Jun 2003, pnelson wrote: > > > > > On Fri, 2003-06-13 at 11:29, John Alton Tamplin wrote: > > > > pnelson wrote: > > > > > > > > >My last thing to do prior to converting to production is a backup > > > > >strategy. I have been doing this with tar something like: > > > > > > > > > >tar -C /var/lib-czf lib-.tar.gzimap > > > > >tar -C /var/spool -czf spool-.tar.gz imap > > > > >tar -cf cyrus-.tar > > > > > > > > > >This is producing a pretty big file(s): > > > > > > > > > > lib-.tar.gz-> 2.2M > > > > > spool-.tar.gz -> 11.0M > > > > > > > > > >and ultimately > > > > > > > > > > cyrus-.tar -> 13.5M > > > > > > > > > >and I was thinking maybe there is a better way that someone else has > > > > >come up with. Anyone doing backups a different way? > > > > > > > > > Are you then dumping these files to tape? Otherwise, just having > > > > another copy on disk doesn't protect against many potential causes of > > > > data loss. > > > > > > Yes dumping to removable medium. > > > > > > > We just backup the mail files normally with Veritas Netbackup (be sure > > > > to disable true image restore with the millions of files), with the only > > > > custom bit being to dump a copy of the mailbox list to a text file > > > > before the backups run (this is a precaution since we are backing up > > > > structured database files without synchronization with the program > > > > writing them, so there is no guarantee the resulting backup is useful). > > > > Our full backup for all Cyrus files is 98G and 4.2M files, taking 5-8 > > > > hours depending on other data hitting the tape drives. Daily > > > > incremental backups average 1-3G and 10-30k files. > > > > > > So a cyrus backup needs to contain: > > > > > > /var/spool/imap > > > /var/lib/imap/mailboxes.db > > > > > > to be useful as a backup, right? With these to things I can recover... > > > I'm making sure I understand this completely. > > > > I am not sure what your directory structure looks like, but you need to > > make sure to backup sieve and quota directories. > > > > Your procedure may require hand recovery after restore before the mail > > store is usable. I recommend using filesystem snapshot (i assume you do > > not stop the mail server during backup) before performing backup. This > > will make your backup 'sane.' > > > > > How do you dump mailboxes to/from text? > > > What is the restore process? > > Good point. So the latest process would be: > > So a cyrus backup needs to contain: > > su cyrus -c "ctl_mboxlist -d" > mailboxes-.txt This is not neccassary, but not a bad idea. > /var/spool/imap > /var/lib/imap/quota > /var/lib/imap/user > /var/lib/imap/sieve > > Not sure how the filesystem snapshot works? On solaris do 'man fssnap'. veritas filesystem supports the snapshot feature as does Linux (at least the newer versions), I am not sure which filesystem. Basically, this feature provides a temporary stable and read-only view (snapshot) of a filesystem. The writes occur on a separate filesystem or device. -- Igor
Re: Cyrus Backup Strategy
On Fri, 2003-06-13 at 12:11, Igor Brezac wrote: > On Fri, 13 Jun 2003, pnelson wrote: > > > On Fri, 2003-06-13 at 11:29, John Alton Tamplin wrote: > > > pnelson wrote: > > > > > > >My last thing to do prior to converting to production is a backup > > > >strategy. I have been doing this with tar something like: > > > > > > > >tar -C /var/lib-czf lib-.tar.gzimap > > > >tar -C /var/spool -czf spool-.tar.gz imap > > > >tar -cf cyrus-.tar > > > > > > > >This is producing a pretty big file(s): > > > > > > > > lib-.tar.gz-> 2.2M > > > > spool-.tar.gz -> 11.0M > > > > > > > >and ultimately > > > > > > > > cyrus-.tar -> 13.5M > > > > > > > >and I was thinking maybe there is a better way that someone else has > > > >come up with. Anyone doing backups a different way? > > > > > > > Are you then dumping these files to tape? Otherwise, just having > > > another copy on disk doesn't protect against many potential causes of > > > data loss. > > > > Yes dumping to removable medium. > > > > > We just backup the mail files normally with Veritas Netbackup (be sure > > > to disable true image restore with the millions of files), with the only > > > custom bit being to dump a copy of the mailbox list to a text file > > > before the backups run (this is a precaution since we are backing up > > > structured database files without synchronization with the program > > > writing them, so there is no guarantee the resulting backup is useful). > > > Our full backup for all Cyrus files is 98G and 4.2M files, taking 5-8 > > > hours depending on other data hitting the tape drives. Daily > > > incremental backups average 1-3G and 10-30k files. > > > > So a cyrus backup needs to contain: > > > > /var/spool/imap > > /var/lib/imap/mailboxes.db > > > > to be useful as a backup, right? With these to things I can recover... > > I'm making sure I understand this completely. > > I am not sure what your directory structure looks like, but you need to > make sure to backup sieve and quota directories. > > Your procedure may require hand recovery after restore before the mail > store is usable. I recommend using filesystem snapshot (i assume you do > not stop the mail server during backup) before performing backup. This > will make your backup 'sane.' > > > How do you dump mailboxes to/from text? > > What is the restore process? Good point. So the latest process would be: So a cyrus backup needs to contain: su cyrus -c "ctl_mboxlist -d" > mailboxes-.txt /var/spool/imap /var/lib/imap/quota /var/lib/imap/user /var/lib/imap/sieve Not sure how the filesystem snapshot works? No I do not want to stop the server.
Re: Cyrus Backup Strategy
On Fri, 13 Jun 2003, pnelson wrote: > On Fri, 2003-06-13 at 11:29, John Alton Tamplin wrote: > > pnelson wrote: > > > > >My last thing to do prior to converting to production is a backup > > >strategy. I have been doing this with tar something like: > > > > > >tar -C /var/lib-czf lib-.tar.gzimap > > >tar -C /var/spool -czf spool-.tar.gz imap > > >tar -cf cyrus-.tar > > > > > >This is producing a pretty big file(s): > > > > > > lib-.tar.gz-> 2.2M > > > spool-.tar.gz -> 11.0M > > > > > >and ultimately > > > > > > cyrus-.tar -> 13.5M > > > > > >and I was thinking maybe there is a better way that someone else has > > >come up with. Anyone doing backups a different way? > > > > > Are you then dumping these files to tape? Otherwise, just having > > another copy on disk doesn't protect against many potential causes of > > data loss. > > Yes dumping to removable medium. > > > We just backup the mail files normally with Veritas Netbackup (be sure > > to disable true image restore with the millions of files), with the only > > custom bit being to dump a copy of the mailbox list to a text file > > before the backups run (this is a precaution since we are backing up > > structured database files without synchronization with the program > > writing them, so there is no guarantee the resulting backup is useful). > > Our full backup for all Cyrus files is 98G and 4.2M files, taking 5-8 > > hours depending on other data hitting the tape drives. Daily > > incremental backups average 1-3G and 10-30k files. > > So a cyrus backup needs to contain: > > /var/spool/imap > /var/lib/imap/mailboxes.db > > to be useful as a backup, right? With these to things I can recover... > I'm making sure I understand this completely. I am not sure what your directory structure looks like, but you need to make sure to backup sieve and quota directories. Your procedure may require hand recovery after restore before the mail store is usable. I recommend using filesystem snapshot (i assume you do not stop the mail server during backup) before performing backup. This will make your backup 'sane.' > How do you dump mailboxes to/from text? > What is the restore process? > > Thanks > > -- Igor
Re: Cyrus Backup Strategy
On Fri, 2003-06-13 at 11:29, John Alton Tamplin wrote: > pnelson wrote: > > >My last thing to do prior to converting to production is a backup > >strategy. I have been doing this with tar something like: > > > >tar -C /var/lib-czf lib-.tar.gzimap > >tar -C /var/spool -czf spool-.tar.gz imap > >tar -cf cyrus-.tar > > > >This is producing a pretty big file(s): > > > > lib-.tar.gz-> 2.2M > > spool-.tar.gz -> 11.0M > > > >and ultimately > > > > cyrus-.tar -> 13.5M > > > >and I was thinking maybe there is a better way that someone else has > >come up with. Anyone doing backups a different way? > > > Are you then dumping these files to tape? Otherwise, just having > another copy on disk doesn't protect against many potential causes of > data loss. Yes dumping to removable medium. > We just backup the mail files normally with Veritas Netbackup (be sure > to disable true image restore with the millions of files), with the only > custom bit being to dump a copy of the mailbox list to a text file > before the backups run (this is a precaution since we are backing up > structured database files without synchronization with the program > writing them, so there is no guarantee the resulting backup is useful). > Our full backup for all Cyrus files is 98G and 4.2M files, taking 5-8 > hours depending on other data hitting the tape drives. Daily > incremental backups average 1-3G and 10-30k files. So a cyrus backup needs to contain: /var/spool/imap /var/lib/imap/mailboxes.db to be useful as a backup, right? With these to things I can recover... I'm making sure I understand this completely. How do you dump mailboxes to/from text? What is the restore process? Thanks
Re: Cyrus Backup Strategy
pnelson wrote: My last thing to do prior to converting to production is a backup strategy. I have been doing this with tar something like: tar -C /var/lib-czf lib-.tar.gzimap tar -C /var/spool -czf spool-.tar.gz imap tar -cf cyrus-.tar This is producing a pretty big file(s): lib-.tar.gz-> 2.2M spool-.tar.gz -> 11.0M and ultimately cyrus-.tar -> 13.5M and I was thinking maybe there is a better way that someone else has come up with. Anyone doing backups a different way? Are you then dumping these files to tape? Otherwise, just having another copy on disk doesn't protect against many potential causes of data loss. We just backup the mail files normally with Veritas Netbackup (be sure to disable true image restore with the millions of files), with the only custom bit being to dump a copy of the mailbox list to a text file before the backups run (this is a precaution since we are backing up structured database files without synchronization with the program writing them, so there is no guarantee the resulting backup is useful). Our full backup for all Cyrus files is 98G and 4.2M files, taking 5-8 hours depending on other data hitting the tape drives. Daily incremental backups average 1-3G and 10-30k files. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
Cyrus Backup Strategy
My last thing to do prior to converting to production is a backup strategy. I have been doing this with tar something like: tar -C /var/lib-czf lib-.tar.gzimap tar -C /var/spool -czf spool-.tar.gz imap tar -cf cyrus-.tar This is producing a pretty big file(s): lib-.tar.gz-> 2.2M spool-.tar.gz -> 11.0M and ultimately cyrus-.tar -> 13.5M and I was thinking maybe there is a better way that someone else has come up with. Anyone doing backups a different way?
Re: Sendmail SASL Auth problem
Sorry guys, my fault :-) I forgot to put smtpauthrequiredpam_pgsql.sotry_first_pass smtpaccount requiredpam_pgsql.sotry_first_pass in my pam.conf file Dmitry
Re: Trying to deliver to sub folder
After more searching I just realized that the following will also work without the need for anonymous to have p rights. /usr/cyrus/bin/deliver -m Junk -a boutilpj boutilpj Michael Bacon wrote: If you're using deliver, the user that needs "post" access to the mailbox is not cyrus, but anonymous. So "sam user.boutilpj anonymous p" (or "anyone p") is what you need. Should work after you do that. Michael --On Friday, June 13, 2003 9:35 AM -0300 Patrick Boutilier <[EMAIL PROTECTED]> wrote: Cyrus 2.1.13 According to the man page for deliver the "cat ..." command below should put the message in the Junk folder however it goes directly into the INBOX. Clip from 'man deliver": -m mailbox Deliver to mailbox. If any userids are specified, attempts todeliver to user.userid.mailbox for each userid. If the ACL onany such mailbox does not grant the sender the "p" right or if-m is not specified, then delivers to the INBOX for the userid,regardless of the ACL on the INBOX. If no userids are specified, attempts to deliver to mailbox. Ifthe ACL on mailbox does not grant the sender the "p" right, thedelivery fails. cyradm: localhost> lam user.boutilpj boutilpj lrswipcda cyrus lrswpa localhost> lam user.boutilpj.Junk boutilpj lrswipcda cyrus lrswpa Any ideas? cat mail.txt|strace -fF /usr/cyrus/bin/deliver -m Junk boutilpj
Sendmail SASL Auth problem
Hi, I have a problem sending mail using sendmail SASL Authentication. I'm using saslauthd -a pam for authentication. pam module is pam-pgsql Users can login to Cyrus IMAPD and receive their mail using MS Outlook Express but they can't send mail. The accounts setup to authenticate to mail server using the same settings (username and password) as for incoming mail (Cyrus IMAPD). When I hit reseive button Authentication screen pops up, I enter valid user name and password and this record appers in the maillog: Jun 13 10:26:40 mail sm-mta[4930]: h5DGQd4D004930: win2k.intellinetinc.com [139.142.54.35] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA And if I run saslauthd -a pam -d saslauthd[4982] :main: num_procs : 5 saslauthd[4982] :main: mech_option: NULL saslauthd[4982] :main: run_path : /var/state/saslauthd saslauthd[4982] :main: auth_mech : pam saslauthd[4982] :ipc_init: using accept lock file: /var/state/saslauthd/mux.accept saslauthd[4982] :detach_tty : master pid is: 0 saslauthd[4982] :ipc_init: listening on socket: /var/state/saslauthd/mux saslauthd[4982] :main: using process model saslauthd[4982] :have_baby : forked child: 4983 saslauthd[4983] :get_accept_lock : acquired accept lock saslauthd[4982] :have_baby : forked child: 4984 saslauthd[4982] :have_baby : forked child: 4985 saslauthd[4982] :have_baby : forked child: 4986 saslauthd[4984] :get_accept_lock : acquired accept lock saslauthd[4983] :rel_accept_lock : released accept lock saslauthd[4983] :do_auth : auth failure: [user=dmitry] [service=smtp] [realm=] [mech=pam] saslauthd[4985] :get_accept_lock : acquired accept lock saslauthd[4984] :rel_accept_lock : released accept lock NOTICE: Adding missing FROM-clause entry for table "domains" NOTICE: Adding missing FROM-clause entry for table "domains" saslauthd[4984] :do_auth : auth success: [user=dmitry] [service=imap] [realm=] [mech=pam] saslauthd[4984] :do_request : response: OK saslauthd[4986] :get_accept_lock : acquired accept lock saslauthd[4985] :rel_accept_lock : released accept lock In my sendmail.mc I have: define(`confAUTH_MECHANISMS',`PLAIN LOGIN DIGEST-MD5 CRAM-MD5')dnl TRUST_AUTH_MECH(`PLAIN LOGIN DIGEST-MD5 CRAM-MD5')dnl Do I have to add something else to my sendmail.mc? Please help ASAP Thank you Dmitry
Re: Compiling Cyrus IMAPD on AMD Opteron
On 13 Jun 2003, Rob Siemborski said: > On Fri, 13 Jun 2003, Igor Brezac wrote: > >>> Anything that goes inside a lib should be -fPIC. Really. I have >>> done this in the Debian build (which runs OK in S/390, IA64, >>> Alpha, MIPS, MIPS-EL...) ages ago. I don't know if these changes >>> are in CMU Cyrus. >> >> This in true only for shared libs unless you are trying to link an >> archive into a shared lib (which can be the case with perl >> modules). >> >> Position independent code adds some overhead. I think CMU folks >> like to build things static as much as possible for performance >> reasons. > > Actually, we prefer shared libraries for maintainability reasons. > > However, the number of shared libraries our IMAPd links (once SASL > is all done loading etc) is something up near 25-30. Since each of > these shared libraries costs you a per-process jump table, this gets > expensive in terms of memory usage really fast. So, we try to link > staticly in this case. > >>> Yep. Arch dislikes mixing PIC and non-PIC code inside a >>> relocatable object. >> >> Correct. On Solaris, I build lib/ and perl/sieve/lib with -fPIC >> just to build cyrus-imap perl stuff. > > H. We've never had to do this on solaris. > > I wonder if we could write a configure test to determine if this is > necessary on a given platform. Isn't that what libtool is for? For the Perl stuff explicitly: [EMAIL PROTECTED]:46$ perl -V:cccdlflags cccdlflags='-fpic'; [EMAIL PROTECTED]:47$ -- Stephen L. Ulmer [EMAIL PROTECTED] Senior Systems Programmer http://www.ulmer.org/ Northeast Regional Data Center VOX: (352) 392-2061 University of Florida FAX: (352) 392-9440
Re: Compiling Cyrus IMAPD on AMD Opteron
On Fri, 13 Jun 2003, Lawrence Greenfield wrote: >Date: Fri, 13 Jun 2003 11:11:41 -0400 (EDT) >From: Rob Siemborski <[EMAIL PROTECTED]> > >> > Yep. Arch dislikes mixing PIC and non-PIC code inside a >> > relocatable object. >> >> Correct. On Solaris, I build lib/ and perl/sieve/lib with -fPIC >> just to build cyrus-imap perl stuff. > >H. We've never had to do this on solaris. > > Yeah, Solaris is one of the platforms that is tolerant of mixing > non -fPIC into shared libraries. It poses a large memory hit (shared > libraries with non -fPIC code aren't shared between processes). -zcombreloc linker flag make my installation require -fPIC. > The major problem with trying to add -fPIC to the distribution is that > isn't how it works on all compilers and all OS's. Thus the pain that > is libtool. I've thought about making all of Cyrus build with libtool, > and then I read some of the bug reports we get because of libsasl's > use of libtool and start thinking better of it. > >I wonder if we could write a configure test to determine if this is >necessary on a given platform. > > To do it in all generality requires duplicating libtool. > > Larry > > -- Igor
Re: Compiling Cyrus IMAPD on AMD Opteron
On Fri, 13 Jun 2003, Rob Siemborski wrote: > On Fri, 13 Jun 2003, Igor Brezac wrote: > > > > Anything that goes inside a lib should be -fPIC. Really. I have done this in > > > the Debian build (which runs OK in S/390, IA64, Alpha, MIPS, MIPS-EL...) > > > ages ago. I don't know if these changes are in CMU Cyrus. > > > > This in true only for shared libs unless you are trying to link an > > archive into a shared lib (which can be the case with perl modules). > > > > Position independent code adds some overhead. I think CMU folks like to > > build things static as much as possible for performance reasons. > > Actually, we prefer shared libraries for maintainability reasons. I stand corrected. ;) All this trouble of building static libsasl led me to think this way. > However, the number of shared libraries our IMAPd links (once SASL is all > done loading etc) is something up near 25-30. Since each of these shared > libraries costs you a per-process jump table, this gets expensive in terms > of memory usage really fast. So, we try to link staticly in this case. > > > > Yep. Arch dislikes mixing PIC and non-PIC code inside a relocatable object. > > > > Correct. On Solaris, I build lib/ and perl/sieve/lib with -fPIC just to > > build cyrus-imap perl stuff. > > H. We've never had to do this on solaris. > > I wonder if we could write a configure test to determine if this is > necessary on a given platform. It depends on how perl is built and possibly type of compiler/linker flags used. Also, CFLAGS=-fPIC breaks 'make depend'. I am not sure what is the best way to deal with this, fix makedepend?. -- Igor
Re: Compiling Cyrus IMAPD on AMD Opteron
Date: Fri, 13 Jun 2003 11:11:41 -0400 (EDT) From: Rob Siemborski <[EMAIL PROTECTED]> > > Yep. Arch dislikes mixing PIC and non-PIC code inside a > > relocatable object. > > Correct. On Solaris, I build lib/ and perl/sieve/lib with -fPIC > just to build cyrus-imap perl stuff. H. We've never had to do this on solaris. Yeah, Solaris is one of the platforms that is tolerant of mixing non -fPIC into shared libraries. It poses a large memory hit (shared libraries with non -fPIC code aren't shared between processes). The major problem with trying to add -fPIC to the distribution is that isn't how it works on all compilers and all OS's. Thus the pain that is libtool. I've thought about making all of Cyrus build with libtool, and then I read some of the bug reports we get because of libsasl's use of libtool and start thinking better of it. I wonder if we could write a configure test to determine if this is necessary on a given platform. To do it in all generality requires duplicating libtool. Larry
RE: seen file corruption
Hmmm I see your point. Maybe not such a good idea. Thanks for setting me straight. Rich On Fri, 2003-06-13 at 10:19, Rob Siemborski wrote: > On Fri, 13 Jun 2003, Richard Houston wrote: > > > It would be very cool to have the actual messages stored in database as > > well. The dbmail project is doing this in Mysql or Postgresql. Imagine > > the maturity of Cyrus with all the benefits of storage and backup in a > > database. Would be cool. > > Except that the benefits of Cyrus are lost, for the most part, if you > change the mail store. The parser APIs that lie on top of the mail store > are almost trivial to implement compared to the data storage (and > retrieval) mechanisms themselves. > > Cyrus gets its high performance from clever indexing and caching of > information in each mailbox. If you gut all this code and replace it with > a database, you've removed the primary benefit! > > Additionally, you've probably lost some performance because the speed of > Cyrus's store (optimized for IMAP) is going to be hard to beat with a > generic database. Not impossible, but its really not something we're > interested in doing for the foreseeable future. > > As it is, I have trouble understanding why anyone would want to make a > cyrusdb out of a relational database. Cyrusdb provides simple key/value > pairs, where a relational database is providing a lot more, and has more > overhead. If you want to be able to access this data (internal to cyrus) > from another application, you're asking for serious trouble. > > -Rob > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 > Research Systems Programmer * /usr/contributed Gatekeeper > > > On Fri, 2003-06-13 at 10:19, Rob Siemborski wrote: > On Fri, 13 Jun 2003, Richard Houston wrote: > > > It would be very cool to have the actual messages stored in database as > > well. The dbmail project is doing this in Mysql or Postgresql. Imagine > > the maturity of Cyrus with all the benefits of storage and backup in a > > database. Would be cool. > > Except that the benefits of Cyrus are lost, for the most part, if you > change the mail store. The parser APIs that lie on top of the mail store > are almost trivial to implement compared to the data storage (and > retrieval) mechanisms themselves. > > Cyrus gets its high performance from clever indexing and caching of > information in each mailbox. If you gut all this code and replace it with > a database, you've removed the primary benefit! > > Additionally, you've probably lost some performance because the speed of > Cyrus's store (optimized for IMAP) is going to be hard to beat with a > generic database. Not impossible, but its really not something we're > interested in doing for the foreseeable future. > > As it is, I have trouble understanding why anyone would want to make a > cyrusdb out of a relational database. Cyrusdb provides simple key/value > pairs, where a relational database is providing a lot more, and has more > overhead. If you want to be able to access this data (internal to cyrus) > from another application, you're asking for serious trouble. > > -Rob > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 > Research Systems Programmer * /usr/contributed Gatekeeper > > >
RE: seen file corruption
On Fri, 13 Jun 2003, Richard Houston wrote: > It would be very cool to have the actual messages stored in database as > well. The dbmail project is doing this in Mysql or Postgresql. Imagine > the maturity of Cyrus with all the benefits of storage and backup in a > database. Would be cool. Except that the benefits of Cyrus are lost, for the most part, if you change the mail store. The parser APIs that lie on top of the mail store are almost trivial to implement compared to the data storage (and retrieval) mechanisms themselves. Cyrus gets its high performance from clever indexing and caching of information in each mailbox. If you gut all this code and replace it with a database, you've removed the primary benefit! Additionally, you've probably lost some performance because the speed of Cyrus's store (optimized for IMAP) is going to be hard to beat with a generic database. Not impossible, but its really not something we're interested in doing for the foreseeable future. As it is, I have trouble understanding why anyone would want to make a cyrusdb out of a relational database. Cyrusdb provides simple key/value pairs, where a relational database is providing a lot more, and has more overhead. If you want to be able to access this data (internal to cyrus) from another application, you're asking for serious trouble. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Compiling Cyrus IMAPD on AMD Opteron
On Fri, 13 Jun 2003, Igor Brezac wrote: > > Anything that goes inside a lib should be -fPIC. Really. I have done this in > > the Debian build (which runs OK in S/390, IA64, Alpha, MIPS, MIPS-EL...) > > ages ago. I don't know if these changes are in CMU Cyrus. > > This in true only for shared libs unless you are trying to link an > archive into a shared lib (which can be the case with perl modules). > > Position independent code adds some overhead. I think CMU folks like to > build things static as much as possible for performance reasons. Actually, we prefer shared libraries for maintainability reasons. However, the number of shared libraries our IMAPd links (once SASL is all done loading etc) is something up near 25-30. Since each of these shared libraries costs you a per-process jump table, this gets expensive in terms of memory usage really fast. So, we try to link staticly in this case. > > Yep. Arch dislikes mixing PIC and non-PIC code inside a relocatable object. > > Correct. On Solaris, I build lib/ and perl/sieve/lib with -fPIC just to > build cyrus-imap perl stuff. H. We've never had to do this on solaris. I wonder if we could write a configure test to determine if this is necessary on a given platform. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
RE: seen file corruption
Just an idea, It would be very cool to have the actual messages stored in database as well. The dbmail project is doing this in Mysql or Postgresql. Imagine the maturity of Cyrus with all the benefits of storage and backup in a database. Would be cool. Thanks Rich On Fri, 2003-06-13 at 03:34, Gareth Bult wrote: > Hi, > > I don't suppose that custom MySQL connector is 'available' is it? > > Regards, > Gareth. > > On Thu, 2003-06-12 at 18:22, Brasseur Valéry wrote: > > I use a custom mysql database connector for my mailboxes ! > > > > > -Original Message- > > > From: Rob Siemborski [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, June 12, 2003 7:22 PM > > > To: Brasseur Valéry > > > Cc: [EMAIL PROTECTED] > > > Subject: RE: seen file corruption > > > > > > > > > On Thu, 12 Jun 2003, [iso-8859-1] Brasseur Valéry wrote: > > > > > > > just seen state > > > > > > You're hitting a bug then. > > > > > > Any chance you can convert your mboxlist to skiplist? > > > > > > -Rob > > > > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 > > > Research Systems Programmer * /usr/contributed Gatekeeper > > > > > > > > > > -- > > Gareth Bult - Frontier Internet Services Limited > > Tel:02920 820 000 > Fax:02920 820 035 > Email: [EMAIL PROTECTED] > Web: www.bult.co.uk > Statements made are at all times subject to Frontier's Terms and > Conditions of Business, which are available upon request.
Re: Compiling Cyrus IMAPD on AMD Opteron
On Fri, 13 Jun 2003, Henrique de Moraes Holschuh wrote: > On Fri, 13 Jun 2003, [EMAIL PROTECTED] wrote: > > Compiling with the -fPIC fixes the problem. I had to do this for the > > following: imclient.c imparse.c xmalloc.c imapurl.c iptostring.c assert.c > > util.c libisieve.c prot.c > > > > Why does -fPIC fix this problem? > > Because of either: > 1. AMD64 is unforgiving of non-PIC code mixed with PIC code where it > shouldn't be (libraries) > 2. Compiler bugs. > > Anything that goes inside a lib should be -fPIC. Really. I have done this in > the Debian build (which runs OK in S/390, IA64, Alpha, MIPS, MIPS-EL...) > ages ago. I don't know if these changes are in CMU Cyrus. This in true only for shared libs unless you are trying to link an archive into a shared lib (which can be the case with perl modules). Position independent code adds some overhead. I think CMU folks like to build things static as much as possible for performance reasons. > I don't think the Cyrus build uses --shared, but I didn't check. > > > >>../../lib/libcyrus.a(imclient.o): relocation R_X86_64_32 can not be used > > >>when making a shared object; recompile with -fPIC > > Yep. Arch dislikes mixing PIC and non-PIC code inside a relocatable object. Correct. On Solaris, I build lib/ and perl/sieve/lib with -fPIC just to build cyrus-imap perl stuff. -- Igor
Re: migrating from sendmail/shadow to sasl on new box
On Fri, 13 Jun 2003, John Alton Tamplin wrote: > > As far as I've been able to find, the only way to migrate use info > > from an old box running sendmail authenticating against shadow to a > > new system running postfix authenticating against sasldb2 is to use > > the auto_transition feature. Is this true, or is there perhaps a > > manual_transition feature that I might employ? > > If you have their clear-text password, or are willing to reset the > passwords, it would be trivial to write a script to do it. Otherwise, > you do not have sufficient information (shadow only stores a one-way > hash of the password, using crypt or md5 depending on your OS and > configuration) to regenerate the clear-text password that is required. To make matters worse, there is no good way to implement auto_transition in a database-independent way currently, so it isn't going to do what you want anyway. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: migrating from sendmail/shadow to sasl on new box
John Alton Tamplin wrote: blast wrote: As far as I've been able to find, the only way to migrate use info from an old box running sendmail authenticating against shadow to a new system running postfix authenticating against sasldb2 is to use the auto_transition feature. Is this true, or is there perhaps a manual_transition feature that I might employ? If you have their clear-text password, or are willing to reset the passwords, it would be trivial to write a script to do it. Otherwise, you do not have sufficient information (shadow only stores a one-way hash of the password, using crypt or md5 depending on your OS and configuration) to regenerate the clear-text password that is required. That is what I assumed initially as well. But after looking into things just to say I did, it occurred to me that since sasl can store passwords as md5, I might be able to cut-and-paste my md5 shadow hashes into sasldb2 somehow. Might you be able to explain why this won't work (not that I've been able to get it to work of course ;)? basem
Re: Trying to deliver to sub folder
Michael, Thanks. Now to try and get Exim to deliver to subfolders using lmtp. :-) Anybody get that working corectly? Michael Bacon wrote: If you're using deliver, the user that needs "post" access to the mailbox is not cyrus, but anonymous. So "sam user.boutilpj anonymous p" (or "anyone p") is what you need. Should work after you do that. Michael --On Friday, June 13, 2003 9:35 AM -0300 Patrick Boutilier <[EMAIL PROTECTED]> wrote: Cyrus 2.1.13 According to the man page for deliver the "cat ..." command below should put the message in the Junk folder however it goes directly into the INBOX. Clip from 'man deliver": -m mailbox Deliver to mailbox. If any userids are specified, attempts todeliver to user.userid.mailbox for each userid. If the ACL onany such mailbox does not grant the sender the "p" right or if-m is not specified, then delivers to the INBOX for the userid,regardless of the ACL on the INBOX. If no userids are specified, attempts to deliver to mailbox. Ifthe ACL on mailbox does not grant the sender the "p" right, thedelivery fails. cyradm: localhost> lam user.boutilpj boutilpj lrswipcda cyrus lrswpa localhost> lam user.boutilpj.Junk boutilpj lrswipcda cyrus lrswpa Any ideas?
Re: Compiling Cyrus IMAPD on AMD Opteron
On Fri, 13 Jun 2003, [EMAIL PROTECTED] wrote: > Compiling with the -fPIC fixes the problem. I had to do this for the > following: imclient.c imparse.c xmalloc.c imapurl.c iptostring.c assert.c > util.c libisieve.c prot.c > > Why does -fPIC fix this problem? Because of either: 1. AMD64 is unforgiving of non-PIC code mixed with PIC code where it shouldn't be (libraries) 2. Compiler bugs. Anything that goes inside a lib should be -fPIC. Really. I have done this in the Debian build (which runs OK in S/390, IA64, Alpha, MIPS, MIPS-EL...) ages ago. I don't know if these changes are in CMU Cyrus. I don't think the Cyrus build uses --shared, but I didn't check. > >>../../lib/libcyrus.a(imclient.o): relocation R_X86_64_32 can not be used > >>when making a shared object; recompile with -fPIC Yep. Arch dislikes mixing PIC and non-PIC code inside a relocatable object. -- "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
Re: migrating from sendmail/shadow to sasl on new box
blast wrote: As far as I've been able to find, the only way to migrate use info from an old box running sendmail authenticating against shadow to a new system running postfix authenticating against sasldb2 is to use the auto_transition feature. Is this true, or is there perhaps a manual_transition feature that I might employ? If you have their clear-text password, or are willing to reset the passwords, it would be trivial to write a script to do it. Otherwise, you do not have sufficient information (shadow only stores a one-way hash of the password, using crypt or md5 depending on your OS and configuration) to regenerate the clear-text password that is required. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
Re: Compiling Cyrus IMAPD on AMD Opteron
[EMAIL PROTECTED] wrote: Compiling with the -fPIC fixes the problem. I had to do this for the following: imclient.c imparse.c xmalloc.c imapurl.c iptostring.c assert.c util.c libisieve.c prot.c Why does -fPIC fix this problem? Code to be used in a shared library must be position-independent, since it will be linked into various applications at different places in the various applications that link to that library. The linker was complaining that a relocation type used was not suitable in a shared library because it could not be made to be position-independent, and recompiling with -fPIC made the compiler avoid that addressing mode and relocation type. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
migrating from sendmail/shadow to sasl on new box
As far as I've been able to find, the only way to migrate use info from an old box running sendmail authenticating against shadow to a new system running postfix authenticating against sasldb2 is to use the auto_transition feature. Is this true, or is there perhaps a manual_transition feature that I might employ? Thanks for listening, basem
Re: Trying to deliver to sub folder
If you're using deliver, the user that needs "post" access to the mailbox is not cyrus, but anonymous. So "sam user.boutilpj anonymous p" (or "anyone p") is what you need. Should work after you do that. Michael --On Friday, June 13, 2003 9:35 AM -0300 Patrick Boutilier <[EMAIL PROTECTED]> wrote: Cyrus 2.1.13 According to the man page for deliver the "cat ..." command below should put the message in the Junk folder however it goes directly into the INBOX. Clip from 'man deliver": -m mailbox Deliver to mailbox. If any userids are specified, attempts todeliver to user.userid.mailbox for each userid. If the ACL onany such mailbox does not grant the sender the "p" right or if-m is not specified, then delivers to the INBOX for the userid,regardless of the ACL on the INBOX. If no userids are specified, attempts to deliver to mailbox. Ifthe ACL on mailbox does not grant the sender the "p" right, thedelivery fails. cyradm: localhost> lam user.boutilpj boutilpj lrswipcda cyrus lrswpa localhost> lam user.boutilpj.Junk boutilpj lrswipcda cyrus lrswpa Any ideas? cat mail.txt|strace -fF /usr/cyrus/bin/deliver -m Junk boutilpj execve("/usr/cyrus/bin/deliver", ["/usr/cyrus/bin/deliver", "-m", "Junk", "boutilpj"], [/* 19 vars */]) = 0 uname({sys="Linux", node="student.ednet.ns.ca", ...}) = 0 brk(0) = 0x80766c0 open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory) open("/usr/local/lib/i686/mmx/libsasl2.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/local/lib/i686/mmx", 0xb250) = -1 ENOENT (No such file or directory) open("/usr/local/lib/i686/libsasl2.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/local/lib/i686", 0xb250) = -1 ENOENT (No such file or directory) open("/usr/local/lib/mmx/libsasl2.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/local/lib/mmx", 0xb250) = -1 ENOENT (No such file or directory) open("/usr/local/lib/libsasl2.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`/\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=371313, ...}) = 0 old_mmap(NULL, 72104, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40013000 old_mmap(0x40024000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1) = 0x40024000 close(3)= 0 open("/usr/local/lib/libssl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=31245, ...}) = 0 old_mmap(NULL, 31245, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40025000 close(3)= 0 open("/lib/libssl.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\220"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=224721, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4002d000 old_mmap(NULL, 195076, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4002e000 old_mmap(0x4005b000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x2d000) = 0x4005b000 close(3) = 0 open("/usr/local/lib/libcrypto.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libcrypto.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p9\2\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=995665, ...}) = 0 old_mmap(NULL, 875620, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4005e000 old_mmap(0x40125000, 49152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xc7000) = 0x40125000 old_mmap(0x40131000, 11364, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40131000 close(3)= 0 open("/usr/local/lib/libresolv.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libresolv.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\230\'\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=69443, ...}) = 0 old_mmap(NULL, 69444, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40134000 old_mmap(0x40142000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xe000) = 0x40142000 old_mmap(0x40143000, 8004, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40143000 close(3) = 0 open("/usr/local/lib/libdb-4.0.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libdb-4.0.so", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\27"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0555, st_size=760175, ...}) = 0 old_mmap(NULL, 686348, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40145000 old_mmap(0x401eb000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xa5000) = 0x401eb000 close(3) = 0 open("/usr/local/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libc.so.6",
Re: notes on Sieve and cyrus-imapd-2.2a
On Fri, 13 Jun 2003, Rob Siemborski wrote: > I'm anticipating doing a next 2.1 version of both SASL and Cyrus, and > probably shortly thereafter a 2.2.1-ALPHA ...by early next month. ;) -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: notes on Sieve and cyrus-imapd-2.2a
On Fri, 13 Jun 2003, Henrique de Moraes Holschuh wrote: > On Thu, 12 Jun 2003, Ken Murchison wrote: > > I seem to recall this being fixed in CVS as well. > > IMHO CMU should package a 2.2alpha2. Too many fixes are already > in CVS... enough that nobody should be using 2.2alpha anymore. We're still working on some last minute things, and I'm doing other work at the moment. I'm anticipating doing a next 2.1 version of both SASL and Cyrus, and probably shortly thereafter a 2.2.1-ALPHA -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Compiling Cyrus IMAPD on AMD Opteron
Compiling with the -fPIC fixes the problem. I had to do this for the following: imclient.c imparse.c xmalloc.c imapurl.c iptostring.c assert.c util.c libisieve.c prot.c Why does -fPIC fix this problem? > [EMAIL PROTECTED] wrote: > >>make[2]: Entering directory `/root/src/cyrus-imapd-2.1.13/perl/imap' >>rm -f blib/arch/auto/Cyrus/IMAP/IMAP.so >>LD_RUN_PATH="/usr/lib64" cc -shared -L/usr/local/lib64 IMAP.o -o >>blib/arch/auto/Cyrus/IMAP/IMAP.so ../../lib/libcyrus.a -lssl -lcrypto >>/usr/lib64/gcc-lib/x86_64-suse-linux/3.2.2/../../../../x86_64-suse-linux/bin/ld: >>../../lib/libcyrus.a(imclient.o): relocation R_X86_64_32 can not be used >>when making a shared object; recompile with -fPIC >>../../lib/libcyrus.a: could not read symbols: Bad value >>collect2: ld returned 1 exit status >>make[2]: *** [blib/arch/auto/Cyrus/IMAP/IMAP.so] Error 1 >>make[2]: Leaving directory `/root/src/cyrus-imapd-2.1.13/perl/imap' >>make[1]: *** [all] Error 1 >>make[1]: Leaving directory `/root/src/cyrus-imapd-2.1.13/perl' >>make: *** [all] Error 1 >>[snippet] >> >>Can anyone help me with it? I wanted to get it working to test out the >>performance of the system. >> >> > What you need to look at is where imclient.c was compiled. Either it > wasn't compiled with -shared, or the gcc port is not properly choosing > the right flags for -shared. Run the cc command yourself in that > directory, adding the -v flag and see if -fPIC gets passed to cc1. If > not, you can fix the problem just by adding -fPIC yourself in the > compile commands. If it is getting passed, then it looks like the > machine definition is improperly choosing a particular addressing mode > when generating PIC code and that will need to get fixed by whoever > maintains the x86_64 machine description for gcc. > > -- > John A. Tamplin Unix System Administrator > Emory University, School of Public Health +1 404/727-9931 > > > --- Curtis Robinson [EMAIL PROTECTED]
Trying to deliver to sub folder
Cyrus 2.1.13 According to the man page for deliver the "cat ..." command below should put the message in the Junk folder however it goes directly into the INBOX. Clip from 'man deliver": -m mailbox Deliver to mailbox. If any userids are specified, attempts to deliver to user.userid.mailbox for each userid. If the ACL on any such mailbox does not grant the sender the "p" right or if -m is not specified, then delivers to the INBOX for the userid, regardless of the ACL on the INBOX. If no userids are specified, attempts to deliver to mailbox. If the ACL on mailbox does not grant the sender the "p" right, the delivery fails. cyradm: localhost> lam user.boutilpj boutilpj lrswipcda cyrus lrswpa localhost> lam user.boutilpj.Junk boutilpj lrswipcda cyrus lrswpa Any ideas? cat mail.txt|strace -fF /usr/cyrus/bin/deliver -m Junk boutilpj execve("/usr/cyrus/bin/deliver", ["/usr/cyrus/bin/deliver", "-m", "Junk", "boutilpj"], [/* 19 vars */]) = 0 uname({sys="Linux", node="student.ednet.ns.ca", ...}) = 0 brk(0) = 0x80766c0 open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory) open("/usr/local/lib/i686/mmx/libsasl2.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/local/lib/i686/mmx", 0xb250) = -1 ENOENT (No such file or directory) open("/usr/local/lib/i686/libsasl2.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/local/lib/i686", 0xb250) = -1 ENOENT (No such file or directory) open("/usr/local/lib/mmx/libsasl2.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/local/lib/mmx", 0xb250) = -1 ENOENT (No such file or directory) open("/usr/local/lib/libsasl2.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`/\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=371313, ...}) = 0 old_mmap(NULL, 72104, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40013000 old_mmap(0x40024000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1) = 0x40024000 close(3)= 0 open("/usr/local/lib/libssl.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=31245, ...}) = 0 old_mmap(NULL, 31245, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40025000 close(3)= 0 open("/lib/libssl.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\220"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=224721, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4002d000 old_mmap(NULL, 195076, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4002e000 old_mmap(0x4005b000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x2d000) = 0x4005b000 close(3)= 0 open("/usr/local/lib/libcrypto.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libcrypto.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p9\2\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=995665, ...}) = 0 old_mmap(NULL, 875620, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4005e000 old_mmap(0x40125000, 49152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xc7000) = 0x40125000 old_mmap(0x40131000, 11364, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40131000 close(3)= 0 open("/usr/local/lib/libresolv.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libresolv.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\230\'\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=69443, ...}) = 0 old_mmap(NULL, 69444, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40134000 old_mmap(0x40142000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xe000) = 0x40142000 old_mmap(0x40143000, 8004, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40143000 close(3)= 0 open("/usr/local/lib/libdb-4.0.so", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libdb-4.0.so", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\27"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0555, st_size=760175, ...}) = 0 old_mmap(NULL, 686348, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40145000 old_mmap(0x401eb000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xa5000) = 0x401eb000 close(3)= 0 open("/usr/local/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/libc.so.6", O_RDONLY)= 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\210U\1"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1377691, ...}) = 0 old_mmap(NULL, 121917
Re: notes on Sieve and cyrus-imapd-2.2a
Henrique de Moraes Holschuh wrote: On Thu, 12 Jun 2003, Ken Murchison wrote: I seem to recall this being fixed in CVS as well. IMHO CMU should package a 2.2alpha2. Too many fixes are already in CVS... enough that nobody should be using 2.2alpha anymore. That will probably happen soon. There are a few things that I want to get done first. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
RE: seen file corruption
Hi, I don't suppose that custom MySQL connector is 'available' is it? Regards, Gareth. On Thu, 2003-06-12 at 18:22, Brasseur Valéry wrote: I use a custom mysql database connector for my mailboxes ! > -Original Message- > From: Rob Siemborski [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 12, 2003 7:22 PM > To: Brasseur Valéry > Cc: [EMAIL PROTECTED] > Subject: RE: seen file corruption > > > On Thu, 12 Jun 2003, [iso-8859-1] Brasseur Valéry wrote: > > > just seen state > > You're hitting a bug then. > > Any chance you can convert your mboxlist to skiplist? > > -Rob > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 > Research Systems Programmer * /usr/contributed Gatekeeper > > -- Gareth Bult - Frontier Internet Services Limited Tel: 02920 820 000 Fax: 02920 820 035 Email: [EMAIL PROTECTED] Web: www.bult.co.uk Statements made are at all times subject to Frontier's Terms and Conditions of Business, which are available upon request.
unable to authenticate
Hello list, I've installed cyrus-imapd 2.1.13 and cyrus-sasl 2.1.13, but I am having trouble authenticathing. I don't want to create unix users for every imap user so I'd like to use the sasldb athentication. I'm using Solaris 8 platform. My sasldb is at /etc/sasldb2 and the cyrus user can read the /etc/sasldb2 file. This is my /etc/imapd.conf file: configdirectory: /var/imap defaultpartition: default partition-default: /var/spool/imap admins: cyrus sievedir: /usr/sieve sendmail: /usr/lib/sendmail sasl_pwcheck_method: auxprop sasl_auxprop_plugin: sasldb sasl_sasldb_path: /etc/sasldb2 tls_cert_file: /var/imap/server.pem tls_key_file: /var/imap/server.pem postmaster: ean allowanonymouslogin: no allowplaintext: yes sasl_mech_list: PLAIN servername: delius.upc.es autocreatequota: 1 reject8bit: no quotawarn: 90 timeout: 30 poptimeout: 10 dracinterval: 0 drachost: localhost sieve_maxscriptsize: 32 sieve_maxscripts: 5 altnamespace: yes duplicatesuppression: yes hashimapspool: true unixhierarchysep: yes I've tried to create the cyrus user with saslpasswd2 and it seems to work. The sasldblistusers2 shows: [EMAIL PROTECTED]: userPassword but this is the response when I try to connect using imtest: > imtest -a cyrus -m login localhost S: * OK delius.upc.es Cyrus IMAP4 v2.1.13 server ready C: C01 CAPABILITY S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES IDLE STARTTLS S: C01 OK Completed Please enter your password: C: L01 LOGIN cyrus {7} S: + go ahead C: S: L01 NO Login failed: user not found Authentication failed. generic failure Security strength factor: 0 Am I missing something? Are there something wrong? Any help would be much appreciated. - ANNA -