FUD Perl module need tester
Hi there,
I recently wrote a Perl module to interface to FUD. It is very simple
and so far seem reliable. I would like it to get a little testing
before Ipost it on CPAN. If you are using, wheter successfully or not,
I would like to hear from you. Your feedback are appreciated.
It is quite easy to use. The following snippet of Perl would dump the
info available for a mailbox :
#!/usr/bin/perl
use warnings;
use Net::FUD;
my $fud = Net::FUD-new(server = localhost);
my @ret = $fud-retr_info('egoyer', 'user.egoyer');
print (join ' ', @ret) . \n;
$fud-close;
Just copy the attached .pm inside of a Net folder somewhere in @INC. It
is documented by POD, accessible by perldoc Net::FUD.
I also have a module that interface to MUPDATE in the work. It is not
ready for release (require cleanup and documentation), but if you really
need such a thing, contact me off-list and I will send it to you.
Thanks for your feedback.
--
Etienne GoyerLinux Québec Technologies Inc.
http://www.LinuxQuebec.com [EMAIL PROTECTED]
# Net::FUD.pm
# $Id: FUD.pm,v 1.2 2003/05/29 19:13:36 egoyer Exp $
#
# Copyright (c) 2003 Etienne Goyer, Linux Québec Technologies
# [EMAIL PROTECTED]. All rights reserved.
# This program is free software; you can redistribute it and/or
# modify it under the same terms as Perl itself.
#
# This package retrieve information on mailbox from a FUD daemon,
# such as bundled by Cyrus imapd.
#
package Net::FUD;
use strict;
use vars qw($VERSION);
use IO::Socket::INET;
$VERSION = 0.01;
sub new {
my $class = shift;
my %self = @_;
unless ($self{'server'}) {
return undef;
}
unless ($self{'port'}) { $self{'port'} = 4201 }
# Connect to server
$self{'socket'} = IO::Socket::INET-new( PeerAddr = $self{'server'},
PeerPort = $self{'port'},
Proto= udp );
if ($self{'socket'}-error) {
$self{'error'} = Error connecting to $self{'server'}:$self{'port'}.;
}
my $ret = \%self;
bless ($ret, $class);
return $ret;
}
sub retr_info {
my $self = shift;
my $user = shift;
my $mbox = shift;
my $fh = $self-{'socket'};
my ($resp, @ret);
unless ($user) { return }
# FIXME : this make the assumption that the mailboxes separator is '.'
unless ($mbox) { $mbox = user. . $user }
print $fh $user|$mbox;
sysread($fh, $resp, 511);
if ($resp eq PERMDENY) {
$self-{'error'} = Permission denied;
} elsif($resp eq UNKNOWN) {
$self-{'error'} = User or mailbox unknown;
} else {
# Parse response
@ret = split /\|/, $resp;
}
return @ret;
}
sub error {
my $self = shift;
return $self-{'error'};
}
# Not sure if these two are necessary
sub close {
my $self = shift;
$self-{'socket'}-close;
}
sub DESTROY {
my $self = shift;
$self-close;
}
1;
__END__
=head1 NAME
Net::FUD - FUD Client class
=head1 SYNOPSIS
use Net::FUD;
$fud = Net::FUD-new( server = some.host.name, port = 4201);
@info = $fud(johndoe, user.johndoe.folder)
$err = $fud-error
=head1 DESCRIPTION
CNet::FUD is a class implementing a simple client in Perl to the FUD daemon
as shipped with ICyrus imapd.
=head1 CONSTRUCTOR
=over 4
=item new ( server = HOST [, port = PORT ])
Create a new CNet::FUD object where HOST is the host to connect to.
Optionnally, you can specify the port PORT (default udp/4201).
=back
=head1 METHODS
=over 4
=item retr_info ( USER [, MAILBOX ])
Retrieve information for mailbox MAILBOX (default to user.USER if
unspecified) and user USER. Return an array of five elements on
success, false otherwise. The content of the array is as follow :
=over 5
=item *
$ret[0] : The user for which the information was retrieved
=item *
$ret[1] : The mailbox for which the information was retrieved.
=item *
$ret[2] : Number of messages unseen by the user in this mailbox.
=item *
$ret[3] : Last time Iuser have read the mailbox, in typical Unix timestamp
(second since the epoch) suitable for Clocaltime().
=item *
$ret[4] : Last time a message was delivered to the Iuser's mailbox, in Unix
timestamp.
=back
=item close
Close the connection.
=item error
If there was an error then this method will return an error string.
=back
=head1 AUTHOR
Etienne Goyer [EMAIL PROTECTED] Linux Québec Technologies
inc.
=head1 COPYRIGHT
Copyright (c) 2003 Etienne Goyer, Linux Québec Technologies
[EMAIL PROTECTED]. All rights reserved.
This program is free software; you can redistribute it and/or modify
it under the same terms as Perl itself.
=cut
Re: ACL when creating mailbox in IMAP utf7
On Thu, 5 Jun 2003, Etienne Goyer wrote: When I create a top-level mailbox containing IMAP-style utf7 caracters, it does not get any ACL. The problem appear wheter using cyradm or not. Example : localhost.localdomain cm 'user.AOkA6QDp-' localhost.localdomain lam 'user.AOkA6QDp-' localhost.localdomain cm user.testing localhost.localdomain lam user.testing testing lrswipcda Maybe top-level mailboxes are supposed to only use 7 bits caracters ? Most likely the authorization module doesn't like the username. (auth_unix does not allow , for example). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
ACL when creating mailbox in IMAP utf7
Hi, When I create a top-level mailbox containing IMAP-style utf7 caracters, it does not get any ACL. The problem appear wheter using cyradm or not. Example : localhost.localdomain cm 'user.AOkA6QDp-' localhost.localdomain lam 'user.AOkA6QDp-' localhost.localdomain cm user.testing localhost.localdomain lam user.testing testing lrswipcda Maybe top-level mailboxes are supposed to only use 7 bits caracters ? -- Etienne GoyerLinux Québec Technologies Inc. http://www.LinuxQuebec.com [EMAIL PROTECTED]
Re: [PATCH] fud.c : timeout in do_proxy_request
On Wed, 4 Jun 2003, Etienne Goyer wrote: The fud daemon can proxy request for mailbox that are remote (ie Murder). In 2.1.13, the fud daemon will just sit there if the remote fud is not responding. It is strange because the recvfrom() is alarm()'ed; however, the SIGALRM handler do nothing else than clear the signal. It shouldn't need to, when the alarm goes off recvfrom should return with a value of -1 and errno = EINTR, and therefore fud should continue on as normal (the next line catches the error). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: [PATCH] fud.c : timeout in do_proxy_request
recvfrom() does not return when alarm() trigger. I am testing it on Linux RedHat 7.3, glibc 2.2.5. I am experiencing this problem when querying the fud daemon on the MUPDATE master of Murder and the backend on which the queryed mailbox reside does not have fud running. If you use fud-client to test it yourself, it must be taken into account that it include its own timeout code. It is possible to use the FUD Perl module I posted earlier instead as it does not include any timeout mechanism. Can somebody else using another OS/libc combo test it on their rig to confirm the bug is specific to my setup (or not) ? Thanks for your feedback. On Thu, Jun 05, 2003 at 11:04:04AM -0400, Rob Siemborski wrote: On Wed, 4 Jun 2003, Etienne Goyer wrote: The fud daemon can proxy request for mailbox that are remote (ie Murder). In 2.1.13, the fud daemon will just sit there if the remote fud is not responding. It is strange because the recvfrom() is alarm()'ed; however, the SIGALRM handler do nothing else than clear the signal. It shouldn't need to, when the alarm goes off recvfrom should return with a value of -1 and errno = EINTR, and therefore fud should continue on as normal (the next line catches the error). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper -- Etienne GoyerLinux Québec Technologies Inc. http://www.LinuxQuebec.com [EMAIL PROTECTED]
Sorry for the trouble
Hi, 1 h ago I studied my logfiles and I wondered who sent so many emails to [EMAIL PROTECTED] through our mailsystem. Quickly I came to the conclusion that this was my fault. Yesterday I installed SpamAssassin und unfortunatly I made a big mistake so that all emails sent to [EMAIL PROTECTED] were re-sent to [EMAIL PROTECTED] Immediatly I stopped the system and fixed the problem. I hope you can forgive me that silly adventure Regards, Marek
Re: ACL when creating mailbox in IMAP utf7
Effectively, imapd had been configured with --with-auth=unix. Is there an alternative or a workaround, beside the obvious not using 8 bit caracter in mailbox name ? Also, the ACL are not shown but does it exist ? Finally, does that mean that it is impossible to have username containing 8 bit caracters if imapd had been compiled with --with-auth=unix ? On Thu, Jun 05, 2003 at 11:06:09AM -0400, Rob Siemborski wrote: On Thu, 5 Jun 2003, Etienne Goyer wrote: When I create a top-level mailbox containing IMAP-style utf7 caracters, it does not get any ACL. The problem appear wheter using cyradm or not. Example : localhost.localdomain cm 'user.AOkA6QDp-' localhost.localdomain lam 'user.AOkA6QDp-' localhost.localdomain cm user.testing localhost.localdomain lam user.testing testing lrswipcda Maybe top-level mailboxes are supposed to only use 7 bits caracters ? Most likely the authorization module doesn't like the username. (auth_unix does not allow , for example). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper -- Etienne GoyerLinux Québec Technologies Inc. http://www.LinuxQuebec.com [EMAIL PROTECTED]
Re: ACL when creating mailbox in IMAP utf7
On Thu, 5 Jun 2003, Etienne Goyer wrote: Effectively, imapd had been configured with --with-auth=unix. Is there an alternative or a workaround, beside the obvious not using 8 bit caracter in mailbox name ? No workarounds without fixing the authorization module, no. Also, the ACL are not shown but does it exist ? It doesn't exist. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Subject field corruption
I use Postfix 2.0.10 with TLS patch, cyrus-imapd 2.1.13, sasl 2.1.13 The problem is as follow: When a message with russian charset characters (KOI8-R, WIN1251) in Subject field arrives or is moved into the Sent Items folders by Outlook Express, each russian character is replaced by an X (ex: Re: mazda 626 ). I happens only when the Subject field is without charaterset specification. I dumped mailboxes with cyrdump, the Xes are in. What can be wrog? I will appreciate any help. Max. -- Real programmers never sleep. They enter brainsaver mode.
Re: Subject field corruption
On Thu, 5 Jun 2003, NOwlar wrote: I dumped mailboxes with cyrdump, the Xes are in. What can be wrog? I will appreciate any help. The sending client included raw 8-bit data in the headers, which is not allowed. Cyrus dealt with this problem by munging the header to be valid. You can set reject8bit: t in your imapd.conf to outright reject the messages. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Subject field corruption
NOwlar wrote: I use Postfix 2.0.10 with TLS patch, cyrus-imapd 2.1.13, sasl 2.1.13 The problem is as follow: When a message with russian charset characters (KOI8-R, WIN1251) in Subject field arrives or is moved into the Sent Items folders by Outlook Express, each russian character is replaced by an X (ex: Re: mazda 626 ). I happens only when the Subject field is without charaterset specification. I dumped mailboxes with cyrdump, the Xes are in. What can be wrog? The problem is that 8-bit characters are not allowed in the header of an RFC822 message. There are extensions designed to allow 8-bit characters, by encoding the character set and a base64 or quoted-printable representation of them. The problem is that Cyrus cannot properly transform these messages to standards compliance since it cannot know what character set was used, only that it wasn't US-ASCII, so Cyrus chooses to either drop the message or replace all 8-bit characters with X depending on a configuration setting. There was some discussion of hacking Cyrus to allow an administrator-supplied default character set in the case of 8-bit data without a character set, but the consensus of the developers seemed to be that was more an MTA function than Cyrus, and nobody felt like doing a hack that would not be accepted into the official source. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
Re: Weird pop3d hang problem (fd blocked?!)
On Thu, Jun 05, 2003 at 11:14:47AM +1000, Stewart wrote: Thanks for your reply Patrick (all 8 of them :) but i was hoping there'd be a fix that didn't involve compiling.. this is a production server installed from a debian pkg so compilation isn't really an option at this stage.. Last time I ran out of entropy, I had to log in and do a ls -R / to get the password prompt :-) I believe moving the mouse might also work, but as said box has no keyboard/mouse/monitor, and as collection from network packet timestamps is now deemed unsafe as the network traffic may be styled by an attacker(!) the number of sources of entropy are sadly low - time of disk access when most data remains in NetBSD's Unified Buffer Cache (that's why the ls worked)? So, I went for the recompile... Maybe you have a Debian bell/whistle for this instead? Good luck, Patrick
auth_unix.c and make
Hello, I am attemtping to install Cyrus-imapd-2.1.13 from source on a Cygwin setup(W2k.) The cyrus-sasl compiled just fine from source however I am getting this error when running make all CFLAGS=-O auth_unix.c auth_unix.c: In function `auth_canonifyid': auth_unix.c:188: warning: assignment makes pointer from integer wi auth_unix.c:190: dereferencing pointer to incomplete type auth_unix.c: In function `auth_newstate': auth_unix.c:245: warning: assignment makes pointer from integer wi auth_unix.c:246: dereferencing pointer to incomplete type auth_unix.c:250: dereferencing pointer to incomplete type auth_unix.c:254: dereferencing pointer to incomplete type make[1]: *** [auth_unix.o] Error 1 make[1]: Leaving directory `/usr/local/tmp/cyrus-imapd-2.1.13/lib' make: *** [all] Error 1 I configured using ./configure --with-auth=unix and the make depend goes fine. I am stumped on this error. If someone could help me out with this I greatly appreciate it. Thanks in advance __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
Re: Subject field corruption
NOwlar wrote: I use Postfix 2.0.10 with TLS patch, cyrus-imapd 2.1.13, sasl 2.1.13 The problem is as follow: When a message with russian charset characters (KOI8-R, WIN1251) in Subject field arrives or is moved into the Sent Items folders by Outlook Express, each russian character is replaced by an X (ex: Re: mazda 626 ). I happens only when the Subject field is without charaterset specification. I dumped mailboxes with cyrdump, the Xes are in. What can be wrog? Maybe postfix can auto-convert these messages for you ? In sendmail you could do something like: define(`confSEVEN_BIT_INPUT', `false')dnl define(`confEIGHT_BIT_HANDLING', `mime')dnl define(`confDEF_CHAR_SET', `iso-8859-15')dnl but such a solution can produce quite ugly results if the message beeing autoconverted does not apply to the default charset in use. I stopped using such features because squatter stopped working for certain mailboxes in which auto-converted messages resided, I think. I would suggest setting reject8bit in imapd.conf to yes so that these non-standard-compliant messages get rejected. It is more a mta issue somehow than cyrus! Your mta delivers non-standard-compliant messages to cyrus and leaves the decision what to do with them to cyrus instead of just rejecting everything non-standarad-compliant. For me, the sender should get notice about the wrong behaving client and is the one to fix the problem on his side. I mainly had problems with messages coming from some webmail clients and I stopped caring about anybody who knows about the existence of e.g. php's mail function but does not know how to send messages with it correctly! If you see X in your messages cyrus just corrected a message the sender's client was not able to specify a character-set for correctly! --Christian
Mailbox namespace + LMTP question (repost)
Wasn't sure if this request was lost in the mail loop the sysadmin mentioned earlier today, so here's a repost. Please disregard if you've already received it. I'm running cyrus-imapd 2.1.13 w/cyrus-sasl 2.1.13 on a RedHat 9.0 system. My goal is have my mailer hand off a message to deliver with the recepient mailbox in an e-mail address format: [EMAIL PROTECTED]. I'm not sure if I've violoated the mailbox namespace by trying to use names containing the @ character...deliver refuses to deliver any messages to mailboxes I've created with this character in their name. I get the Mailbox does not exist error message whenever I try. I am able to deliver messages using deliver when I give it a recepient without the @ character. If the @ character violates the mailbox namespace, then why does cyradm let me create mailboxes that contain it? Reconstruct, ctl_mbxolist, and the other utilites / commands seem to be okay with it as well. useful lines in /etc/imapd.conf are: hashimapspool: true unixhierarchysep: yes Thanks in advance for any light you can shed on this matter. Regards, Lars Peterson [EMAIL PROTECTED]
Re: Weird pop3d hang problem (fd blocked?!)
On Linux, there is the i810_rng driver that can gather entropy from some Intel chipset hardware random number generator. Debian have a package to use this driver as feed for the kernel entropy pool. My 0.02$ On Thu, Jun 05, 2003 at 07:03:31PM +0100, Patrick Welche wrote: On Thu, Jun 05, 2003 at 11:14:47AM +1000, Stewart wrote: Thanks for your reply Patrick (all 8 of them :) but i was hoping there'd be a fix that didn't involve compiling.. this is a production server installed from a debian pkg so compilation isn't really an option at this stage.. Last time I ran out of entropy, I had to log in and do a ls -R / to get the password prompt :-) I believe moving the mouse might also work, but as said box has no keyboard/mouse/monitor, and as collection from network packet timestamps is now deemed unsafe as the network traffic may be styled by an attacker(!) the number of sources of entropy are sadly low - time of disk access when most data remains in NetBSD's Unified Buffer Cache (that's why the ls worked)? So, I went for the recompile... Maybe you have a Debian bell/whistle for this instead? Good luck, Patrick -- Etienne GoyerLinux Québec Technologies Inc. http://www.LinuxQuebec.com [EMAIL PROTECTED]
Re: Weird pop3d hang problem (fd blocked?!)
On Thu, 5 Jun 2003, Stewart wrote: Thanks for your reply Patrick (all 8 of them :) but i was hoping there'd be a fix that didn't involve compiling.. this is a production server installed from a debian pkg so compilation isn't really an option at this stage.. You can symlink /dev/random to point at /dev/urandom, but keep in mind that will affect all applications, not just cyrus. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
remove
remove
Re: Weird pop3d hang problem (fd blocked?!)
Rob Siemborski wrote: You can symlink /dev/random to point at /dev/urandom, but keep in mind that will affect all applications, not just cyrus. And in particular you may not want to do this if you are generating RSA private keys or equivalent on a machine that anyone else may have shell access to. I would think that whoever packaged it chose poorly. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
Problems with Cyrus IMAP 2.1.13
Hi all. Just upgraded our production server to 2.1.13. I must confess, yesterday afternoon and evening were full of Gremlins (those little creatures that screw up your, otherwise, perfect plan for upgrade). Well, I got the Cyrus UP and RUNNING, but there are some subtle points which fail and make me nervous. POINT 1: admin - I have users cyrus and root listed as admins in the imapd.conf file. I can login as root via cyradm, no problem (cyradm --auth=cram-md5 --user=root localhost). I can create mailboxes cm user.nikola. What I cannot do is: list mailboxes (lm just gives empty line), delete a mailbox (dm user.ene just gives deletemailbox: and the mailbox is still there) list ACL for a mailbox (again, a blank line) I CAN set ACL for mailbox (sam user.ene root lrwp gives setaclmailbox: root: lrwp:) What is going on here? I'd expect it to be some general ACL problem, but if someone can advise, I'd be grateful. POINT 2: imapd complains I am seeing this in imap.log Jun 6 07:54:40 Mercury master[5235]: about to exec /usr/opt/Cyrus-IMAP-2.1.13/sbin/imapd Jun 6 07:54:40 Mercury imaps[5235]: executed Jun 6 07:54:40 Mercury imapd[5235]: accepted connection Jun 6 07:54:40 Mercury imapd[5235]: mystore: starting txn 2147483707 Jun 6 07:54:40 Mercury imapd[5235]: mystore: committing txn 2147483707 Jun 6 07:54:40 Mercury imapd[5235]: starttls: TLSv1 with cipher RC4-MD5 (128/128 bits new) no authentication Jun 6 07:54:40 Mercury imapd[5235]: login: Brigitte.ev.co.yu[192.168.61.110] nikola plaintext+TLS Jun 6 07:54:40 Mercury imapd[5235]: seen_db: user nikola opened /var/opt/Cyrus-IMAP-2.1.13/config/user/n/nikola.seen Jun 6 07:54:40 Mercury imapd[5235]: open: user nikola opened INBOX Jun 6 07:54:41 Mercury imapd[5235]: Connection reset by peer, closing connection Jun 6 07:54:41 Mercury imapd[5235]: Could not shut down filedescriptor 0: Socket is not connected Jun 6 07:54:41 Mercury imapd[5235]: Could not shut down filedescriptor 1: Socket is not connected Jun 6 07:54:41 Mercury imapd[5235]: Could not shut down filedescriptor 2: Socket is not connected Jun 6 08:00:52 Mercury master[5337]: about to exec /usr/opt/Cyrus-IMAP-2.1.13/sbin/lmtpd Jun 6 08:00:52 Mercury lmtpunix[5337]: executed Jun 6 08:00:53 Mercury lmtpd[5337]: accepted connection Jun 6 08:00:53 Mercury lmtpd[5337]: lmtp connection preauth'd as postman Jun 6 08:00:53 Mercury lmtpd[5337]: duplicate_check: [EMAIL PROTECTED] user.nikola 0 Jun 6 08:00:53 Mercury lmtpd[5337]: mystore: starting txn 2147483730 Jun 6 08:00:53 Mercury lmtpd[5337]: mystore: committing txn 2147483730 Jun 6 08:00:53 Mercury lmtpd[5337]: duplicate_mark: [EMAIL PROTECTED] user.nikola 1054879253 Jun 6 08:00:53 Mercury lmtpd[5337]: Could not shut down filedescriptor 0: Socket is not connected Jun 6 08:00:53 Mercury lmtpd[5337]: Could not shut down filedescriptor 1: Socket is not connected Jun 6 08:00:53 Mercury lmtpd[5337]: Could not shut down filedescriptor 2: Socket is not connected POINT 3: (could be gone) IdleD problems. --- I was seeing complaints from both imapd and lmtpd, that they couldn't connect to idled socket, but those are gone at the moment. The log contained this: Jun 6 06:57:43 Mercury master[3365]: about to exec /usr/opt/Cyrus-IMAP-2.1.13/sbin/imapd Jun 6 06:57:43 Mercury imap[3365]: executed Jun 6 06:57:44 Mercury imapd[3365]: accepted connection Jun 6 06:57:44 Mercury imapd[3365]: login: webmaster.ev.co.yu[192.168.61.105] davor plaintext Jun 6 06:57:47 Mercury imapd[3676]: error sending to idled: 0 Jun 6 06:57:47 Mercury imapd[3676]: error sending to idled: 1 Jun 6 06:57:48 Mercury imapd[3676]: seen_db: user davor opened /var/opt/Cyrus-IMAP-2.1.13/config/user/d/davor.seen Jun 6 06:57:48 Mercury imapd[3676]: error sending to idled: 0 Jun 6 06:57:48 Mercury imapd[3676]: error sending to idled: 1 Jun 6 06:57:48 Mercury imapd[3676]: Could not shut down filedescriptor 0: Socket is not connected Jun 6 06:57:48 Mercury imapd[3676]: Could not shut down filedescriptor 1: Socket is not connected Jun 6 06:57:48 Mercury imapd[3676]: Could not shut down filedescriptor 2: Socket is not connected Jun 6 06:57:48 Mercury imapd[3676]: accepted connection Jun 6 06:57:48 Mercury imapd[3676]: login: webmaster.ev.co.yu[192.168.61.105] davor plaintext Jun 6 06:57:49 Mercury master[2888]: about to exec /usr/opt/Cyrus-IMAP-2.1.13/sbin/pop3d Jun 6 06:57:49 Mercury pop3[2888]: executed Jun 6 06:57:49 Mercury pop3d[2888]: accepted connection Jun 6 06:57:49 Mercury pop3d[2888]: login: Celeron2.ev.co.yu[192.168.1.135] draganal plaintext Jun 6 06:57:54 Mercury imapd[3365]: error sending to idled: 0 Jun 6 06:57:54 Mercury imapd[3365]: error sending to idled: 1 Jun 6 06:57:54 Mercury imapd[3365]: seen_db: user davor opened /var/opt/Cyrus-IMAP-2.1.13/config/user/d/davor.seen Jun 6 06:57:54 Mercury imapd[3365]:
[no subject]
Title: Message remove
Re: I can't get imtest to work
Mmm, Sounds a bit like your setting imap to be chrooted and you've not got a copy of /etc/services in the jail ??? (Not seen it with IMAP, but had a similar thing with postfix...) Gareth. On Fri, 2003-06-06 at 04:20, Ronald Rough wrote: Help: I can't run: imtest -m login -p imap localhost When I do, I get the following: Jun 5 20:13:35 roughrider imapd[22485]: could not getenv(CYRUS_SERVICE); exiting I was told that I should check the log files after I start the imap server. I need to know how to start the imap server. I need to know what to do to resolve the CYRUS_SERVICE error. Any ideas. Thanks, Ron -- 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: Problems with Cyrus IMAP 2.1.13
Hi, I've seen similar things here. Jun 6 06:57:59 Mercury pop3d[2888]: error sending to idled: 2 Means that something has crashed badly. Jun 6 06:57:48 Mercury imapd[3676]: Could not shut down filedescriptor 0: Socket is not connected Means your client has dropped out 'uncleanly'. Or at least this is what I gather after hours of 'fun'. I do however have a solution, I was running a ctl_cyrusdb -r followed by a reconstruct and still getting the problems.. which sort of lead me to believe it wasn't a DB problem. However, I noticed that every time I ran a reconstruct I ended up with more DB problems a little later. (!) My fix;; (now you'll probably tell me I should have known this, but because (a) it let me and (b) I don't want to shut down the system, I didn't try it earlier) Shut down Cyrus and let incoming queue and users cry. ctl_cyrusdb -r reconstruct Start Cyrus back up. All is now well with the world and at present I'm not seeing more problems Either there is a bug and the recovery/reconstruct code isn't locking properly, or we need some bigger notices in the docs to let people know these things need a cyrus shutdown HTH Gareth. On Fri, 2003-06-06 at 07:19, Nikola Milutinovic wrote: Hi all. Just upgraded our production server to 2.1.13. I must confess, yesterday afternoon and evening were full of Gremlins (those little creatures that screw up your, otherwise, perfect plan for upgrade). Well, I got the Cyrus UP and RUNNING, but there are some subtle points which fail and make me nervous. POINT 1: admin - I have users cyrus and root listed as admins in the imapd.conf file. I can login as root via cyradm, no problem (cyradm --auth=cram-md5 --user=root localhost). I can create mailboxes cm user.nikola. What I cannot do is: list mailboxes (lm just gives empty line), delete a mailbox (dm user.ene just gives deletemailbox: and the mailbox is still there) list ACL for a mailbox (again, a blank line) I CAN set ACL for mailbox (sam user.ene root lrwp gives setaclmailbox: root: lrwp:) What is going on here? I'd expect it to be some general ACL problem, but if someone can advise, I'd be grateful. POINT 2: imapd complains I am seeing this in imap.log Jun 6 07:54:40 Mercury master[5235]: about to exec /usr/opt/Cyrus-IMAP-2.1.13/sbin/imapd Jun 6 07:54:40 Mercury imaps[5235]: executed Jun 6 07:54:40 Mercury imapd[5235]: accepted connection Jun 6 07:54:40 Mercury imapd[5235]: mystore: starting txn 2147483707 Jun 6 07:54:40 Mercury imapd[5235]: mystore: committing txn 2147483707 Jun 6 07:54:40 Mercury imapd[5235]: starttls: TLSv1 with cipher RC4-MD5 (128/128 bits new) no authentication Jun 6 07:54:40 Mercury imapd[5235]: login: Brigitte.ev.co.yu[192.168.61.110] nikola plaintext+TLS Jun 6 07:54:40 Mercury imapd[5235]: seen_db: user nikola opened /var/opt/Cyrus-IMAP-2.1.13/config/user/n/nikola.seen Jun 6 07:54:40 Mercury imapd[5235]: open: user nikola opened INBOX Jun 6 07:54:41 Mercury imapd[5235]: Connection reset by peer, closing connection Jun 6 07:54:41 Mercury imapd[5235]: Could not shut down filedescriptor 0: Socket is not connected Jun 6 07:54:41 Mercury imapd[5235]: Could not shut down filedescriptor 1: Socket is not connected Jun 6 07:54:41 Mercury imapd[5235]: Could not shut down filedescriptor 2: Socket is not connected Jun 6 08:00:52 Mercury master[5337]: about to exec /usr/opt/Cyrus-IMAP-2.1.13/sbin/lmtpd Jun 6 08:00:52 Mercury lmtpunix[5337]: executed Jun 6 08:00:53 Mercury lmtpd[5337]: accepted connection Jun 6 08:00:53 Mercury lmtpd[5337]: lmtp connection preauth'd as postman Jun 6 08:00:53 Mercury lmtpd[5337]: duplicate_check: [EMAIL PROTECTED] user.nikola 0 Jun 6 08:00:53 Mercury lmtpd[5337]: mystore: starting txn 2147483730 Jun 6 08:00:53 Mercury lmtpd[5337]: mystore: committing txn 2147483730 Jun 6 08:00:53 Mercury lmtpd[5337]: duplicate_mark: [EMAIL PROTECTED] user.nikola 1054879253 Jun 6 08:00:53 Mercury lmtpd[5337]: Could not shut down filedescriptor 0: Socket is not connected Jun 6 08:00:53 Mercury lmtpd[5337]: Could not shut down filedescriptor 1: Socket is not connected Jun 6 08:00:53 Mercury lmtpd[5337]: Could not shut down filedescriptor 2: Socket is not connected POINT 3: (could be gone) IdleD problems. --- I was seeing complaints from both imapd and lmtpd, that they couldn't connect to idled socket, but those are gone at the moment. The log contained this: Jun 6 06:57:43 Mercury master[3365]: about to exec /usr/opt/Cyrus-IMAP-2.1.13/sbin/imapd Jun 6 06:57:43 Mercury imap[3365]: executed Jun 6 06:57:44 Mercury imapd[3365]: accepted connection Jun 6 06:57:44 Mercury imapd[3365]: login: webmaster.ev.co.yu[192.168.61.105] davor plaintext Jun 6 06:57:47 Mercury imapd[3676]: error sending to idled: 0 Jun 6 06:57:47 Mercury imapd[3676]: error sending to idled: 1 Jun 6 06:57:48 Mercury imapd[3676]: seen_db: user davor
Cyrus Imap refuses to work with vpopmail maildir
Hello All, This is my first post to the list. RedHat 7.3 Apache 1.3.27 PHP 4.3.1 Qmail SquirrelMail 1.0.4 qmailadmin 1.0.20 vpopmail 5.3.20 Cyrus Imap. The above is my setup. I have created mail accounts for my virtual domain with vpopmail and they are working fine with QmailAdmin. When i try to login to SquirrelMail which is on SSL and uses Cyrus Imap server It simply Says Incorrect Username/Password. I have checked the username and passwd they are perfectly correct and i can login with the same to qmail admin. Here i want to mark a point that these mail accounts are created with vpopmail and are in MailDir format. How how do i enable the working of my mail accounts with Cyrus ? Please put me on a correct path, i have searched and googled around but was unable to get what i want. Regards, Tina.
Sieve vacation not working
Hi,
I do have a set of rules, which are all working, and then, I add :
require vacation;
if header :contains subject vacation sieve {
vacation I'm outta here;
fileinto INBOX/mat;
stop;
}
It does file the mail into INBOX/mat but does not respond with anything.
Am I doing something wrong ?
--
Mathieu Arnold
Re: Subject field corruption
On Thu, Jun 05, 2003 at 08:57:38PM +0400, NOwlar wrote: I use Postfix 2.0.10 with TLS patch, cyrus-imapd 2.1.13, sasl 2.1.13 The problem is as follow: When a message with russian charset characters (KOI8-R, WIN1251) in Subject field arrives or is moved into the Sent Items folders by Outlook Express, each russian character is replaced by an X (ex: Re: mazda 626 ). I happens only when the Subject field is without charaterset specification. I dumped mailboxes with cyrdump, the Xes are in. What can be wrog? I will appreciate any help. Max. Cyrus kills the 8th bit character in the header, and replaces it with 'X'. There is a configuration option, that would discard unconditionally every message with the 8th bit turned on in the headers. Luckily you are *only* seeing the 'X' inserted instead. In Cyrus-2.0.16 one file needed to be patched. In the latest Cyrus-es you apparently need to patch 2 files. In my opinion, this breaks the Be liberal in what you accept, strict in what you send. Unfortunately (regardless of what the developers of Cyrus think) there are still software out there that generates email messages with 8th bit headers. -- [EMAIL PROTECTED]
Re: Sieve vacation not working
I believe you need an address option.
The vacation facility will only send out a message if the to address
matches the addresse(s) in the address option. This allows sieve to
prevent messages being sent to mailing lists, spam.
johnh...
On Fri, 6 Jun 2003, Mathieu Arnold wrote:
Hi,
I do have a set of rules, which are all working, and then, I add :
require vacation;
if header :contains subject vacation sieve {
vacation I'm outta here;
fileinto INBOX/mat;
stop;
}
It does file the mail into INBOX/mat but does not respond with anything.
Am I doing something wrong ?
--
Mathieu Arnold
Re: Problems with Cyrus IMAP 2.1.13
Nikola Milutinovic wrote: Hi all. Just upgraded our production server to 2.1.13. I must confess, yesterday afternoon and evening were full of Gremlins (those little creatures that screw up your, otherwise, perfect plan for upgrade). Well, I got the Cyrus UP and RUNNING, but there are some subtle points which fail and make me nervous. POINT 1: admin - I have users cyrus and root listed as admins in the imapd.conf file. I can login as root via cyradm, no problem (cyradm --auth=cram-md5 --user=root localhost). I can create mailboxes cm user.nikola. What I cannot do is: list mailboxes (lm just gives empty line), delete a mailbox (dm user.ene just gives deletemailbox: and the mailbox is still there) You need to have the 'c' right in order to create/delete a mailbox. list ACL for a mailbox (again, a blank line) I CAN set ACL for mailbox (sam user.ene root lrwp gives setaclmailbox: root: lrwp:) What is going on here? I'd expect it to be some general ACL problem, but if someone can advise, I'd be grateful. It _could_ be an ACL problem, but I'd be more inclined to think its a Perl problem. Try doing this: imtest -a root -m cram-md5 localhost . LIST * . GETACL user.ene POINT 2: imapd complains I am seeing this in imap.log You're logging an the local6.debug level. Step this down to local6.info and these will go away. POINT 3: (could be gone) IdleD problems. --- I was seeing complaints from both imapd and lmtpd, that they couldn't connect to idled socket, but those are gone at the moment. The log contained this: Jun 6 06:57:43 Mercury master[3365]: about to exec /usr/opt/Cyrus-IMAP-2.1.13/sbin/imapd Jun 6 06:57:43 Mercury imap[3365]: executed Jun 6 06:57:44 Mercury imapd[3365]: accepted connection Jun 6 06:57:44 Mercury imapd[3365]: login: webmaster.ev.co.yu[192.168.61.105] davor plaintext Jun 6 06:57:47 Mercury imapd[3676]: error sending to idled: 0 Jun 6 06:57:47 Mercury imapd[3676]: error sending to idled: 1 Jun 6 06:57:48 Mercury imapd[3676]: seen_db: user davor opened /var/opt/Cyrus-IMAP-2.1.13/config/user/d/davor.seen Jun 6 06:57:48 Mercury imapd[3676]: error sending to idled: 0 Jun 6 06:57:48 Mercury imapd[3676]: error sending to idled: 1 You configured Cyrus to use idled, but haven't added it to your cyrus.conf. If you have it in cyrus.conf, then it has crashed. -- 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: I can't get imtest to work
On Thu, 5 Jun 2003, Ronald Rough wrote: Jun 5 20:13:35 roughrider imapd[22485]: could not getenv(CYRUS_SERVICE); exiting Did you read the install documentation? It looks like you're trying to run imapd out of inetd, which hasn't been the way of doing things for a very very long time. You want to start the server by running the master process. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Subject field corruption
Einar Indridason wrote: On Thu, Jun 05, 2003 at 08:57:38PM +0400, NOwlar wrote: I use Postfix 2.0.10 with TLS patch, cyrus-imapd 2.1.13, sasl 2.1.13 The problem is as follow: When a message with russian charset characters (KOI8-R, WIN1251) in Subject field arrives or is moved into the Sent Items folders by Outlook Express, each russian character is replaced by an X (ex: Re: mazda 626 ). I happens only when the Subject field is without charaterset specification. I dumped mailboxes with cyrdump, the Xes are in. What can be wrog? I will appreciate any help. Max. Cyrus kills the 8th bit character in the header, and replaces it with 'X'. There is a configuration option, that would discard unconditionally every message with the 8th bit turned on in the headers. Luckily you are *only* seeing the 'X' inserted instead. In Cyrus-2.0.16 one file needed to be patched. In the latest Cyrus-es you apparently need to patch 2 files. In my opinion, this breaks the Be liberal in what you accept, strict in what you send. There is a difference between being liberal and being foolish. Unfortunately (regardless of what the developers of Cyrus think) there are still software out there that generates email messages with 8th bit headers. The users of such broken software should either pressure the author(s) to fix it or abandon it. Darwin's theory of evolution applies equally as well to software as it does to plants/animals. It has been mentioned MANY times that even if Cyrus was to accept 8-bit headers, there is no reasonable way to determine the character set. -- 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: Subject field corruption
On Fri, 6 Jun 2003, Einar Indridason wrote: In my opinion, this breaks the Be liberal in what you accept, strict in what you send. Actually, munging the data to Xs *is* being liberal in what is accepted and strict in what is sent. Since 8-bit characters in headers are nonsensical (there's no character set to go with them), changing them to Xs is the only way that cyrus can be strict in what it sends (IMAP is a 7-bit clean protocol, excepting the new BINARY extention which wouldn't allow 8-bit in this situation anyway). Having a default charset is a reasonable compromise, but I haven't seen anyone yet do the work (which would include properly QP-encoding the bogus headers). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Problems with Cyrus IMAP 2.1.13
On Fri, 6 Jun 2003, Gareth Bult wrote: Jun 6 06:57:48 Mercury imapd[3676]: Could not shut down filedescriptor 0: Socket is not connected Means your client has dropped out 'uncleanly'. Its a harmless log message, and if you're logging at LOG_DEBUG you should expect to see a lot of harmless log messages. In the next version of cyrus we've turned off logging for socket is not connected totally. Shut down Cyrus and let incoming queue and users cry. ctl_cyrusdb -r reconstruct Start Cyrus back up. You shouldn't ever need to reconstruct unless a mailbox is corrupted (And that can be done live). ctl_cyrusdb -r should *always* be run becfore cyrus starts (it should be in the START section of master.conf). Statements made are at all times subject to Frontier's Terms and Conditions of Business, which are available upon request. I'm not sure what these conditions are, but disclaimers like this generally can make it hard to take posts to public mailing in any serious way (for example, if the disclaimer is that the contents of the message on a public list is confidential what does that mean?) -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Problems with Cyrus IMAP 2.1.13
Means your client has dropped out 'uncleanly'. Its a harmless log message, and if you're logging at LOG_DEBUG you should expect to see a lot of harmless log messages. Sure. However I have noted that I only see this when my client dies, not when it exits.. [!] In the next version of cyrus we've turned off logging for socket is not connected totally. Shut down Cyrus and let incoming queue and users cry. ctl_cyrusdb -r reconstruct Start Cyrus back up. You shouldn't ever need to reconstruct unless a mailbox is corrupted (And that can be done live). ctl_cyrusdb -r should *always* be run becfore cyrus starts (it should be in the START section of master.conf). Ok, so what would you make of this;; Jun 5 23:17:54 core imapd[4579]: DBERROR: error fetching user.oddjob: DB_RUNRECOVERY: Fatal error, run database recovery Jun 5 23:18:28 core imapd[4579]: DBERROR: error fetching user.oddjob: cyrusdb error Jun 5 23:19:31 core imapd[4579]: DBERROR: error closing: DB_RUNRECOVERY: Fatal error, run database recovery Jun 5 23:19:31 core imapd[4579]: DBERROR: error closing mailboxes: cyrusdb error Jun 5 23:19:31 core imapd[4579]: DBERROR: error exiting application: DB_RUNRECOVERY: Fatal error, run database recovery Jun 5 23:19:31 core imapd[4579]: DBERROR: error exiting application: cyrusdb error Jun 5 23:19:33 core imapd[4601]: DBERROR: error closing: DB_RUNRECOVERY: Fatal error, run database recovery Jun 5 23:19:33 core imapd[4601]: DBERROR: error closing mailboxes: cyrusdb error Jun 5 23:19:33 core imapd[4601]: DBERROR: error exiting application: DB_RUNRECOVERY: Fatal error, run database recovery Jun 5 23:19:33 core imapd[4601]: DBERROR: error exiting application: cyrusdb error Jun 5 23:49:32 core imapd[4819]: DBERROR: error exiting application: DB_RUNRECOVERY: Fatal error, run database recovery Jun 5 23:49:32 core imapd[4819]: DBERROR: error exiting application: cyrusdb error Jun 5 23:54:48 core lmtpd[4421]: DBERROR: error fetching user.oddjob: DB_RUNRECOVERY: Fatal error, run database recovery Jun 5 23:54:48 core lmtpd[4421]: DBERROR: error fetching user.oddjob: cyrusdb error Jun 5 23:55:48 core lmtpd[4421]: DBERROR: error closing: DB_RUNRECOVERY: Fatal error, run database recovery Jun 5 23:55:48 core lmtpd[4421]: DBERROR: error closing deliverdb: cyrusdb error Jun 5 23:55:48 core lmtpd[4421]: DBERROR: error closing: DB_RUNRECOVERY: Fatal error, run database recovery Jun 5 23:55:48 core lmtpd[4421]: DBERROR: error closing mailboxes: cyrusdb error Jun 5 23:55:48 core lmtpd[4421]: DBERROR: error exiting application: DB_RUNRECOVERY: Fatal error, run database recovery Jun 5 23:55:48 core lmtpd[4421]: DBERROR: error exiting application: cyrusdb error Given runing recover does not fix it.. [?] Statements made are at all times subject to Frontier's Terms and Conditions of Business, which are available upon request. I'm not sure what these conditions are, but disclaimers like this generally can make it hard to take posts to public mailing in any serious way (for example, if the disclaimer is that the contents of the message on a public list is confidential what does that mean?) I refer to it as the legal bullshit that means that I don't get fired for sending an email. What it actually says is that you can't sue my employer for anything I say, even if I'm using my employer's systems. .. and if I didn't say it, then my emails would come to a very abrupt halt. Happy? Regards, Gareth. -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. attachment: smiley-3.png
Re: [PATCH] fud.c : timeout in do_proxy_request
Is there any hope somebody look at it ? On Thu, Jun 05, 2003 at 11:28:35AM -0400, Etienne Goyer wrote: recvfrom() does not return when alarm() trigger. I am testing it on Linux RedHat 7.3, glibc 2.2.5. I am experiencing this problem when querying the fud daemon on the MUPDATE master of Murder and the backend on which the queryed mailbox reside does not have fud running. If you use fud-client to test it yourself, it must be taken into account that it include its own timeout code. It is possible to use the FUD Perl module I posted earlier instead as it does not include any timeout mechanism. Can somebody else using another OS/libc combo test it on their rig to confirm the bug is specific to my setup (or not) ? Thanks for your feedback. On Thu, Jun 05, 2003 at 11:04:04AM -0400, Rob Siemborski wrote: On Wed, 4 Jun 2003, Etienne Goyer wrote: The fud daemon can proxy request for mailbox that are remote (ie Murder). In 2.1.13, the fud daemon will just sit there if the remote fud is not responding. It is strange because the recvfrom() is alarm()'ed; however, the SIGALRM handler do nothing else than clear the signal. It shouldn't need to, when the alarm goes off recvfrom should return with a value of -1 and errno = EINTR, and therefore fud should continue on as normal (the next line catches the error). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper -- Etienne GoyerLinux Québec Technologies Inc. http://www.LinuxQuebec.com [EMAIL PROTECTED] -- Etienne GoyerLinux Québec Technologies Inc. http://www.LinuxQuebec.com [EMAIL PROTECTED]
Re: Problems with Cyrus IMAP 2.1.13
On Fri, 6 Jun 2003, Gareth Bult wrote: You shouldn't ever need to reconstruct unless a mailbox is corrupted (And that can be done live). ctl_cyrusdb -r should *always* be run becfore cyrus starts (it should be in the START section of master.conf). Ok, so what would you make of this;; [snip] Jun 5 23:19:33 core imapd[4601]: DBERROR: error exiting application: DB_RUNRECOVERY: Fatal error, run database recovery Jun 5 23:19:33 core imapd[4601]: DBERROR: error exiting application: cyrusdb error Given runing recover does not fix it.. [?] Did you ever convert mailbox formats from berkley DB? If so, you many need to clean the log files. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Cyrus-Imap-2.2 with postfix
Has or does anyone use the 2.2 version with postfix. I cannot get any mail delivered to cyrus. the ususal statement (unknown user). I have created a user like cm [EMAIL PROTECTED] Set the imapd.conf file per the docs use the standard LMTP config within postfix Still no mail can be delivered outside of the default domain name. What should the master.cf file look like? Any help would be great Andy Vernon A. Fort (Andy) Provident Solutions, LLC (615) 427-4016 http://www.provident-solutions.com attachment: winmail.dat
Re: Problems with Cyrus IMAP 2.1.13
... Completely clean install ... Cyrus+Postfix+SASL+SA On Fri, 2003-06-06 at 14:30, Rob Siemborski wrote: On Fri, 6 Jun 2003, Gareth Bult wrote: You shouldn't ever need to reconstruct unless a mailbox is corrupted (And that can be done live). ctl_cyrusdb -r should *always* be run becfore cyrus starts (it should be in the START section of master.conf). Ok, so what would you make of this;; [snip] Jun 5 23:19:33 core imapd[4601]: DBERROR: error exiting application: DB_RUNRECOVERY: Fatal error, run database recovery Jun 5 23:19:33 core imapd[4601]: DBERROR: error exiting application: cyrusdb error Given runing recover does not fix it.. [?] Did you ever convert mailbox formats from berkley DB? If so, you many need to clean the log files. -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: [PATCH] fud.c : timeout in do_proxy_request
I just tried to duplicate the setup on our murder locally, and had no success (The proxy timed out appropriately). Of course, our proxies are on solaris... I did see fud-client timeout before the server did when I couldn't resolve the backend the server is on, but this isn't your problem if you are hanging in recvfrom(). -Rob On Fri, 6 Jun 2003, Etienne Goyer wrote: Is there any hope somebody look at it ? On Thu, Jun 05, 2003 at 11:28:35AM -0400, Etienne Goyer wrote: recvfrom() does not return when alarm() trigger. I am testing it on Linux RedHat 7.3, glibc 2.2.5. I am experiencing this problem when querying the fud daemon on the MUPDATE master of Murder and the backend on which the queryed mailbox reside does not have fud running. If you use fud-client to test it yourself, it must be taken into account that it include its own timeout code. It is possible to use the FUD Perl module I posted earlier instead as it does not include any timeout mechanism. Can somebody else using another OS/libc combo test it on their rig to confirm the bug is specific to my setup (or not) ? Thanks for your feedback. On Thu, Jun 05, 2003 at 11:04:04AM -0400, Rob Siemborski wrote: On Wed, 4 Jun 2003, Etienne Goyer wrote: The fud daemon can proxy request for mailbox that are remote (ie Murder). In 2.1.13, the fud daemon will just sit there if the remote fud is not responding. It is strange because the recvfrom() is alarm()'ed; however, the SIGALRM handler do nothing else than clear the signal. It shouldn't need to, when the alarm goes off recvfrom should return with a value of -1 and errno = EINTR, and therefore fud should continue on as normal (the next line catches the error). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper -- Etienne GoyerLinux Québec Technologies Inc. http://www.LinuxQuebec.com [EMAIL PROTECTED] -- Etienne GoyerLinux Québec Technologies Inc. http://www.LinuxQuebec.com [EMAIL PROTECTED] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
RH 9.0 ssl compiler error
Hi all, I am trying to compile Cyrus 2.1.13 on RH 9.0 but it keeps crapping out on ssl. I have included the ./configure and the error. Thanks all Rich ./configure --enable-netscapehack --enable-annotatemore --enable-listext --with-perl=/usr/bin/perl --with-libwrap=/usr --with-sasl=/usr --with-seen-db=db3_nosync --with-subs-db=db3_nosync --with-auth=unix gcc -c -I/usr/include -I/usr/include -I. -I.. -I. -I./../lib -DHAVE_CONFIG_H -Wall -g -O2 \ acap.c In file included from /usr/include/openssl/ssl.h:179, from ../lib/prot.h:54, from acap.c:64: /usr/include/openssl/kssl.h:72:18: krb5.h: No such file or directory In file included from /usr/include/openssl/ssl.h:179, from ../lib/prot.h:54, from acap.c:64: /usr/include/openssl/kssl.h:132: parse error before krb5_enctype /usr/include/openssl/kssl.h:134: parse error before FAR /usr/include/openssl/kssl.h:135: parse error before '}' token /usr/include/openssl/kssl.h:147: parse error before kssl_ctx_setstring /usr/include/openssl/kssl.h:147: parse error before '*' token /usr/include/openssl/kssl.h:148: parse error before '*' token /usr/include/openssl/kssl.h:149: parse error before '*' token /usr/include/openssl/kssl.h:149: parse error before '*' token /usr/include/openssl/kssl.h:150: parse error before '*' token /usr/include/openssl/kssl.h:151: parse error before kssl_ctx_setprinc /usr/include/openssl/kssl.h:151: parse error before '*' token /usr/include/openssl/kssl.h:153: parse error before kssl_cget_tkt /usr/include/openssl/kssl.h:153: parse error before '*' token /usr/include/openssl/kssl.h:155: parse error before kssl_sget_tkt /usr/include/openssl/kssl.h:155: parse error before '*' token /usr/include/openssl/kssl.h:157: parse error before kssl_ctx_setkey /usr/include/openssl/kssl.h:157: parse error before '*' token /usr/include/openssl/kssl.h:159: parse error before context /usr/include/openssl/kssl.h:160: parse error before kssl_build_principal_2 /usr/include/openssl/kssl.h:160: parse error before context /usr/include/openssl/kssl.h:163: parse error before kssl_validate_times /usr/include/openssl/kssl.h:163: parse error before atime /usr/include/openssl/kssl.h:165: parse error before kssl_check_authent /usr/include/openssl/kssl.h:165: parse error before '*' token /usr/include/openssl/kssl.h:167: parse error before enctype In file included from ../lib/prot.h:54, from acap.c:64: /usr/include/openssl/ssl.h:909: parse error before KSSL_CTX /usr/include/openssl/ssl.h:931: parse error before '}' token make[1]: *** [acap.o] Error 1 make[1]: Leaving directory `/mnt/nfs/cyrus-imapd-2.1.13/acap' make: *** [all] Error 1
Re: LMTP Network delivery
Update: I was able to work around the problem by adding a line of code to the cyrus source version 2.0.17 (which is what I am currently using...): in imap/lmtpengine.c around line 470... Original code: -- return s; -- Hacked code: -- lcase(s); return s; -- Seems to be working like a charm. 'lcase' is a function I found in lib/util.h Does anyone see any problems with this other than the obvious which is you can never delivery mail to an Uppercase mailbox? Thanks, -John John C. Amodeo wrote: Greetings, I have a minor problem. I'm migrating to a Postfix 2.0.10 server using LMTP delivery to a Cyrus server over the network via transport maps. When users send e-mail to an account that has a capital letter in it, the mail bounces because the account is unknown. Is there any way to have Postfix lowercase all addresses before they are forwarded to the transport map? Thanks, -John
Debug output
hi, which lines i have to write into my syslog.conf, to stop the debug output. cu denny signature.asc Description: This is a digitally signed message part
Re: RH 9.0 ssl compiler error
Richard Houston said:
Hi all,
I am trying to compile Cyrus 2.1.13 on RH 9.0 but it keeps crapping out
I had the same problem recently. Let me know if --without-krb works,
but I don't think it does. A friend of mine wrote this perl script to fix
it:
#!/usr/bin/perl -w
# FIXIT: for use in cyrus-imapd until they catch up to Redhat's recent
#location for kerberos include files
use strict;
# these are the subdirectories with Makefiles which need modification
my @dirs = qw( acap lib imap imtest perl/sieve/lib timsieved );
foreach (@dirs) {
my $file = $_/Makefile;
open F, $file; # read all lines from the Makefile
my @lines = F;
close F;
open F, $file;# rewrite the Makefile
foreach (@lines) {
chomp;# strip off newline
# append -I/usr/kerberos/include to the CPPFLAGS line
# if it's not already there
$_ .= -I/usr/kerberos/include if /^CPPFLAGS/ ! /kerberos/;
print F $_\n;# write the line to the file
}
close F;
}
--
Trooper Jon S. Nelson, Linux Certified Admin.
Pa. State Police, Bureau of Criminal Investigation
Computer Crimes Unit
Work: 610.344.4471 Cell/Page: 866.284.1603
[EMAIL PROTECTED]
Re: RH 9.0 ssl compiler error
Hi, Assuming you're a normal linux user and don't use Kerberos ( ) and don't want Krb on the system, try setting defs in configure to be; DEFS=-DHAVE_CONFIG_H -DOPENSSL_NO_KRB5 Works fine for me... Regards, Gareth. On Fri, 2003-06-06 at 17:00, Richard Houston wrote: Hi all, I am trying to compile Cyrus 2.1.13 on RH 9.0 but it keeps crapping out on ssl. I have included the ./configure and the error. Thanks all Rich ./configure --enable-netscapehack --enable-annotatemore --enable-listext --with-perl=/usr/bin/perl --with-libwrap=/usr --with-sasl=/usr --with-seen-db=db3_nosync --with-subs-db=db3_nosync --with-auth=unix gcc -c -I/usr/include -I/usr/include -I. -I.. -I. -I./../lib -DHAVE_CONFIG_H -Wall -g -O2 \ acap.c In file included from /usr/include/openssl/ssl.h:179, from ../lib/prot.h:54, from acap.c:64: /usr/include/openssl/kssl.h:72:18: krb5.h: No such file or directory In file included from /usr/include/openssl/ssl.h:179, from ../lib/prot.h:54, from acap.c:64: /usr/include/openssl/kssl.h:132: parse error before krb5_enctype /usr/include/openssl/kssl.h:134: parse error before FAR /usr/include/openssl/kssl.h:135: parse error before '}' token /usr/include/openssl/kssl.h:147: parse error before kssl_ctx_setstring /usr/include/openssl/kssl.h:147: parse error before '*' token /usr/include/openssl/kssl.h:148: parse error before '*' token /usr/include/openssl/kssl.h:149: parse error before '*' token /usr/include/openssl/kssl.h:149: parse error before '*' token /usr/include/openssl/kssl.h:150: parse error before '*' token /usr/include/openssl/kssl.h:151: parse error before kssl_ctx_setprinc /usr/include/openssl/kssl.h:151: parse error before '*' token /usr/include/openssl/kssl.h:153: parse error before kssl_cget_tkt /usr/include/openssl/kssl.h:153: parse error before '*' token /usr/include/openssl/kssl.h:155: parse error before kssl_sget_tkt /usr/include/openssl/kssl.h:155: parse error before '*' token /usr/include/openssl/kssl.h:157: parse error before kssl_ctx_setkey /usr/include/openssl/kssl.h:157: parse error before '*' token /usr/include/openssl/kssl.h:159: parse error before context /usr/include/openssl/kssl.h:160: parse error before kssl_build_principal_2 /usr/include/openssl/kssl.h:160: parse error before context /usr/include/openssl/kssl.h:163: parse error before kssl_validate_times /usr/include/openssl/kssl.h:163: parse error before atime /usr/include/openssl/kssl.h:165: parse error before kssl_check_authent /usr/include/openssl/kssl.h:165: parse error before '*' token /usr/include/openssl/kssl.h:167: parse error before enctype In file included from ../lib/prot.h:54, from acap.c:64: /usr/include/openssl/ssl.h:909: parse error before KSSL_CTX /usr/include/openssl/ssl.h:931: parse error before '}' token make[1]: *** [acap.o] Error 1 make[1]: Leaving directory `/mnt/nfs/cyrus-imapd-2.1.13/acap' make: *** [all] Error 1 -- 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. attachment: smiley-3.pngattachment: smiley-4.png
Re: Sieve help
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. -- 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
Linking imapd with db-4.1.25
Hello, I've built and installed db-4.1.25 in a non-standard location on my RedHat 9.0 machine and am having trouble getting cyrus-imapd-2.1.13 to against it. It appears that the configure script does not detect it properly, even if I invoke the configure script with the --with-bdb-libdir=my non-standard db-4.1.25 location and --with-bdb-incdir=my non standard db-4.1.25 location options set. Snippet from configure's output: === checking for db.h... yes checking for db_create in -ldb-4.1... no checking for db_create in -ldb4.1... no checking for db_create in -ldb41... no checking for db_create in -ldb-4.0... yes === When I do an ldd on the resultant imapd binary after the build finishes, I see that it been linked to the bdb libraries that came with the RedHat install (4.0.14-20). I've played around with LDFLAGS, CPPFLAGS, and LD_LIBRARY_PATH environment variables to try and force the directories of my non-standard libraries and headers to be loaded first, but that didn't change a thing. I'm reluctant to remove the RedHat db4 installation because I quite certain that it would break a large amount of dependencies... Any ideas? Thanks, Lars Peterson iTech Inc.
Re: Linking imapd with db-4.1.25
Lars Peterson wrote: Snippet from configure's output: === checking for db.h... yes checking for db_create in -ldb-4.1... no checking for db_create in -ldb4.1... no checking for db_create in -ldb41... no checking for db_create in -ldb-4.0... yes === When I do an ldd on the resultant imapd binary after the build finishes, I see that it been linked to the bdb libraries that came with the RedHat install (4.0.14-20). I've played around with LDFLAGS, CPPFLAGS, and LD_LIBRARY_PATH environment variables to try and force the directories of my non-standard libraries and headers to be loaded first, but that didn't change a thing. I'm reluctant to remove the RedHat db4 installation because I quite certain that it would break a large amount of dependencies... Any ideas? In the directory you passed for bdb-libdir, is there a libdb-4.1.so? Are permissions on it set properly? BTW, you may be happier using 4.0.14. On Solaris anyway, I consistently ran into problems after a week or two of uptime with 4.1.25, and that all went away after downgrading to 4.0.14. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
Re: Linking imapd with db-4.1.25
On Fri, June 6, 2003 2:05 pm, John Alton Tamplin wrote: Lars Peterson wrote: Snippet from configure's output: === checking for db.h... yes checking for db_create in -ldb-4.1... no checking for db_create in -ldb4.1... no checking for db_create in -ldb41... no checking for db_create in -ldb-4.0... yes === When I do an ldd on the resultant imapd binary after the build finishes, I see that it been linked to the bdb libraries that came with the RedHat install (4.0.14-20). I've played around with LDFLAGS, CPPFLAGS, and LD_LIBRARY_PATH environment variables to try and force the directories of my non-standard libraries and headers to be loaded first, but that didn't change a thing. I'm reluctant to remove the RedHat db4 installation because I quite certain that it would break a large amount of dependencies... Any ideas? In the directory you passed for bdb-libdir, is there a libdb-4.1.so? Are permissions on it set properly? Yes libdb-4.1.so is in the same directory I passed to configure for bdb-libdir. Permissions are same user I'm building as, and mode is 775. I was able to link against these libraries successfully for an openldap-2.1.19 build. BTW, you may be happier using 4.0.14. On Solaris anyway, I consistently ran into problems after a week or two of uptime with 4.1.25, and that all went away after downgrading to 4.0.14. I'll take this into consideration. I've had no problems thus far with db-4.1.25 with respect to openldap / slapd... What kind of problems were you seeing on your Solaris box? Lars
Re: Linking imapd with db-4.1.25
On Fri, 6 Jun 2003, John Alton Tamplin wrote: Lars Peterson wrote: Snippet from configure's output: === checking for db.h... yes checking for db_create in -ldb-4.1... no checking for db_create in -ldb4.1... no checking for db_create in -ldb41... no checking for db_create in -ldb-4.0... yes === When I do an ldd on the resultant imapd binary after the build finishes, I see that it been linked to the bdb libraries that came with the RedHat install (4.0.14-20). I've played around with LDFLAGS, CPPFLAGS, and LD_LIBRARY_PATH environment variables to try and force the directories of my non-standard libraries and headers to be loaded first, but that didn't change a thing. I'm reluctant to remove the RedHat db4 installation because I quite certain that it would break a large amount of dependencies... Any ideas? In the directory you passed for bdb-libdir, is there a libdb-4.1.so? Are permissions on it set properly? BTW, you may be happier using 4.0.14. On Solaris anyway, I consistently ran into problems after a week or two of uptime with 4.1.25, and that all went away after downgrading to 4.0.14. This problem is fixed in cvs for both 2.1.x and 2.2. -- Igor
Re: Linking imapd with db-4.1.25
Lars Peterson wrote: Yes libdb-4.1.so is in the same directory I passed to configure for bdb-libdir. Permissions are same user I'm building as, and mode is 775. I was able to link against these libraries successfully for an openldap-2.1.19 build. Then I suggest looking at the log generated by configure and see why it didn't think it passed the test. I'll take this into consideration. I've had no problems thus far with db-4.1.25 with respect to openldap / slapd... Right, I haven't had any problems in any other application either. I don't know if that is because they don't get as heavy usage or if the usage pattern is different or what. What kind of problems were you seeing on your Solaris box? After a week or two of uptime, I would get ENOSPC returns from dbopen, and sieve would stop working (since my duplicate delivery database is using db3_nosync). Other people reported similar problems with 4.1.24-25 in this list without any resolution, until someone suggested to me that going back to db 4.0.14 would fix the problem. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
Re: Linking imapd with db-4.1.25
Igor Brezac wrote: This problem is fixed in cvs for both 2.1.x and 2.2. Ok, so it was a problem in Cyrus not db? Thanks. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
Re: Linking imapd with db-4.1.25
On Fri, June 6, 2003 2:46 pm, John Alton Tamplin wrote: Igor Brezac wrote: This problem is fixed in cvs for both 2.1.x and 2.2. Ok, so it was a problem in Cyrus not db? Thanks. I'm not so sure. Checked 2.1 branch out of CVS and I still can't get it to work. Same results with 2.2-ALPHA. It finds db-4.0 but not db-4.1. Upon further investigation, it looks like maybe the problem is with db-4.1.25 and not cyrus... Here's some output from config.log: snip configure:5808: checking for db_create in -ldb-4.1 configure:5839: gcc -o conftest -Wall -g -O2 -I/usr/local/itech/iwaymail/include -L/usr/local/lib -Wl,-rpath,/usr/local/lib - L/usr/local/itech/iwaymail/lib conftest.c -ldb-4.1 -L/usr/local/itech/iwaymail/lib -lresolv -Wl,-rpath,/usr/local/itech/iw aymail/lib 5 /usr/local/itech/iwaymail/lib/libdb-4.1.so: undefined reference to `pthread_condattr_setpshared' /usr/local/itech/iwaymail/lib/libdb-4.1.so: undefined reference to `pthread_mutexattr_destroy' /usr/local/itech/iwaymail/lib/libdb-4.1.so: undefined reference to `pthread_mutexattr_setpshared' /usr/local/itech/iwaymail/lib/libdb-4.1.so: undefined reference to `pthread_mutexattr_init' /usr/local/itech/iwaymail/lib/libdb-4.1.so: undefined reference to `pthread_mutex_trylock' collect2: ld returned 1 exit status configure:5842: $? = 1 snip Any ideas where I might find some support for db-4.1.25? Can't find any mailing lists or news feeds on sleepycat's site. Lars
Re: Linking imapd with db-4.1.25
Lars Peterson wrote: Here's some output from config.log: snip configure:5808: checking for db_create in -ldb-4.1 configure:5839: gcc -o conftest -Wall -g -O2 -I/usr/local/itech/iwaymail/include -L/usr/local/lib -Wl,-rpath,/usr/local/lib - L/usr/local/itech/iwaymail/lib conftest.c -ldb-4.1 -L/usr/local/itech/iwaymail/lib -lresolv -Wl,-rpath,/usr/local/itech/iw aymail/lib 5 /usr/local/itech/iwaymail/lib/libdb-4.1.so: undefined reference to `pthread_condattr_setpshared' /usr/local/itech/iwaymail/lib/libdb-4.1.so: undefined reference to `pthread_mutexattr_destroy' /usr/local/itech/iwaymail/lib/libdb-4.1.so: undefined reference to `pthread_mutexattr_setpshared' /usr/local/itech/iwaymail/lib/libdb-4.1.so: undefined reference to `pthread_mutexattr_init' /usr/local/itech/iwaymail/lib/libdb-4.1.so: undefined reference to `pthread_mutex_trylock' collect2: ld returned 1 exit status configure:5842: $? = 1 snip Any ideas where I might find some support for db-4.1.25? Can't find any mailing lists or news feeds on sleepycat's site. Ah, you are running into fun with RH9's NPTL (New Posix Threads Library). If you look at the archives for this list you will find some discussion about it. I believe the quick and dirty solution was to compile DB4 with a flag telling it to assume phtreads were not available, but Simon also posted a link to a discussion at RedHat about more general issues with NPTL. The particular errors you are getting are because it can't find the pthreads library when it does the test. You can fix that by telling configure to use -lpthreads on any compiles, but if I remember correctly you will then run into other issues when DB4 tries to do some operations on the threads. I am staying with RH8 for my production machines because of this and a few other minor issues. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
delete folder does not delete directory
Cyrus 2.1.12 on Solaris 9 (sparc). It seems that when one deletes a folder via IMAP, the directory under /var/spool/imap/... is not always removed. I'm still investigating if this behaviour depends on the mail client. Is this a known problem ? -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Piet RUYSSINCK e-mail: [EMAIL PROTECTED] Unix Systeem Administratie tel: +32 9 264 4733 Directie Informatie- en Communicatietechnologie fax: +32 9 264 4994 Universiteit Gent Krijgslaan 281, gebouw S9 - 9000 Gent, Belgie -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Please avoid sending me Word or PowerPoint attachments See http://www.fsf.org/philosophy/no-word-attachments.html
Re: delete folder does not delete directory
On Fri, 6 Jun 2003, Piet Ruyssinck wrote: Cyrus 2.1.12 on Solaris 9 (sparc). It seems that when one deletes a folder via IMAP, the directory under /var/spool/imap/... is not always removed. I'm still investigating if this behaviour depends on the mail client. Is this a known problem ? Known problem. If you delete a mailbox that is SELECTED (in another session), then the directory can't be removed because the process is chdir'd into it. I have a (probably slightly out of date at this point) patch to fix cyrus's use of chdir(), see: http://bugzilla.andrew.cmu.edu/show_bug.cgi?id=1268 -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Linking imapd with db-4.1.25
On Fri, 6 Jun 2003, John Alton Tamplin wrote: Igor Brezac wrote: This problem is fixed in cvs for both 2.1.x and 2.2. Ok, so it was a problem in Cyrus not db? Thanks. This is an unfortunate bug. Sleepycat added db handle locking in 4.1.25 and cyrus was not closing db handles to clear the locks after the services (lmtpd, imapd...) terminated. -- Igor
Re: Cyrus-Imap-2.2 with postfix
I use from 6 months cyrus-imapd-2.2 with postfix without any problems. Which version of postfix are you using ? Because starting from version 2 there are some change in the postfix configuration for virtual address. On my machine I work with 3 domains and I use LDAP. May be if you coul send the postfix main.cf and the imapd.conf file I can help you. vittorio Citazione Vernon A. Fort [EMAIL PROTECTED]: Has or does anyone use the 2.2 version with postfix. I cannot get any mail delivered to cyrus. the ususal statement (unknown user). I have created a user like cm [EMAIL PROTECTED] Set the imapd.conf file per the docs use the standard LMTP config within postfix Still no mail can be delivered outside of the default domain name. What should the master.cf file look like? Any help would be great Andy Vernon A. Fort (Andy) Provident Solutions, LLC (615) 427-4016 http://www.provident-solutions.com - This mail sent through IMP: http://horde.org/imp/
Cyrus Imap refuses to work with vpopmail maildir
Hello All, RedHat 7.3 Apache 1.3.27 PHP 4.3.1 Qmail SquirrelMail 1.0.4 qmailadmin 1.0.20 vpopmail 5.3.20 Cyrus Imap. The above is my setup. I have created mail accounts for my virtual domain with vpopmail and they are working fine with QmailAdmin. When i try to login to SquirrelMail which is on SSL and uses Cyrus Imap server It simply Says Incorrect Username/Password. I have checked the username and passwd they are perfectly correct and i can login with the same to qmail admin. Here i want to mark a point that these mail accounts are created with vpopmail and are in MailDir format. How how do i enable the working of my mail accounts with Cyrus ? Please put me on a correct path, i have searched and googled around but was unable to get what i want. Regards, Tina.
Re: RH 9.0 ssl compiler error
/usr/kerberos/include has to be added to the include path anywhere the openssl headers are used. You can probably do it by adding -I/usr/kerberos/include to the CFLAGS environment variable when you run configure. Bennett --On Friday, June 6, 2003 11:00 -0500 Richard Houston [EMAIL PROTECTED] wrote: Hi all, I am trying to compile Cyrus 2.1.13 on RH 9.0 but it keeps crapping out on ssl. I have included the ./configure and the error. Thanks all Rich ./configure --enable-netscapehack --enable-annotatemore --enable-listext --with-perl=/usr/bin/perl --with-libwrap=/usr --with-sasl=/usr --with-seen-db=db3_nosync --with-subs-db=db3_nosync --with-auth=unix gcc -c -I/usr/include -I/usr/include -I. -I.. -I. -I./../lib -DHAVE_CONFIG_H -Wall -g -O2 \ acap.c In file included from /usr/include/openssl/ssl.h:179, from ../lib/prot.h:54, from acap.c:64: /usr/include/openssl/kssl.h:72:18: krb5.h: No such file or directory In file included from /usr/include/openssl/ssl.h:179, from ../lib/prot.h:54, from acap.c:64: /usr/include/openssl/kssl.h:132: parse error before krb5_enctype /usr/include/openssl/kssl.h:134: parse error before FAR /usr/include/openssl/kssl.h:135: parse error before '}' token /usr/include/openssl/kssl.h:147: parse error before kssl_ctx_setstring /usr/include/openssl/kssl.h:147: parse error before '*' token /usr/include/openssl/kssl.h:148: parse error before '*' token /usr/include/openssl/kssl.h:149: parse error before '*' token /usr/include/openssl/kssl.h:149: parse error before '*' token /usr/include/openssl/kssl.h:150: parse error before '*' token /usr/include/openssl/kssl.h:151: parse error before kssl_ctx_setprinc /usr/include/openssl/kssl.h:151: parse error before '*' token /usr/include/openssl/kssl.h:153: parse error before kssl_cget_tkt /usr/include/openssl/kssl.h:153: parse error before '*' token /usr/include/openssl/kssl.h:155: parse error before kssl_sget_tkt /usr/include/openssl/kssl.h:155: parse error before '*' token /usr/include/openssl/kssl.h:157: parse error before kssl_ctx_setkey /usr/include/openssl/kssl.h:157: parse error before '*' token /usr/include/openssl/kssl.h:159: parse error before context /usr/include/openssl/kssl.h:160: parse error before kssl_build_principal_2 /usr/include/openssl/kssl.h:160: parse error before context /usr/include/openssl/kssl.h:163: parse error before kssl_validate_times /usr/include/openssl/kssl.h:163: parse error before atime /usr/include/openssl/kssl.h:165: parse error before kssl_check_authent /usr/include/openssl/kssl.h:165: parse error before '*' token /usr/include/openssl/kssl.h:167: parse error before enctype In file included from ../lib/prot.h:54, from acap.c:64: /usr/include/openssl/ssl.h:909: parse error before KSSL_CTX /usr/include/openssl/ssl.h:931: parse error before '}' token make[1]: *** [acap.o] Error 1 make[1]: Leaving directory `/mnt/nfs/cyrus-imapd-2.1.13/acap' make: *** [all] Error 1
Sieve help
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?
Re: Debug output
It really sort of depends on how it's configured now, which syslog you use, etc. In my case it'd be a matter of changing local6.debug to local6.info, but your system may vary. Denny Schierz wrote: hi, which lines i have to write into my syslog.conf, to stop the debug output. cu denny
Re: RH 9.0 ssl compiler error
I'd guess you don't have the Kerberos development package installed (and I don't run Red Hat, so I couldn't tell you what it'd be called). If it's there, and configure's just not finding it, you'll need to use to use the --with-krb=PATH option for configure. From ./configure --help: --with-krb=PATH use Kerberos from PATH If you don't need Kerberos, using --without-krb may get you where you want to go. Bennett Crowell wrote: /usr/kerberos/include has to be added to the include path anywhere the openssl headers are used. You can probably do it by adding -I/usr/kerberos/include to the CFLAGS environment variable when you run configure. Bennett --On Friday, June 6, 2003 11:00 -0500 Richard Houston [EMAIL PROTECTED] wrote: Hi all, I am trying to compile Cyrus 2.1.13 on RH 9.0 but it keeps crapping out on ssl. I have included the ./configure and the error. Thanks all Rich ./configure --enable-netscapehack --enable-annotatemore --enable-listext --with-perl=/usr/bin/perl --with-libwrap=/usr --with-sasl=/usr --with-seen-db=db3_nosync --with-subs-db=db3_nosync --with-auth=unix gcc -c -I/usr/include -I/usr/include -I. -I.. -I. -I./../lib -DHAVE_CONFIG_H -Wall -g -O2 \ acap.c In file included from /usr/include/openssl/ssl.h:179, from ../lib/prot.h:54, from acap.c:64: /usr/include/openssl/kssl.h:72:18: krb5.h: No such file or directory In file included from /usr/include/openssl/ssl.h:179, from ../lib/prot.h:54, from acap.c:64: /usr/include/openssl/kssl.h:132: parse error before krb5_enctype /usr/include/openssl/kssl.h:134: parse error before FAR /usr/include/openssl/kssl.h:135: parse error before '}' token /usr/include/openssl/kssl.h:147: parse error before kssl_ctx_setstring /usr/include/openssl/kssl.h:147: parse error before '*' token /usr/include/openssl/kssl.h:148: parse error before '*' token /usr/include/openssl/kssl.h:149: parse error before '*' token /usr/include/openssl/kssl.h:149: parse error before '*' token /usr/include/openssl/kssl.h:150: parse error before '*' token /usr/include/openssl/kssl.h:151: parse error before kssl_ctx_setprinc /usr/include/openssl/kssl.h:151: parse error before '*' token /usr/include/openssl/kssl.h:153: parse error before kssl_cget_tkt /usr/include/openssl/kssl.h:153: parse error before '*' token /usr/include/openssl/kssl.h:155: parse error before kssl_sget_tkt /usr/include/openssl/kssl.h:155: parse error before '*' token /usr/include/openssl/kssl.h:157: parse error before kssl_ctx_setkey /usr/include/openssl/kssl.h:157: parse error before '*' token /usr/include/openssl/kssl.h:159: parse error before context /usr/include/openssl/kssl.h:160: parse error before kssl_build_principal_2 /usr/include/openssl/kssl.h:160: parse error before context /usr/include/openssl/kssl.h:163: parse error before kssl_validate_times /usr/include/openssl/kssl.h:163: parse error before atime /usr/include/openssl/kssl.h:165: parse error before kssl_check_authent /usr/include/openssl/kssl.h:165: parse error before '*' token /usr/include/openssl/kssl.h:167: parse error before enctype In file included from ../lib/prot.h:54, from acap.c:64: /usr/include/openssl/ssl.h:909: parse error before KSSL_CTX /usr/include/openssl/ssl.h:931: parse error before '}' token make[1]: *** [acap.o] Error 1 make[1]: Leaving directory `/mnt/nfs/cyrus-imapd-2.1.13/acap' make: *** [all] Error 1
Re: Debug output
Something along the line of : local6.info /var/log/imapd.log You replace /var/log/imapd.log by whatever is the file where you want to log messages from imapd. local6 is called the syslog facilities; imapd ask to syslog to log his messages to that facilities. info is the level; messages of level lower than info will not be logged by that line (see the syslog.conf man page for explanation). On Fri, Jun 06, 2003 at 06:13:13PM +0200, Denny Schierz wrote: hi, which lines i have to write into my syslog.conf, to stop the debug output. cu denny -- Etienne GoyerLinux Québec Technologies Inc. http://www.LinuxQuebec.com [EMAIL PROTECTED]
